Stephan von Krawczynski wrote: > I can confirm that the setup seems to work if enlarging the hw if mtu > to 1508. This is good.
Okay, good to hear. > 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. Unfortunately that would require us to currently allocate 16kB for every receive descriptor, which would slow down the general case significantly, not to mention bring up all sorts of errors as the system memory fragmentation increases. > If I enlarge the basic mtu this may or may not have drawbacks > concerning the traffic routed directly via this interface. I think that routed traffic won't care at all unless something checks the path MTU, and even then it should take the lowest MTU. > Obviously the setup is somehow not consistent, as everything > works well without tuning mtus as long as you use only 1 tag. 1 tag is the way that things are supposed to work. In fact, the hardware takes care of all insertion and stripping of a single tag, so that the data actually handed to the stack never even has the tag in the packet data. > 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? Actually I think that first statement isn't correct. With the stacked setup your maximum frame length is 1500 (MTU) + 14 enet + 4 (tag1) + 4 (tag2) + CRC = 1526. The vlan code with stacked vlans is broken (from the maintainer who mentioned it in this thread) probably because in order to do stacked vlans correctly the vlan layer must support IP fragmentation of some kind. Seems like stacked vlans wouldn't work anyway, at least not very well. The only way I see to get even close is the MTU increase on the base interface. Sorry to not offer much, Jesse - 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
