[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101022084052.GA2118@verge.net.au>
Date: Fri, 22 Oct 2010 10:41:26 +0200
From: Simon Horman <horms@...ge.net.au>
To: David Miller <davem@...emloft.net>
Cc: mst@...hat.com, eric.dumazet@...il.com, netdev@...r.kernel.org,
johann.baudy@...-log.net
Subject: Re: [PATCH] af_packet: account for VLAN when checking packet size
On Tue, Oct 12, 2010 at 10:40:32AM -0700, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> Date: Tue, 12 Oct 2010 19:19:41 +0200
>
> > Yes, like eth_type_trans does I guess. I think we had a similar
> > discussion already:
> >
> > http://lists.openwall.net/netdev/2010/01/06/38
> >
> > Summary: if we want to make the protocol field have the correct
> > value for this case we need to make it work for other
> > transports not just for ethernet.
>
> Right, so for now we should just allow 4-byte larger
> than MTU TX packets, as long as the device is ethernet
> and can handle VLANs properly.
Incidently, I believe that this problem will only become more acute
and complex if support for 802.1ad (Provider Bridges, aka Q-in-Q),
802.1ah (Provider Backbone Bridges, aka MAC-in-MAC) or other standards
which further extend the maximum frame size.
Dave, you were mentioning to me the other day that the kernel
already supports some notion of Q-in-Q (though its not 802.1ad).
Does the current implementation allow for frames > 1504 bytes?
Is that a complication to the change proposed here?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists