svn commit: r257455 - head/sys/net

[Ian Lepore]

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.

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.

-- Ian