[PATCH] Updated 802.1p/q patch

[Bruce M Simpson]

Yar Tikhiy wrote:
> Do you have any architectural reservations about nested VLANs in
> the main network stack?  Presently, a one-line patch can allow a
> vlan(4) to attach to another vlan(4), but I haven't heard about the
> behaviour of the resulting setup yet.
>   
After looking around it seems there is definite scope and demand for 
such a feature in scenarios such as ISP Metro Ethernet setups. However, 
we can't rely on M_VLANTAG alone to implement it. To do it we need to be 
sure of the following:

1. Output path in vlan(4) changes not to call ether_output_frame() 
directly if nested.
2. Output path in vlan(4) detects when it's going to re-enter the parent 
vlan(4), and makes sure the inner 802.1q header is expanded and inserted 
from M_VLANTAG before passing it down the stack.
3. That the drivers and cards out there can deal with Q-in-Q.
4. That the input path only extracts and applies M_VLANTAG for the outer 
802.1q header.
4. That the input path is able to reenter vlan(4) correctly on the way 
back up the stack; The code which produces/consumes M_VLANTAG from the 
802.1q header might need to be made common.

The priority field them becomes problematic. As a compromise I'd suggest 
the priority field in the VLAN tag is derived from the innermost 802.1q 
header, which will be the first M_VLANTAG which the Ethernet part of the 
stack sees.

This gives ALTQ/RSVP/PF a chance to do its thing without complicated 
workarounds.

BMS