On Tue, May 17, 2016 at 4:23 PM, Carsten Koester (ckoester) <
ckoester@...> wrote:

> I guess personally I would have a very slight preference for
>
>     sudo add-apt-repository 'deb
> https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.trusty.main/
> ./'
>
> instead of manually creating the apt sources file, for the following
> reasons:
>
> - the command works with sudo (unlike the "echo [...] > /etc/apt/[...]"
> which requires the user to be in a root shell),
> - the command is slightly more descriptive of what it actually does,
> - I guess I generally have a slight preference for using APT utilities
> when available, rather than modifying files by hand.
>
> But that's just my 2 cent, and, I admit, mostly academic.
>
>
> Wondering if we can link this to the "CSIT verification for multiple linux
> images" thread initiated by Dave:
>
> Should there be some relation between the OSs and versions we test, and
> the ones we build binary packages for? IMHO we should NOT be claiming to
> support X, test on Y, and provide a binary package for Z. They should all
> be the same versions, and stem from a common "authoritative" source.
>
> And should CSIT actually test these binary packages? Not from a
> functionality point of view (we have that covered as part of the
> jenkins/git-review cycle), but for "installability", ie make sure there are
> no missing dependancies in the .deb or .rpm packages?
>
> -Carsten
>
>
>
>
> From:  <vpp-dev-bounces@...> on behalf of Edward Warnicke <
> hagbard@...>
> Date:  Tuesday, May 17, 2016 at 1:59 PM
> To:  vpp-dev <vpp-dev@...>
> Subject:  [vpp-dev] Please help in testing binary package repos
>
>
> I have documented how to install packages from binary repos here:
>
> https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages
>
>
> I have done spot checks for ubuntu1404 and centos7 for both master and
> stable/1606 packages.
>
> If someone has an ubuntu1604 they could try with, or would be willing to
> otherwise
> give the instructions a spin, that would be very helpful :)
>
> Ed
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fd.io/pipermail/vpp-dev/attachments/20160517/eff99b5c/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 17 May 2016 16:05:16 -0700
From: Chandrasekar Kannan <ckannan@...>
To: "Dave Barach (dbarach)" <dbarach@...>
Cc: "csit-dev@..." <csit-dev@...>,
"vpp-dev@..." <vpp-dev@...>
Subject: Re: [vpp-dev] Performance tuning
Message-ID:
<CAF2CpCkJxerzGS9y1WhDYd+eaLOeF2mVZrXO1XjOjvv8DQ-9QQ@...>
Content-Type: text/plain; charset="utf-8"

Sure. Will try it out. Thanks for all the feedback so far.

-Chandra



On Tue, May 17, 2016 at 2:35 PM, Dave Barach (dbarach) <dbarach@...>
wrote:

