Date: Tue, 08 Jul 2003 08:19:15 -0700 From: Sam Leffler <sam@errno.com> To: Garrett Wollman <wollman@lcs.mit.edu>, Bill Paul <wpaul@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_vlan.c Message-ID: <690828498.1057652355@melange.errno.com> In-Reply-To: <200307080101.h6811sTT018888@khavrinen.lcs.mit.edu> References: <200307071845.h67Ij1N1016542@khavrinen.lcs.mit.edu> <20030707234511.3B0FB37B401@hub.freebsd.org> <200307080101.h6811sTT018888@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Mon, 7 Jul 2003 16:45:11 -0700 (PDT), wpaul@FreeBSD.ORG (Bill Paul) > said: > >> 1) Change vlan_input() to apply EVL_VLANOFTAG() to all incoming tags >> (in both hardware and non-hardware tagging cases) and change the >> vlan_ioctl() function to only accept vlan tags from 0 to 4095 >> and return EINVAL if the caller tries to set any of the other >> bits. (Prevent user from shooting self in foot.) > > I believe that this is the correct choice. (It's probably a result of > my stupidity that the vlan driver didn't do this already.) > > At some point we should do something sensible with the other bits, > too. In some applications it might be useful to allow the user to > configure the .1p priority bits, outside of a VLAN context. (We > should be able to at least decode frames that arrive with .1p > encapsulation but .1Q tag 0.) > I need/want these bits for the Atheros driver which has multi-q h/w support for QOS. I haven't had the time to look at a general solution for dealing with this within the network stack. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?690828498.1057652355>