Date: Thu, 5 Feb 2015 12:08:31 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Scott Long <scott4long@yahoo.com> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Silly experiments with netisr Message-ID: <CAJ-Vmo=Vb4ngvskLTLs9Rchm_uc2pYg%2BAJ-wsHRf_WyhqDxEgg@mail.gmail.com> In-Reply-To: <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com> References: <54D3BE67.8060502@ignoranthack.me> <752D84FB-0B65-47CF-973A-91C3697A28DC@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 February 2015 at 11:31, Scott Long via freebsd-net <freebsd-net@freebsd.org> wrote: > >> On Feb 5, 2015, at 12:03 PM, Sean Bruno <sbruno@ignoranthack.me> wrote: >> >> >> Signed PGP part >> Some questions came up around the office and we ended up doing some >> quite silly things with lo0 and netcat. >> >> If one runs a continuous netcat on localhost to another netcat listener >> on localhost that writes the output to /dev/null, netisr gets super busy >> doing stuff/things. >> >> E.g. >> -- listener running "nc -k -l 10000 > /dev/null" >> - sender running in a while loop "nc -N localhost 10000 < >> /var/tmp/testfile" >> >> Interesting things start happening on the machine. top -SH shows netisr >> eating up about 1/2 of a cpu core. If you drop the MTU on lo0 to 1500 >> (so that it looks like something in the real world), netisr will peg out >> a cpu core. This seems logical, in that smaller MTU means busier >> netisr. Its interesting though. >> >> Looking at some pmcstat things, shows that the system is busilly >> chugging along in tcp_do_segment(). I wonder if this is meaningful in >> anyway or just "interesting". > > > Welcome to our workload. Granted, we don=E2=80=99t involve pf, but the m= ajority of our CPU processing right now is spent in TCP (with the rest bein= g spent in the VM, but that=E2=80=99s a different matter). > > FWIW, Randall has some optimizations in this area of the stack. They are= n=E2=80=99t huge, IIRC they=E2=80=99re only a few percent, but worth lookin= g at. Yeah, I see that too in all the TCP concurrency testing I'm doing. The moment TCP TSO drops in effectiveness in any way, the cost of tcp_do_segment() jumps dramatically. :( -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=Vb4ngvskLTLs9Rchm_uc2pYg%2BAJ-wsHRf_WyhqDxEgg>