> Not having all of the memory channels populated is an absolute killer.
> This isn?t a case of ?would be faster,? it?s a case of ?won?t work properly
> unless...?
>
>
>
> There is no workaround. Please populate all the memory channels.
>
>
>
> Thanks? Dave
>
>
>
> *From:* vpp-dev-bounces@... [mailto:vpp-dev-bounces@...] *On
> Behalf Of *Chandrasekar Kannan
> *Sent:* Tuesday, May 17, 2016 5:25 PM
> *To:* Maciek Konstantynowicz (mkonstan) <mkonstan@...>
> *Cc:* csit-dev@...; vpp-dev@...
> *Subject:* Re: [vpp-dev] Performance tuning
>
>
>
> Interesting. Will try that one out and report back.
>
> On May 17, 2016 1:52 PM, "Maciek Konstantynowicz (mkonstan)" <
> mkonstan@...> wrote:
>
> Good.
>
> Looking at http://pastebin.com/raw/5wUrh2Z0
>
>
>
> Memory channels 2 and 3 are not populated - so your system operates in
> dual-channel memory mode,
>
> instead of quad-channel i.e. slower memory access. It would be faster if
> they would be populated.
>
>
> -Maciek
>
>
>
> Physical Memory Array
>
>     Use: System Memory
>
> Memory Device
>
>     Size: 16384 MB
>
>     Locator: P1-DIMMA1
>
>     Bank Locator: P0_Node0_Channel0_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMA2
>
>     Bank Locator: P0_Node0_Channel0_Dimm1
>
> Memory Device
>
>     Size: 16384 MB
>
>     Locator: P1-DIMMB1
>
>     Bank Locator: P0_Node0_Channel1_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMB2
>
>     Bank Locator: P0_Node0_Channel1_Dimm1
>
> Physical Memory Array
>
>     Use: System Memory
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMC1
>
>     Bank Locator: P0_Node0_Channel2_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMC2
>
>     Bank Locator: P0_Node0_Channel2_Dimm1
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMD1
>
>     Bank Locator: P0_Node0_Channel3_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P1-DIMMD2
>
>     Bank Locator: P0_Node0_Channel3_Dimm1
>
> Physical Memory Array
>
>     Use: System Memory
>
> Memory Device
>
>     Size: 16384 MB
>
>     Locator: P2-DIMME1
>
>     Bank Locator: P1_Node1_Channel0_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMME2
>
>     Bank Locator: P1_Node1_Channel0_Dimm1
>
> Memory Device
>
>     Size: 16384 MB
>
>     Locator: P2-DIMMF1
>
>     Bank Locator: P1_Node1_Channel1_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMMF2
>
>     Bank Locator: P1_Node1_Channel1_Dimm1
>
> Physical Memory Array
>
>     Use: System Memory
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMMG1
>
>     Bank Locator: P1_Node1_Channel2_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMMG2
>
>     Bank Locator: P1_Node1_Channel2_Dimm1
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMMH1
>
>     Bank Locator: P1_Node1_Channel3_Dimm0
>
> Memory Device
>
>     Size: No Module Installed
>
>     Locator: P2-DIMMH2
>
>     Bank Locator: P1_Node1_Channel3_Dimm1
>
>
>
>
>
> On 17 May 2016, at 21:03, Chandrasekar Kannan <ckannan@...> wrote:
>
>
>
> adding dpdk { no-multi-seg } has definitely bumped up the perf from
> 7.5Gbps to 8.8Gbps.
>
> Thanks for the suggestion. Much appreciated.
>
>
>
> -Chandra
>
>
>
>
>
>
>
> On Tue, May 17, 2016 at 12:57 PM, Chandrasekar Kannan <ckannan@...>
> wrote:
>
> dmidecode output is here - http://pastebin.com/raw/5wUrh2Z0
>
> Single port Intel 40GbE card -  yes.
>
>
>
> Traffic leaves the generator - hits the intel nic - vpp routes it back to
> the traffic generator. Hope that helps.
>
> Will do some test on multi-seg and report back.
>
>
>
> -Chandra
>
>
>
>
>
>
>
> On Tue, May 17, 2016 at 12:52 PM, Maciek Konstantynowicz (mkonstan) <
> mkonstan@...> wrote:
>
> Chandra,
>
>
>
> Looking at your configs posted here:  http://pastebin.com/raw/gTxUUVgJ
>
>
>
> You?re testing single 40GE, in one direction, yes?
>
>
>
> Can you send output of "dmidecode -t memory??
>
>
>
> In your startup.conf, can you add:
>
>
>
>   dpdk {
>
>     no-multi-seg
>
>   }
>
>
>
> -Maciek
>
>
>
>
>
>
>
> On 17 May 2016, at 19:53, Chandrasekar Kannan <ckannan@...> wrote:
>
>
>
> >> In your system you should be getting better number than these :)
>
> That's great to hear. Hopefully we can find out what's going on here...
>
>
>
> -Chandra
>
>
>
>
>
>
>
> On Tue, May 17, 2016 at 11:40 AM, Maciek Konstantynowicz (mkonstan) <
> mkonstan@...> wrote:
>
> +csit-dev
>
>
>
> Chandra,
>
>
>
> ~14Mpps has been measured on faster cores e.g. E5-2667 3.20 GHz v3.
>
> Also on older CPUs e.g. E5-2690 2.9GHz.
>
> Core frequency matters a lot.
>
>
>
> From this thread I see you?re testing on:
>
> [root@localhost ~]# grep -E '^model name|^cpu MHz' /proc/cpuinfo
>
> model name : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
>
>
>
> In CSIT LF perf test beds we have these:
>
>
>
> model name : Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
>
> https://wiki.fd.io/view/CSIT/CSIT_LF_testbed
>
>
>
> And here recent throughput results generated by csit-vpp-perf-hw-all:
>
>
>
>     https://jenkins.fd.io/view/csit/job/csit-vpp-perf-hw-all/106/console
>
>
> https://jenkins.fd.io/view/csit/job/csit-vpp-perf-hw-all/106/robot/report/log.html
>
>
>
>         1core
>
>         64B Mpps
>
>         l2bd 8.2
>
>         ip4 9.0
>
>         ip6 8.2
>
>         l2xc 10.0
>
>
>
> These still look bit on a low side for this cpu, we don?t have complete
> VPP stats
>
> while test is running, CSIT work ongoing to get them so that we can
> analyze
>
> if system running at capacity or if we have TG/T-Rex or environment issues.
>
>
>
> In your system you should be getting better number than these :)
>
>
> -Maciek
>
>
>
>
>
>
>
> On 17 May 2016, at 18:20, Chandrasekar Kannan <ckannan@...> wrote:
>
>
>
> If anybody has suggestions on how to get to 14Mpps on a single core, I
> would appreciate that.
>
>
>
> Thanks,
>
> -Chandra
>
>
>
>
>
>
>
> On Mon, May 16, 2016 at 10:42 PM, Chandrasekar Kannan <ckannan@...>
> wrote:
>
> yeah I'm not able to get 14Mpps on a single core.
>
>
>
> On Mon, May 16, 2016 at 10:24 PM, Oleg A. Arkhangelsky <sysoleg@...>
> wrote:
>
>
>
> 16.05.2016, 22:04, "Damjan Marion (damarion)" <damarion@...>:
> > Yes, as suspected you can see that only 1st worker thread is doing work.
> >
> > You can also try to randomise UDP port or ip address in the flow, to get
> RSS engine to spray traffic more equally...
> >
>
> Hmm... According to this [1], VPP should be able to go up to
> the ~14 Mpps even on a single core (so no RSS).
>
> [1] http://blogs.cisco.com/sp/a-bigger-helping-of-internet-please
>
> --
> wbr, Oleg.
>
> "Anarchy is about taking complete responsibility for yourself."
>       Alan Moore.
>
>
>
>
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@...
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fd.io/pipermail/vpp-dev/attachments/20160517/c387dff8/attachment.html>

------------------------------

_______________________________________________
vpp-dev mailing list
vpp-dev@...
https://lists.fd.io/mailman/listinfo/vpp-dev

End of vpp-dev Digest, Vol 4, Issue 145
***************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you