Date: Thu, 31 Oct 2013 23:35:35 +0100 From: Andre Oppermann <andre@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Ian Lepore <ian@FreeBSD.org> Subject: Re: svn commit: r257455 - head/sys/net Message-ID: <5272DB37.6010801@freebsd.org> In-Reply-To: <20131031221457.GG58155@funkthat.com> References: <201310311546.r9VFkAIb049844@svn.freebsd.org> <20131031180336.GA62132@onelab2.iet.unipi.it> <5272AAC4.4030700@freebsd.org> <1383247645.31172.29.camel@revolution.hippie.lan> <20131031200502.GB83212@onelab2.iet.unipi.it> <20131031204916.GF58155@funkthat.com> <20131031211337.GA83561@onelab2.iet.unipi.it> <20131031221457.GG58155@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5272DB37.6010801>