changes to make ethernet packets able to be unaligned...

[Mike Silbersack]

On Fri, 18 Mar 2005, John-Mark Gurney wrote:

>> Moving the alignment out of the drivers and into a common place seems like
>> a good idea, but I wonder if it should be done in the ethernet code
>> instead of in the ip code; won't other protocols have unaligned access
>> problems if the change is made exactly as is?
>
> Why force it on the protocols that might not need it?
>
> We don't know how much of the ip or foo header to bring in at the
> ethernet layer, so the ip or foo layer might have to bring in more data...
>
> IMO, it's the protocol's job to ensure that it has correct alignment
> to access the data...  what happens when a protocol comes along that
> requires the packet to be 8byte aligned? and the ethernet layer only
> aligned it on a 4byte boundary?  should we add a third mbuf to it?
>
> -- 
>  John-Mark Gurney				Voice: +1 415 225 5579

Well, right now most (all?) drivers handle the alignment issue, so moving 
the alignment step into the ethernet code would centralize it in one 
place, and would not break anything.  Removing the alignment requirement 
without actually having tested all the protocols is going to break 
something.  Having the protocols handle alignment themselves is a good 
goal, but that's a second step you can take later.

I don't see why any extra mbuf allocation should be necessary if the 
alignment is done inside the ethernet code, actually.  Once you strip the 
ethernet header off, you can just slide the rest of packet backwards by 
two bytes, in place.

Mike "Silby" Silbersack