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

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

On 5/18/16, 1:50 AM, "Renuka Rathore" <vpp-dev-bounces@... on behalf of renuka.rathore@...> wrote:

Team,

We tried pulling the NSH branch following the link -
git clone https://gerrit.fd.io/r/nsh_sfc. <https://gerrit.fd.io/r/nsh_sfc>

Download completed with following output and nsh_sfc folder is found empty-
Cloning into 'nsh_sfc'...
remote: Total 2 (delta 0), reused 2 (delta 0)
Unpacking objects: 100% (2/2), done.
Checking connectivity... done.
<https://gerrit.fd.io/r/nsh_sfc>
Is the link correct or else please direct us to actual code base.

Regards,
Renuka



-----vpp-dev-bounces@... wrote: -----To: vpp-dev@...
From: vpp-dev-request@...
Sent by: vpp-dev-bounces@...
Date: 05/18/2016 04:35AM
Subject: vpp-dev Digest, Vol 4, Issue 145

Send vpp-dev mailing list submissions to
vpp-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.fd.io/mailman/listinfo/vpp-dev
or, via email, send a message with subject or body 'help' to
vpp-dev-request@...

You can reach the person managing the list at
vpp-dev-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of vpp-dev digest..."


Today's Topics:

1. Re: Please help in testing binary package repos (Edward Warnicke)
2. Re: Performance tuning (Chandrasekar Kannan)


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

Message: 1
Date: Tue, 17 May 2016 16:38:29 -0500
From: Edward Warnicke <hagbard@...>
To: "Carsten Koester (ckoester)" <ckoester@...>
Cc: "csit-dev@..." <csit-dev@...>, "Dave Wallace
\(dwallace\)" <dwallace@...>, vpp-dev <vpp-dev@...>
Subject: Re: [vpp-dev] Please help in testing binary package repos
Message-ID:
<CAFVSqg2E6=WGQ82Sc6uObLwa01VA0=U=D294L3aFFcRFhuJ0YQ@...>
Content-Type: text/plain; charset="utf-8"

Carsten,

I chose to not use add-apt-repository because it would requere

sudo apt-get install software-properties-common python-software-properties

(note: explanation of reasoning should not be interpreted as defense of
resulting decision in this case ;) ).

I actually like all your reasons to use add-apt-repository, and am just
curious other folks opinion of the tradeoff :)

As to relationships between OSes and versions we build and OSes and
versions we test.
Ideally, they'd be the same.

That said, having build jobs running on an OS and producing binary packages
is a bit different than saying we support an OS/version. I see those
builds as:

a) Preventing us from *breaking* the build for those OSes at least (a
useful thing)
b) Enabling downstream projects to likewise make sure they aren't breaking
their build on those OSes.

Which is my way of saying, I see the build verify jobs as signaling we
still build on a platform, not necessarily a statement of support.
(which would really require some testing as you said).

Ideally, I'd love for CSIT to also test the packaging. You are sort of
doing that a *bit* now in that you are building the packages for ubuntu1404
and then using those on VIRL.

Ed




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
_______________________________________________
vpp-dev mailing list
vpp-dev@...
https://lists.fd.io/mailman/listinfo/vpp-dev