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

[John-Mark Gurney]

Mike Silbersack wrote this message on Fri, Mar 18, 2005 at 02:48 -0600:
> 
> On Fri, 18 Mar 2005, John-Mark Gurney wrote:
> 
> >>I'm confused - don't sparc64 and alpha have similar alignment
> >>requirements?  Why does arm require code changes?
> >
> >yes, the alignment constraints for arm are the same.. the reason I
> >said the above is only for arm is the epe driver (which is only on
> >an ARM core) has been made to use the new feature...
> >
> >The changes to ip_input.c will work with other drivers as well... it
> >just needs to make sure that the proper defines are in amd64 and i386
> >so that we don't do the fix up when we don't need to...
> >
> >-- 
> > John-Mark Gurney				Voice: +1 415 225 5579
> 
> Ok, I see what you're saying now, I had forgotten the #ifdef i386 sections 
> we have scattered throughout the network drivers.  When I read your 
> original commit, I was thinking about the transmit paths in drivers, which 
> is why m_copyup made no sense to me.
> 
> 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

     "All that I will do, has been done, All that I have, has not."