> The speed benefit comes from switching to a stack mbuf except in the
> case of errors, right?
I have worried about this diff since the first time seeing it. if
anyone ever makes a mistake in this code-path, and sends that mbuf out
into the wild, it will be an "un-managed" mbuf. by managed, i m
On Fri, Jun 22, 2012 at 04:58, Brad Smith wrote:
> On Thu, Mar 01, 2012 at 03:28:13PM +0100, Mike Belopuhov wrote:
>> This is a well-known from thib and dlg originally with a length fix
>> from yours truly, that marginally doubles througput (from 300kpps to
>> 500-600kpps on selected hardware).
>>
On Thu, Mar 01, 2012 at 03:28:13PM +0100, Mike Belopuhov wrote:
> This is a well-known from thib and dlg originally with a length fix
> from yours truly, that marginally doubles througput (from 300kpps to
> 500-600kpps on selected hardware).
>
> The idea is to save an IP header and 8 bytes of payl
This is a well-known from thib and dlg originally with a length fix
from yours truly, that marginally doubles througput (from 300kpps to
500-600kpps on selected hardware).
The idea is to save an IP header and 8 bytes of payload (good enough
for tcp state tracking) instead of recommended 68 bytes.
