Re: Re: Default QinQ behaviour for MTU and REORDER flag

[Alex Zeffertt <ajz@xxxxxxxxxxxxxxxxxxxxxx>]

Peter Stuge wrote:
> On Sat, Oct 20, 2007 at 09:18:52PM -0700, Stephen Hemminger wrote:
> > .. should have ..
> >
> > The current situation is that the device needs to allow rx of mtu +
> > possible vlan. An added problem for q-in-q is that many device
> > support some form of vlan offloading that puts the vlan tag in a
> > separate register (ie not part of the receive buffer).
>
> So what to do?

I have to admit I've never really looked at the API which allows
offload of VLAN reordering to the driver.  It seems to me to break the protocol
layering model. IMO the driver should ignore everything between the Source Address
and the FCS and just pass it up.

Yes, breaking this model by letting h/w do the reordering does confer a
performance boost, but in practice this will be tiny, and (IMHO) may not
be worth the extra complication.

Another reason to discard h/w offload is Q-in-Q.  Some drivers that can offload
VLAN header reordering to h/w, might not be modifiable to offload Q-in-Q
reordering because of h/w limitations.  Therefore in order to support Q-in-Q you'll
*have* to disable h/w offload.

Irrespective of this, I think it makes sense for the stack to police mtus and
for the driver API to include calls for requesting that a minimum rx frame size is
supported (and ditto for tx).  This would eliminate the need for driver hacking
whenever another layer is inserted between layers 2 and 3.

However, I've no idea how you get this change into the kernel.  And if it got in,
it would take a long time before the majority of net_device drivers supported it.

Just my two penneth.

Alex

_______________________________________________
Vlan mailing list
Vlan@xxxxxxxxxxxxxxx
http://www.candelatech.com/mailman/listinfo/vlan