Fwd: netmap-ipfw on em0 em1
Clarifying things for the sake of documentation: To use the host stack, append a ^ character after the name of the interface you want to use. (Info from netmap(4) shipped with FreeBSD 10.1 RELEASE.) Examples: kipfw em0 does nothing useful. kipfw netmap:em0 disconnects the NIC from the usual data path, i.e., there are no host communications. kipfw netmap:em0 netmap:em0^ or kipfw netmap:em0+ places the netmap-ipfw rules between the NIC and the host stack entry point associated (the IP addresses configured on it with ifconfig, ARP and RARP, etc...) with the same NIC. On 10 November 2014 at 18:29, Evandro Nunes evandronune...@gmail.com wrote: dear professor luigi, i have some numbers, I am filtering 773Kpps with kipfw using 60% of CPU and system using the rest, this system is a 8core at 2.4Ghz, but only one core is in use in this next round of tests, my NIC is now an avoton with igb(4) driver, currently with 4 queues per NIC (total 8 queues for kipfw bridge) i have read in your papers we should expect something similar to 1.48Mpps how can I benefit from the other CPUs which are completely idle? I tried CPU Affinity (cpuset) kipfw but system CPU usage follows userland kipfw so I could not set one CPU to userland while other for system All the papers talk about *generating* lots of packets, not *processing* lots of packets. What this netmap example does is processing. If someone really wants to use the host stack, the expected performance WILL BE worse - what's the point of using a host stack bypassing tool/framework if someone will end up using the host stack? And by generating, usually the papers means: minimum sized UDP packets. can you please enlighten? For everyone: read the manuals, read related and indicated materials (papers, web sites, etc), and, as a least resource, read the code. Within netmap's codes, it's more easy than it sounds. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Problem reports for freebsd-net@FreeBSD.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- New |197535 | [re] [panic] if_re (Realtek 8168) causes memory w Open|199136 | [if_tap] Added down_on_close sysctl variable to t 2 problems total for which you should take action. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 193743] [re] RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193743 Sean Bruno sbr...@freebsd.org changed: What|Removed |Added CC||sbr...@freebsd.org Status|New |Closed Resolution|--- |FIXED --- Comment #4 from Sean Bruno sbr...@freebsd.org --- This has been committed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 156667] [em] em0 fails to init on CURRENT after March 17
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156667 mar...@blazingdot.com changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 199174] em tx and rx hang
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #11 from Sean Bruno sbr...@freebsd.org --- Did a couple of tests via iperf. test 1 #1 set hw.em.txd=4096 #2 set hw.em.rxd=4096 #3 ran with TSO enabled -- ran into hangs and debug output from watchdog as reporter and stated. -- seems to happen less frequently, once in 24 hour test test 2 #1 setup as test 1 #2 disable TSO (ifconfig em0 -tso) -- no hangs in 24 hours test test 3 #1 set hw.em.txd=256 #2 set hw.em.rxd=256 #3 reboot and leave TSO enabled -- ran into hangs and debug out from watchdog in minutes Hypothesis: -- TSO implementation isn't taking into consideration ring wrap events? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Fwd: netmap-ipfw on em0 em1
On Sun, May 3, 2015 at 6:17 PM, Barney Cordoba via freebsd-net freebsd-net@freebsd.org wrote: Frankly I'm baffled by netmap. You can easily write a loadable kernel module that moves packets from 1 interface to another and hook in the firewall; why would you want to bring them up into user space? It's 1000s of lines of unnecessary code. Because it is much faster. The motivation for netmap-like solutions (that includes Intel's DPDK, PF_RING/DNA and several proprietary implementations) is speed: they bypass the entire network stack, and a good part of the device drivers, so you can access packets 10+ times faster. So things are actually the other way around: the 1000's of unnecessary lines of code (not really thousands, though) are those that you'd pay going through the standard network stack when you don't need any of its services. Going to userspace is just a side effect -- turns out to be easier to develop and run your packet processing code in userspace, but there are netmap clients (e.g. the VALE software switch) which run entirely in the kernel. cheers luigi On Sunday, May 3, 2015 3:10 AM, Raimundo Santos rait...@gmail.com wrote: Clarifying things for the sake of documentation: To use the host stack, append a ^ character after the name of the interface you want to use. (Info from netmap(4) shipped with FreeBSD 10.1 RELEASE.) Examples: kipfw em0 does nothing useful. kipfw netmap:em0 disconnects the NIC from the usual data path, i.e., there are no host communications. kipfw netmap:em0 netmap:em0^ or kipfw netmap:em0+ places the netmap-ipfw rules between the NIC and the host stack entry point associated (the IP addresses configured on it with ifconfig, ARP and RARP, etc...) with the same NIC. On 10 November 2014 at 18:29, Evandro Nunes evandronune...@gmail.com wrote: dear professor luigi, i have some numbers, I am filtering 773Kpps with kipfw using 60% of CPU and system using the rest, this system is a 8core at 2.4Ghz, but only one core is in use in this next round of tests, my NIC is now an avoton with igb(4) driver, currently with 4 queues per NIC (total 8 queues for kipfw bridge) i have read in your papers we should expect something similar to 1.48Mpps how can I benefit from the other CPUs which are completely idle? I tried CPU Affinity (cpuset) kipfw but system CPU usage follows userland kipfw so I could not set one CPU to userland while other for system All the papers talk about *generating* lots of packets, not *processing* lots of packets. What this netmap example does is processing. If someone really wants to use the host stack, the expected performance WILL BE worse - what's the point of using a host stack bypassing tool/framework if someone will end up using the host stack? And by generating, usually the papers means: minimum sized UDP packets. can you please enlighten? For everyone: read the manuals, read related and indicated materials (papers, web sites, etc), and, as a least resource, read the code. Within netmap's codes, it's more easy than it sounds. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- -+--- 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 http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Fwd: netmap-ipfw on em0 em1
Frankly I'm baffled by netmap. You can easily write a loadable kernel module that moves packets from 1 interface to another and hook in the firewall; why would you want to bring them up into user space? It's 1000s of lines of unnecessary code. On Sunday, May 3, 2015 3:10 AM, Raimundo Santos rait...@gmail.com wrote: Clarifying things for the sake of documentation: To use the host stack, append a ^ character after the name of the interface you want to use. (Info from netmap(4) shipped with FreeBSD 10.1 RELEASE.) Examples: kipfw em0 does nothing useful. kipfw netmap:em0 disconnects the NIC from the usual data path, i.e., there are no host communications. kipfw netmap:em0 netmap:em0^ or kipfw netmap:em0+ places the netmap-ipfw rules between the NIC and the host stack entry point associated (the IP addresses configured on it with ifconfig, ARP and RARP, etc...) with the same NIC. On 10 November 2014 at 18:29, Evandro Nunes evandronune...@gmail.com wrote: dear professor luigi, i have some numbers, I am filtering 773Kpps with kipfw using 60% of CPU and system using the rest, this system is a 8core at 2.4Ghz, but only one core is in use in this next round of tests, my NIC is now an avoton with igb(4) driver, currently with 4 queues per NIC (total 8 queues for kipfw bridge) i have read in your papers we should expect something similar to 1.48Mpps how can I benefit from the other CPUs which are completely idle? I tried CPU Affinity (cpuset) kipfw but system CPU usage follows userland kipfw so I could not set one CPU to userland while other for system All the papers talk about *generating* lots of packets, not *processing* lots of packets. What this netmap example does is processing. If someone really wants to use the host stack, the expected performance WILL BE worse - what's the point of using a host stack bypassing tool/framework if someone will end up using the host stack? And by generating, usually the papers means: minimum sized UDP packets. can you please enlighten? For everyone: read the manuals, read related and indicated materials (papers, web sites, etc), and, as a least resource, read the code. Within netmap's codes, it's more easy than it sounds. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
