netdev
[Top] [All Lists]

Re: conflicting alignment requirements

To: Ralf Baechle <ralf@xxxxxxxxxxx>
Subject: Re: conflicting alignment requirements
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 01 Aug 2001 08:43:39 -0700
Cc: kuznet@xxxxxxxxxxxxx, Jacob Avraham <jacoba@xxxxxxxxx>, netdev@xxxxxxxxxxx
Organization: Candela Technologies
References: <EJEHILNJPONOHGEOJKICAEDDCAAA.jacoba@xxxxxxxxx> <200107311712.VAA04463@xxxxxxxxxxxxx> <20010801043638.A17397@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Ralf Baechle wrote:
> 
> On Tue, Jul 31, 2001 at 09:12:22PM +0400, kuznet@xxxxxxxxxxxxx wrote:
> 
> > > copy the packet to a fresh skb (rx_copybreak = 0), the packet will
> > > traverse the net layer with unalinged IP header.
> >
> > Doing this for an arch which traps wrong alignment, you can expect
> > everything (except for crash, which could be bug).
> 
> Afaik all such architectures have exception handlers to complete the access
> transparently in software.  Such an access is very slow so where more
> frequent unaligned accesses are expected there are get_unaligned() and
> put_unaligned().

I was recently asked to remove the get/put_unaligned code from my
VLAN patch, which I did.  However, I don't want to now pay a
performance penalty on Sparc, or whatever...

So, what are the drawbacks of using get/put_unaligned?  If it's a
Macro, it could be defined to do very little extra work on architectures
that can handle un-aligned access, which might fix the common case, and
yet still be faster than catching the trap on other hardware architectures??

Thanks,
Ben

> 
>   Ralf

-- 
Ben Greear <greearb@xxxxxxxxxxxxxxx>          <Ben_Greear@xxxxxxxxxx>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

<Prev in Thread] Current Thread [Next in Thread>