RE: Vector Packet Processing (VPP) portability on FreeBSD
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 | +-+--+ Still busy investigating as to where this issue originates from. > -Original Message- > From: Francois ten Krooden > Sent: Tuesday, 11 May 2021 08:18 > To: 'Luigi Rizzo' > Cc: freebsd-net@freebsd.org > Subject: RE: Vector Packet Processing (VPP) portability on FreeBSD > > On 2021/05/10 15:39, Luigi Rizzo wrote: > > > -Original Message- > > From: Luigi Rizzo [mailto:ri...@iet.unipi.it] > > Sent: Monday, 10 May 2021 16:39 > > To: Rainer Duffner > > Cc: Francois ten Krooden ; freebsd-net@freebsd.org > > Subject: Re: Vector Packet Processing (VPP) portability on FreeBSD > > > > [repost since it appears to be blocked] > > > > On Mon, May 10, 2021 at 2:42 PM Rainer Duffner > > > > wrote: > > > > > > > > > > > > > Am 10.05.2021 um 13:08 schrieb Francois ten Krooden > > : > > > > > > > > Greetings > > > > > > > > We have a vested interest in high-speed IPsec VPN on FreeBSD. We > > > > have > > started with the porting of VPP (https://fd.io/) to FreeBSD. > > > > > > > > Currently we have VPP compiled and running with netmap. The speeds > > we measure are nowhere near the performance of a 10Gbps link, at > > around 350kpps for 1500 byte IPv4 packets. We suspect the biggest > > issue is related to how VPP implements huge pages (Linux) and our > > modifications to support super pages on FreeBSD. > > > > 350kpps is way too low for being related to tlb and page size issues. > > > > I suspect that you are > > either using the "emulated" netmap mode, which runs on top of mbufs > > and may involve extra data copies on the receive path, or the test itself is > e.g. > > using TCP and congestion control or limited window size throttle down > > the rate. > > The NIC's we are using is the 'Intel X552' (10 GbE SFP+) on the Supermicro > X10SDV-8C-TLN4F+ board. > I know this uses the 'ixgbe' driver in FreeBSD which is netmap enabled. > Is there a way I can confirm if it is running in emulated netmap mode? > > > > > I'd retry the test with some open loop traffic source/sink, and using > > first all possible low level APIs (sockets/mbufs; emulated netmap; > > native netmap; your vpp port) with small and large packets and > > increasing packet rates, to see where the limits are with each. That > > should give you good hints to figure out what is making the performance > so bad. > > Even better if you can run the test between one known-good endpoint so > > you can test separately the tx and tx sides. > > Thanks for these suggestions. I will rerun the tests again and just check if > I > can make some headway on this. > One additional test I have done previously is to use 'netmap-fwd' from > https://github.com/Netgate/netmap-fwd. > When I executed the tests with netmap-fwd I was able to reach around > 800kpps for 1500 byte packets, which was almost at the maximum speed. (I > will just confirm this number again) > > Cheers > Francois > > > > > Cheers > > Luigi > > 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-unsubscr...@freebsd.org"
RE: Vector Packet Processing (VPP) portability on FreeBSD
On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > 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 > 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-unsubscr...@freebsd.org"
Re: Vector Packet Processing (VPP) portability on FreeBSD
On Thu, May 13, 2021 at 7:27 AM Francois ten Krooden wrote: > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > 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-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Vector Packet Processing (VPP) portability on FreeBSD
On Thursday, 13 May 2021 13:59 Jacques Fourie > > On Thu, May 13, 2021 at 7:27 AM Francois ten Krooden > wrote: > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > 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: Thank you for the suggestions. > Will it be possible to test using the netmap bridge app or a vale switch > instead of vpp? I did perform a test using netmap-fwd (https://github.com/Netgate/netmap-fwd) I did look at the code and it appears that the packets are processed as a batch in the application. But each packet is passed through the complete IP stack in the application, before the next one is processed. With this application it was possible to reach about 1.4Mpps for 64-byte packets, and 812 kpps for 1518 byte packets I haven't done any other tweaking on the FreeBSD box yet. It is running FreeBSD 13.0 > Did you verify that the TREX setup can perform at line rate when connected > back to back? We did tests with TREX back to back yesterday and we reached the following. +-+--+ | Packet Size | Throughput (pps) | +-+--+ | 64 bytes |14.570 Mpps | | 128 bytes | 8.466 kpps | | 256 bytes | 4.542 kpps | | 512 bytes | 2.354 kpps | | 1024 bytes | 1.200 kpps | | 1280 bytes | 965.042 kpps | | 1440 bytes | 857.795 kpps | | 1518 bytes | 814.690 kpps | +-+--+ > Which NICs are you using? We are using Intel X552 10 GbE SFP+ NIC's which is part of the Intel Xeon D-1537 SoC, on a SuperMicro X10SDV-8C-TLN4F+ Board. I will also put the results on the github repository https://github.com/ftk-ntq/vpp/wiki and will update as we get some more information Kind Regards Francois > > > 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-unsubscr...@freebsd.org" 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-unsubscr...@freebsd.org"
RE: Vector Packet Processing (VPP) portability on FreeBSD
On Thursday, 13 May 2021 15:02, Luigi Rizzo > > On Thu, May 13, 2021 at 2:57 PM Luigi Rizzo wrote: > > > > On Thu, May 13, 2021 at 1:27 PM Francois ten Krooden > wrote: > > > > > > > > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > > > 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. > > > > Then try to instrument the code and see how many packets you are > > getting on every RXSYNC system call. > > > > If the value is mostly/always 0-1 then there is some bug with the > > (user) code that frees slots in the queue. > > Or another issue could be that your application spends too much time to > process packets, so the bottleneck is user processing. > The thing to monitor would be the time between system calls, divided by the > number of packets processed in between > .. > ioctl(RXSYNC); > t1 = get_nanoseconds(); > > n = > t2 = get_nanoseconds() > time_per_packet = (t2 - t1) / n; > > ioctl(RXSYNC); > ... Thank you will have a at this as well. Regards Francois ten Krooden > > cheers > luigi > 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-unsubscr...@freebsd.org"
[Bug 255596] ifconfig move interface with inet address to vnet jail panics kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255596 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||panic -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255421] alc0: Qualcomm Atheros QCA8172 failed get DHCP IP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255421 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||regression -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Vector Packet Processing (VPP) portability on FreeBSD
On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden 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. cheers luigi ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Vector Packet Processing (VPP) portability on FreeBSD
On Thu, May 13, 2021 at 1:27 PM Francois ten Krooden wrote: > > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > 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. Then try to instrument the code and see how many packets you are getting on every RXSYNC system call. If the value is mostly/always 0-1 then there is some bug with the (user) code that frees slots in the queue. cheers luigi > > Will try and see if I can find anything interesting there. > > > > > cheers > > luigi > > > > > > 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 -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Vector Packet Processing (VPP) portability on FreeBSD
On Thu, May 13, 2021 at 2:57 PM Luigi Rizzo wrote: > > On Thu, May 13, 2021 at 1:27 PM Francois ten Krooden wrote: > > > > > > On Thursday, 13 May 2021 13:05 Luigi Rizzo wrote: > > > > > > On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden > > > 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. > > Then try to instrument the code and see how many packets > you are getting on every RXSYNC system call. > > If the value is mostly/always 0-1 then there is some bug > with the (user) code that frees slots in the queue. Or another issue could be that your application spends too much time to process packets, so the bottleneck is user processing. The thing to monitor would be the time between system calls, divided by the number of packets processed in between .. ioctl(RXSYNC); t1 = get_nanoseconds(); n = t2 = get_nanoseconds() time_per_packet = (t2 - t1) / n; ioctl(RXSYNC); ... cheers luigi ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255430] ng_bridge don't sends broadcast packet to first found link in case of error in other links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255430 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a56e5ad6903037861457da754574b4903dcb0e7e commit a56e5ad6903037861457da754574b4903dcb0e7e Author: Lutz Donnerhacke AuthorDate: 2021-04-27 07:49:50 + Commit: Lutz Donnerhacke CommitDate: 2021-05-13 19:49:20 + netgraph/ng_bridge: Handle send errors during loop handling If sending out a packet fails during the loop over all links, the allocated memory is leaked and not all links receive a copy. This patch fixes those problems, clarifies a premature abort of the loop, and fixes a minory style(9) bug. PR: 255430 Submitted by: Dancho Penev Tested by: Dancho Penev MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D30008 sys/netgraph/ng_bridge.c | 55 ++-- 1 file changed, 30 insertions(+), 25 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255430] ng_bridge don't sends broadcast packet to first found link in case of error in other links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255430 Lutz Donnerhacke changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255421] alc(4): Qualcomm Atheros QCA8172 fails get DHCP IP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255421 Kubilay Kocak changed: What|Removed |Added Status|New |Open CC||yong...@freebsd.org Component|misc|wireless Keywords||needs-qa Flags||maintainer-feedback?(yongar ||i...@freebsd.org) Summary|alc0: Qualcomm Atheros |alc(4): Qualcomm Atheros |QCA8172 failed get DHCP IP |QCA8172 fails get DHCP IP --- Comment #1 from Kubilay Kocak --- Thank you for your report. Could you please include: - /var/run/dmesg.boot output (as an attachment) - pciconf -lv output (as an attachment) - /etc/rc.conf contents (as an attachment) - Any relevent errors from /var/log/messages (as an attachment) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255421] alc(4): Qualcomm Atheros QCA8172 fails get DHCP IP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255421 Kubilay Kocak changed: What|Removed |Added CC||n...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255430] ng_bridge don't sends broadcast packet to first found link in case of error in other links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255430 Kubilay Kocak changed: What|Removed |Added Resolution|FIXED |--- URL||https://reviews.freebsd.org ||/D30008 Flags||mfc-stable13?, ||mfc-stable12? Status|Closed |In Progress --- Comment #6 from Kubilay Kocak --- ^Triage: Re-open pending MFC -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255596] ifconfig: Panic when adding existing interface with inet address to vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255596 Kubilay Kocak changed: What|Removed |Added Summary|ifconfig move interface |ifconfig: Panic when adding |with inet address to vnet |existing interface with |jail panics kernel |inet address to vnet jail Flags||mfc-stable13?, ||mfc-stable12? Keywords|panic |crash, needs-qa Status|New |Open -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: Vector Packet Processing (VPP) portability on FreeBSD
On Tue, May 11, 2021 at 12:43:10PM +, Francois ten Krooden wrote: > > On Tue, May 11, 2021 at 12:43:10PM +, Francois ten Krooden wrote: > > On Monday, 10 May 2021 16:10 Konstantin Belousov wrote: > > > > > > > On Mon, May 10, 2021 at 11:08:18AM +, Francois ten Krooden > wrote: > > > > 3. What are suitable alternatives for reading information from > > > > procfs and > > > sysfs on FreeBSD? > > > Understand what information is obtained, then what for is it > > > actually used, then match it against equivalent FreeBSD approach, > > > then gather the required information. > > > > Thank you. This was basically what we suspected. > > One of the ones we are unsure about is what the equivalent of > /proc/self/pagemap on Linux would be. > > The one idea we had is using procstat_getvmmap from libprocstat, but > haven't finished investigating yet. > > I believe DPDK's libeal uses /proc/pagemap to look up the physical address > of large page mappings. Assuming you want to do the same thing, there is > the MEM_EXTRACT_PADDR /dev/mem ioctl. It was added specifically for > DPDK. See the mem(4) man page for details on its usage. > Thank you Mark. Will have a look at that. Regards Francois 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-unsubscr...@freebsd.org"
RE: Vector Packet Processing (VPP) portability on FreeBSD
On 2021/05/11 16:27, Jim Thompson wrote: > > > On May 11, 2021, at 7:04 AM, Mark Johnston wrote: > > > > On Tue, May 11, 2021 at 12:43:10PM +, Francois ten Krooden wrote: > >> On Monday, 10 May 2021 16:10 Konstantin Belousov wrote: > >> > >> > >>> On Mon, May 10, 2021 at 11:08:18AM +, Francois ten Krooden > wrote: > 3. What are suitable alternatives for reading information from > procfs and > >>> sysfs on FreeBSD? > >>> Understand what information is obtained, then what for is it > >>> actually used, then match it against equivalent FreeBSD approach, > >>> then gather the required information. > >> > >> Thank you. This was basically what we suspected. > >> One of the ones we are unsure about is what the equivalent of > /proc/self/pagemap on Linux would be. > >> The one idea we had is using procstat_getvmmap from libprocstat, but > haven't finished investigating yet. > > > > I believe DPDK's libeal uses /proc/pagemap to look up the physical > > address of large page mappings. Assuming you want to do the same > > thing, there is the MEM_EXTRACT_PADDR /dev/mem ioctl. It was added > > specifically for DPDK. See the mem(4) man page for details on its > > usage. > > Upthread mentioned Netgate (we do pfSense) as being possibly involved in > a port of VPP to FreeBSD. We do have some interest, and I had once handed > this to a contractor, but not much progress was made, and we had our hands > full with pfSense and our VPP-based product (tnsr). VPP has been discussed > on freebsd-net before. > > You and your team have made it much farther. > > I’d spoken to the VPP ‘core team’ about the sustainability of a port of VPP to > FreeBSD, and they didn’t say ’No’. The lead VPP person at Cisco used to be a > FreeBSD src committer, and he basically said, “Patches welcome”. > Someone will probably want to bring CSIT along to help prevent regressions > on FreeBSD, but that team also seemed open when I checked. > > IMO, netmap seems a better approach on FreeBSD, as you’ll eventually want > something like the ‘router plugin’ to be able to communicate between the > kernel and VPP, obtain FIBs, etc. > We’ve been strong proponents of (and a main contributor to) the ‘linux-cp” > plugin, (a better version of the router plugin, partially upstreamed to VPP), > but it’s based on netlink, and is has more linux-isms than the main body of > VPP. Netmap has a very nice architecture for building something similar, > where packets can be directly sent to and received from the host rings by > VPP, and these host rings are associated with an interface ring. Netmap-fwd > uses this to good effect. > > Netmap is slightly slower in maximum PPS than DPDK, but for your use case > (IPsec), you won't see a difference (assuming some things when I say this.) > > Jim Thank you for the feedback Jim. It is appreciated. Will have a look. I might have some questions about who to contact when we reach a point where we think it can be upstreamed to VPP. Regards Francois 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-unsubscr...@freebsd.org"
