Date: Thu, 13 May 2021 07:58:39 -0400 From: Jacques Fourie <jacques.fourie@gmail.com> To: Francois ten Krooden <ftk@nanoteq.com> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, Vincenzo Maffione <vmaffione@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Vector Packet Processing (VPP) portability on FreeBSD Message-ID: <CALX0vxA3_eDRJmEGBak=e99nOrBkFYEmdnBHEY9JLTmT7tQ2vQ@mail.gmail.com> In-Reply-To: <AB9BB4D903F59549B2E27CC033B964D6C4F8D386@NTQ-EXC.nanoteq.co.za> References: <AB9BB4D903F59549B2E27CC033B964D6C4F8BECE@NTQ-EXC.nanoteq.co.za> <91e21d18a4214af4898dd09f11144493@EX16-05.ad.unipi.it> <CA%2BhQ2%2BjQ2fh4TXz02mTxAHJkHBWzfNhd=yRqPG45E7Z4umAsKA@mail.gmail.com> <e778ca61766741b0950585f6b26d8fff@EX16-05.ad.unipi.it> <CA%2BhQ2%2BhzjT5%2BRXmUUV4PpkXkvgQEJb8JrLPY7LqteV9ixeM7Ew@mail.gmail.com> <AB9BB4D903F59549B2E27CC033B964D6C4F8D386@NTQ-EXC.nanoteq.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 13, 2021 at 7:27 AM Francois ten Krooden <ftk@nanoteq.com> wrote: > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > <ftk@nanoteq.com> wrote: > > > > > > Hi > > > > > > Just for info I ran a test using TREX (https://trex-tgn.cisco.com/) > > > Where I just sent traffic in one direction through the box running > FreeBSD > > with VPP using the netmap interfaces. > > > These were the results we found before significant packet loss started > > occuring. > > > +-------------+------------------+ > > > | Packet Size | Throughput (pps) | > > > +-------------+------------------+ > > > | 64 bytes | 1.008 Mpps | > > > | 128 bytes | 920.311 kpps | > > > | 256 bytes | 797.789 kpps | > > > | 512 bytes | 706.338 kpps | > > > | 1024 bytes | 621.963 kpps | > > > | 1280 bytes | 569.140 kpps | > > > | 1440 bytes | 547.139 kpps | > > > | 1518 bytes | 524.864 kpps | > > > +-------------+------------------+ > > > > Those numbers are way too low for netmap. > > > > I believe you are either using the emulated mode, or issuing a system > call on > > every single packet. > > > > I am not up to date (Vincenzo may know better) but there used to be a > sysctl > > variable to control the operating mode: > > > > https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 > > > > SYSCTL VARIABLES AND MODULE PARAMETERS > > Some aspects of the operation of netmap and VALE are controlled > > through > > sysctl variables on FreeBSD (dev.netmap.*) and module parameters on > > Linux > > (/sys/module/netmap/parameters/*): > > > > dev.netmap.admode: 0 > > Controls the use of native or emulated adapter mode. > > > > 0 uses the best available option; > > > > 1 forces native mode and fails if not available; > > > > 2 forces emulated hence never fails. > > > > If it still exists, try set it to 1. If the program fails, then you > should figure out > > why native netmap support is not compiled in. > > Thank you. I did set this to 1 specifically now and it still works. So > then it should be running in native mode. > > I will dig a bit into the function that processes the incoming packets. > The code I currently use was added to VPP in somewhere before 2016, so it > might be that there is a bug in that code. > > Will try and see if I can find anything interesting there. > > > > > cheers > > luigi > > > A couple of questions / suggestions: Will it be possible to test using the netmap bridge app or a vale switch instead of vpp? Did you verify that the TREX setup can perform at line rate when connected back to back? Which NICs are you using? > > > Important Notice: > > This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail > legal notice available at: > http://www.nanoteq.com/AboutUs/EmailDisclaimer.aspx > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALX0vxA3_eDRJmEGBak=e99nOrBkFYEmdnBHEY9JLTmT7tQ2vQ>