Re: Receiving Network Packets with Mirage/kFreeBSD

["Robert N. M. Watson" <robert.watson@xxxxxxxxxxxx>]

On 20 Aug 2012, at 22:59, PALI Gabor Janos wrote:

>> - Each packet arriving on any of the plugged interfaces is placed to the next
>>  available slot of the corresponding shared ring buffer with m_copydata().
> 
> I agree that m_copydata() involves a possibly unnecessary copying.  But it 
> also
> contributes to flattening the packets so Mirage can work with them without too
> much trickery.  I suppose intercepted packets should be turned into linear 
> memory
> buffers at some point.


My intuition is that, except in unusual and special situations, packets in the 
inbound path will always turn up contiguously stored in a buffer. The only real 
exceptions will be when odd encapsulations are used, when there is 
header-splitting, or perhaps during a transition to jumbogram use before a 
receive descriptor ring has been repopulated with larger buffer sizes. In the 
outbound path from the regular network stack, again it's probably only in 
situations with odd encapsulations or non-bulk sending patterns that this 
really comes up. The receive stream socket buffers have an algorithm for 
packing small packets but chaining large ones, and a very similar approach 
could be used here: if you get non-contiguous data, you can always "compress" 
it into dynamically allocated contiguous buffers -- in fact, you can ask the 
network stack to do this for you, but you can optimise for the contiguous case 
pretty reasonably. If you do end up seeing a lot of packets fragmented over 
non-contiguous buffers, it's probably due to a device driver or network stack 
bug, which should be fixed. :-)

Robert