[PATCH] Part 2 of low level 802.1p priority support

[Bruce M. Simpson]

Andrew Thompson wrote:
> This is great for the bridge, it has needed to take the vlan tag into
> account when deciding to forward or not. Having m_pkthdr.ether_vtag
> always set makes this much easier to implement.
>   
> In the deleted code M_VLANTAG is cleared but is not done anymore, is
> this right?
>   
Correct. The vlan(4) code as it currently stands consumes M_VLANTAG 
(though as its allocation has been moved into the mbuf header itself, 
there is no additional free needed -- it's not a deep allocation).

The patch moves the M_VLANTAG handling into ether_demux() (it should 
probably move further down to ether_input()) and always sets M_VLANTAG 
if we got raw 802.1q frames from the NIC (!(ifcap & VLAN_HWTAG) 
situation), so that we can deal with VLAN 0 in a clean way in ether_demux().

This may be a slight pessimization, but we always knew that cards which 
don't deal with 802.1q in hardware cause a performance hit anyway -- 
this just means that they will at least be able to process packet 
priorities!

M_VLANTAG then may be passed to upper layers, providing they either 
ignore its presence or do something useful with it. In the case of ALTQ 
we'd examine the priority field in the 802.1q tag to map Layer 2 Quality 
of Service to ALTQ rules.

These changes really need to be considered together with M_PROMISC. 
NetBSD did this presumably to stop the madness we have in ether_demux() 
to deal with the situation of stacked software Ethernet devices (vlan, 
bridge, agr, etc); M_PROMISC gets set for frames coming in off the card 
which we wouldn't have received had we not been in IFF_PROMISC. 'I am a 
hub, not a switch'. It's not smart enough to drop M_MCASTs we didn't ask 
for, it will blindly tag those also.

Both of these changes use mbuf flags, not tags, because tags have a 
higher cost. M_PROMISC is also used in NetBSD to stop the IP forwarding 
paths seeing promiscuous traffic. Throw a wi(4) PRISM2 card into a 
laptop and set up OSPF+DVMRP on the same FreeBSD kernel and you'll see 
what I mean.

We have checks in our code which only deal with that if there's a 
vlan(4) configured on top of your NIC...

BMS