svn commit: r257455 - head/sys/net

Andre Oppermann andre at freebsd.org
Thu Oct 31 22:29:31 UTC 2013


On 31.10.2013 21:15, Ian Lepore wrote:
> On Thu, 2013-10-31 at 21:05 +0100, Luigi Rizzo wrote:
>> On Thu, Oct 31, 2013 at 01:27:25PM -0600, Ian Lepore wrote:
>> ...
>>> Is there any chance all this reworking might get us to a position where
>>> the protocol header in an mbuf doesn't have to be 32-bit aligned
>>> anymore?  We pay a pretty heavy price for that requirement in the
>>> drivers of the least capable hardware we support, the systems that have
>>> the least horsepower to spare to make an extra copy of each packet to
>>> realign it.
>>
>> So are you suggesting to use some 'copy_unaligned_32()' function/macro to
>> access 32-bit protocol fields in the network stack ?
>> (16-bit entries should not be an issue)
>>
>> cheers
>> luigi
>
> Or if not that (I have no idea how frequently those fields are accessed
> and what the performance penalty would be on systems moving a LOT of
> packets), then a compromise might be a flag the driver can set to say it
> may provide unaligned incoming packets.  Then we could have common code
> at just one place in the network stack to split the mbuf and
> realign-copy just the protocol header part to a new mbuf and attach it
> to the front of the chain.  That would minimize both duplicated code and
> the amount of data that has to be copied, and would put knowledge like
> "how big is the protocol header that needs copying?" in a place that
> knows more about protocols.

This is a sensible idea and in fact how some of the drivers already do
it internally for strict alignment architectures.

> I know pretty much nothing about what happens in the network stack after
> I feed a packet to if_input(), so maybe this is all impractical.  But I
> also know that ARM systems with strict alignment constraints spend a lot
> of time copying the entire contents of every incoming packet to realign
> it, and it would be a lot better if they were able to DMA directly into
> an mbuf cluster that can handed up the stack.  Even if "copy the entire
> packet" is the only thing if_input() could do, there might still be some
> benefit in having one common piece of code for it.

We have tons of protocols using direct structure casting into the mbuf
payload.  Changing them all would be a huge task and in many cases also
change the way the code is structured.

-- 
Andre



More information about the svn-src-all mailing list