On Mon, 28 Aug 2006 13:53:36 -0700 "Brandeburg, Jesse" <[EMAIL PROTECTED]> wrote:
> > I tried enlarging both real-device and first vlan interface mtu but > > that does not work out. I really thought that the visible device > > setting of mtu=1500 should have worked out and that the driver (or > > some code in between) should have corrected the allowed frame size to > > reflect the actual setup, not? > > unfortunately I believe that your hardware MTU on the base interface > MUST be adjusted in order to do stacked vlans because the vlan code > doesn't fragment packets, it just inserts tags. The e1000 hardware is > capable of inserting/stripping 1 level of tags without dropping overlong > frames, but cannot seamlessly handle 1+n levels of inserted tags. > Transmit, we don't care how long the frames are that are given to us > (the driver doesn't enforce MTU on transmit) but on receive we have > limited space so it is important that each frame fit into the allocated > buffer (including CRC). > > Please try MTU 1508 on eth0 (base interface only), as that configuration > worked for me. Hello Jesse, I can confirm that the setup seems to work if enlarging the hw if mtu to 1508. This is good. Nevertheless I think that the receive buffer size of a physical device should always be MAX(all virtual device mtu + tags and the like), you know what I mean. If I enlarge the basic mtu this may or may not have drawbacks concerning the traffic routed directly via this interface. Obviously the setup is somehow not consistent, as everything works well without tuning mtus as long as you use only 1 tag. I always thought that the driver uses at least hard_header_len + mtu as buffer size which should be correct even in stacked setup. Only this information doesn't make it to the driver level, right? -- Regards, Stephan von Krawczynski - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
