em(4) patch

[Pyun YongHyeon]

On Sat, Apr 16, 2005 at 10:01:33AM -0700, John-Mark Gurney wrote:
 > Pyun YongHyeon wrote this message on Sat, Apr 16, 2005 at 09:46 +0900:
 > > On Fri, Apr 15, 2005 at 08:43:09AM -0700, John-Mark Gurney wrote:
 > >  > Sten Spans wrote this message on Fri, Apr 15, 2005 at 12:09 +0200:
 > >  > > >With your changes JUMBO frames work here. This should also fix PR75794.
 > >  > > >It would be really great if your changes could be comitted.
 > >  > > 
 > >  > > Let's not forget ipv6 please, it needs this fix too,
 > >  > > if the code is imported.
 > >  > 
 > >  > And netatalk, netipsec and netipx too will probably need these changes..
 > >  > 
 > >  > Another reason I haven't brought in the code quite yet...
 > > 
 > > Hmm, this means we have to patch all filrewalls(pf/ipfw/ipf), carp(4)
 > > and possibily netgraph(4) too. I'm afraid this is not right direction
 > > to go. Alignment fixup would be best served in ether_input or in driver
 > > layer which seems to be more appropriate place. Maybe this is the
 > > reason why OpenBSD have such a complex alignment code in em driver.
 > 
 > Please make sure you know the entire problem before you say it's no
 > the correct way to go... Drivers like re and vge have to copy up an
 > entire cluster (2k), just to make alignment correct...  It's even more
 > ugly than patching everyone to self align...
 > 
 > Also, IMO, it's the correct layer to put the fix up in each firewalls,
 > etc..  Because the driver should not magicly know that the upper layers
 > need an alignment.. Plus, what happens if someone happens to use foobar
 > which only needs 2 byte alignment... Why should we continue to fixup
 > packets on alignment constrained machines when this layer doesn't need
 > it?
 > 

Personally, I beleive all upper layers(> L2) assume its payload is
aligned correctly(maybe NFS is exception). So if lower layers give
no assurance on alignment it have to check whether it needs alignment
fixup(currently no such check exist and your m_copyup would handle
this transparently).
According to my experimentation your m_copyup works well. But this
means all protocol handlers should have this check too and I think
that is hard to maintain since there are so many places to add this
code.

AFAIK all firewalls can be run under bridge environments. In this
situation they need your alignment fixup code too. However if lower
layer(ethernet layer or driver layer) can provide alignment free
mbuf, there is no need to add a such alignment fixup code.
In addition, I believe we can avoid alignment fixup code for
architecures that allow non-aligned memory access in driver layer by
defining conditioanal compilation. Of course, driver layer does
not know that upper layers need an alignment. However I think almost
all protocols have designed to align 4 byte boundary so ethernet header
and its type field would be the only exception. If a protocol handler
need x byte alignment it should handle this in its protocol handler
since other parts of code assumes 4 byte boundary, IMO.

 > Hence why I am trying to get some performance measurements to see just
 > the performance difference the extra mbuf allocation makes over coping
 > data...
-- 
Regards,
Pyun YongHyeon
http://www.kr.freebsd.org/~yongari	|	yongari at freebsd.org