svn commit: r257455 - head/sys/net

[Andre Oppermann]

On 31.10.2013 23:14, John-Mark Gurney wrote:
> Luigi Rizzo wrote this message on Thu, Oct 31, 2013 at 22:13 +0100:
>> On Thu, Oct 31, 2013 at 01:49:16PM -0700, John-Mark Gurney wrote:
>>> Luigi Rizzo wrote this message on Thu, Oct 31, 2013 at 21:05 +0100:
>>>> 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)
>>>
>>> my idea has been to make a change to the various ip/tcp/udp layers
>>> that is dependant upon __NO_STRICT_ALIGNMENT and if we do require
>>> strict alignment to copy the header to a stack buffer to align the
>>> data...
>>
>> I'd rather use accessors functions/macros to read/write
>> the unaligned headers so we can hide the #ifdefs in only
>> one place.
>
> I am/was trying to prevent massive code curn...
>
>> The copy to a stack buffer is probably useful even for readability
>
> Oh, I also realized I left out another part of it...
>
> void
> ip_input(struct mbuf *m)
> {
> #ifndef __NO_STRICT_ALIGNMENT
> 	struct ip tmpip;
> #endif
> 	struct ip *ip = NULL;
>
> #ifndef __NO_STRICT_ALIGNMENT
> 	bcopy(mtod(m, struct ip *), &tmpip, sizeof tmpip);
> 	ip = &tmpip;
> #else
> 	ip = mtod(m, struct ip *);
> #endif

Still massive code churn for all protocols above layer 3.

> }
>> regardless of alignment (i do this in ipfw so i parse the
>> packet only once, and those values are used often),
>> but we should be careful to keep the copy in
>> sync with the original in places where those headers are modified
>> (NAT, ipfw fwd, maybe somewhere else ?)
>
> If you modify the packet, you need to be careful to write back the
> data when needed, i.e. passing the mbuf to another layer or
> returning..  But that isn't anything too different than other
> functions...

Since the beginning and continuing the direct structure casting has
been the way to access protocol data.  Completely changing this
would be a very big change requiring a throughout audit of the kernel.

> Looks like I'll have to revive my TS-7200 port for testing as npe on
> AVILA apparently can handle the slightly odd alignment...

Architectures that have trouble with unaligned access should only
be used with RX DMA engines that can 16bit align their writes. ;)
Then it's only a call to m_adj before the mbuf is mapped into the
RX ring and you're good.

-- 
Andre