Date: Mon, 17 Sep 2012 16:16:27 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-net@freebsd.org, Ryan Stone <rysto32@gmail.com> Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? Message-ID: <CAJ-VmoksUJBX507rOWD8%2B1ZRD1xjEBQvRZFmdnHNxpGeVRJF3w@mail.gmail.com> In-Reply-To: <201209171503.12517.jhb@freebsd.org> References: <CAFMmRNzkwbQpUZ3OOoMKVdrz=dePc5fkeX3m-5vXtiWJ7qXwVA@mail.gmail.com> <201209171316.45029.jhb@freebsd.org> <CAJ-Vmon1iHpjx37=RDOqFPthLv5nTTyjmkOR246nBQ4VxwhVOA@mail.gmail.com> <201209171503.12517.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
There's a lot less cache in these boards. Going through the stack trace all the way and back for each packet is actually quite expensive. Then there's the overhead of having if_start() be called multiple times, concurrently, from multiple senders. It's fine for a wifi AP setup where the if_start() is only called once or twice in an overlapping fashion, but sucks with lots of concurrent TCP/UDP contexts all potentially calling if_start() and having them have to clash with each other. I've not sat down and instrumented it all that much, so I'm going to spend much time harping on about it until I have some hard numbers either way. I'm just going by what I see people do to various network stacks when it comes time to try and squeeze high packet rates out of smaller platforms, especially with NAT/bridging/PPPoE in the way. And that tended not to be "complete packet to completion on each frame." adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmoksUJBX507rOWD8%2B1ZRD1xjEBQvRZFmdnHNxpGeVRJF3w>