Date: Fri, 7 Mar 2003 14:57:05 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: tlambert2@mindspring.com, current@freebsd.org Subject: Re: mbuf cache Message-ID: <200303072057.h27Kv5FZ074080@mail.flugsvamp.com> In-Reply-To: <local.mail.freebsd-current/3E68ECBF.E7648DE8@mindspring.com> References: <local.mail.freebsd-current/0ded01c2e295$cbef0940$932a40c1@PHE> <local.mail.freebsd-current/20030304164449.A10136@unixdaemons.com> <local.mail.freebsd-current/0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <local.mail.freebsd-current/20030304173809.A10373@unixdaemons.com> <local.mail.freebsd-current/0e2b01c2e2a3$96fd3b40$932a40c1@PHE> <local.mail.freebsd-current/20030304182133.A10561@unixdaemons.com> <local.mail.freebsd-current/0e3701c2e2a7$aaa2b180$932a40c1@PHE> <local.mail.freebsd-current/20030304190851.A10853@unixdaemons.com> <local.mail.freebsd-current/001201c2e2ee$54eedfb0$932a40c1@PHE> <local.mail.freebsd-current/20030307093736.A18611@unixdaemons.com> <local.mail.freebsd-current/008101c2e4ba$53d875a0$932a40c1@PHE>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/3E68ECBF.E7648DE8@mindspring.com> you write: >Petri Helenius wrote: >> > There's probably a tightloop of frees going on somewhere. It's tough >> > for me to analyze this as I cannot reproduce it. Have you tried >> > running your tests over loopback to see if the same thing happens? >> >> What is the definition of "tightloop"? The received packet mbufs are freed >> when the packets get processed/discarded which happens once for >> a packet. The received packet rate is 50000-150000 packets per second. >> > >> > If so, and it does, can you please explain how to exactly replicate >> > the test? >> >> Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable >> promisc and monitor so it drops the packets after interrupt processing. >> The overhead beyond that is neglible compared to mb_free. > >Ah. You are receiver livelocked. Try enabling polling; it will >help up to the first stall barrier (NETISR not getting a chance >to run protocol processing to completion because of interrupt >overhead); there are two other stall barriers after that, and >another in user space is possible depending on whether the >application layer is request/response. Actually, in -current, we now have a sysctl (net.isr.enable) that will switch the netisr from queuing into a direct dispatch mechanism. In other words, the packet is pushed all the way through the TCP stack to the socket buffer by the network card's interrupt. You can toggle it on and off at runtime, so you can play with it and see if there is any difference. My initial performance tests showed it to be a wash, but ttcp testing today shows it gives a 30% performance boost when run over a gigabit link. YMMV, I guess. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303072057.h27Kv5FZ074080>