Re: Default QinQ behaviour for MTU and REORDER flag

Jean-Gr=E9goire Foulon wrote:
> Hello,
>=20
> I am currently working with multiple Vlan stacking and the behaviour of=
=20
> QinQ in the kernel is not always consistent. On some hardware I have to=
=20
> use set the reorder flag to 0 for the QinQ to be working, while on=20
> other, it just work whether this flag is 1 or 0.
> I tested with the Fedora core 7 (kernel 2.6.21) on the following machin=
es
> Dell PC with Intel Corporation 82540EM Gigabit Ethernet Controller (rev=
 02)
> Compaq laptop with Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C=
+=20
> (rev 10)
>=20


As I understand it the only reason you would set the reorder flag to 0 is
if you have two vlan devices, using the same VID, connected to a bridge.
E.g.

     br0
      |- eth0.10
      |- eth1.10

In this situation there's no need to strip the tags going up, or add tags=
 going
down because all the interfaces are tagged and have the same VID.  (Howev=
er, if
you wanted to connect br0 to the IP stack you would have to create br0.10=
 and
leave reordering enabled on *that* vlan device.)

In other situations, e.g.

     br0
      |- eth0.10
      |- eth1

or

     br0
      |- eth0.10
      |- eth1.11

you would need to leave reordering on for both vlan devices.

So disabling reordering saves a few clocks, but is only valid in a few ci=
rcumstances.

Someone please correct me if I've misunderstood this!


> On the Dell, I don't need to set the reorder flag to 0 but on the Compa=
q=20
> I need to do it.
> Another even stranger thing is that on kernel 2.6.9 I need to set the=20
> reorder flag to 0 if I want to stack 3 VLAN but I don't need to do it=20
> when I stack only 2 VLAN...
> What is the default behaviour ? Is there a bug for the support of one o=
f=20
> those network adapter ?
> is QinQ officially supported by the Linux kernel ? Someone posted a=20
> patch for 2.6.11, is it needed for 2.6.21 ?
>=20

A patch is still needed, but I've got no idea if the one I sent will stil=
l apply
cleanly to 2.6.21.  Try it out!


> The other problem I have is the fragmentation and MTU behaviour: the MT=
U=20
> of a vlan device is the same as the MTU of its ethernet device (1500 in=
=20
> my case), I think it should be less to reflect the size use by the vlan=
=20
> header, no ?
>=20
>=20
> When I use the command  "ping -t 2000 <ip address>":
> -on a network interface : it works
> -on a level 1 vlan: it works
> -on a level 2 or higher vlan: it fails
>=20
> When I use the command  "ping -t 1468 <ip address>":
> -on a network interface : it works
> -on a level 1 vlan: it works
> -on a level 2 vlan: it works
> -on a level 3 vlan: it fails
>=20
> When I use the command  "ping -t 1464 <ip address>":
> -on a network interface : it works
> -on a level 1 vlan: it works
> -on a level 2 vlan: it works
> -on a level 3 vlan: it works
>=20
> A level 3 vlan has a maximum packet size 4 bytes smaller than a level 2=
=20
> vlan.
> When I change the MTU manually the "ping -t 2000 <ip address>" command=20
> works on level 3 vlan, so it should make sense to reduce it when a VLAN=
=20
> device is created, no ?
> I am trying to modify a 2.4 kernel to do so, and it seems to work, may =
I=20
> by breaking something else ?

Some ethernet drivers implement a change_mtu() method, and use the MTU si=
ze passed
in (from ifconfig <dev> mtu <size>) to set the maximum rx frame size.  Ot=
hers
just have a fixed maximum rx frame size and leave it to the IP stack to p=
olice the
MTU sizes.

If a driver is not vlan aware it may set a fixed maximum rx frame size of=
 1518, or
- if it implements change_mtu() - a maximum rx frame size of mtu + 18.

If a driver *is* vlan aware it will add 4 to the above, as it knows that =
the frames
may have an extra 4 byte shim that gets stripped by the vlan layer before=
 the frame
enters the IP stack.

For a driver to be q-in-q aware it will need to add 4*(max q-in-q levels)=
.  I doubt
any drivers are q-in-q aware as q-in-q support isn't in the current kerne=
l.  You'll
probably have to hack'em.

>=20
> Regards,
>=20
> Jean-Gregoire
>=20

HTH,

Alex