>>From looking at the patch:
j> --
j> + /*
j> +* We map VLAN_TCI priority (0..7) to skb->priority (0..15)
j> +* most similarly e.g. 0->0, 1->1, .., 7->7
j> +*/
j> + skb->priority = (vlan_TCI >> 13) & 7;
j> --
j
Hello!
> If this packet came in from an 802.1Q VLAN device, the VLAN code already
> has the logic necessary to map the .1q priority to an arbitrary
> skb->priority.
Actually, the patch makes sense when it is straight ethernet bridge
not involving full parsing of VLAN. I guess the case when the f
Leo Yuriev wrote:
3) But I think, it is not necessary to provide a customization of
mapping .1q priority to skb->priority (e.g. clone a code from
VLAN-module) for the following reasons:
- my patch is intended only for the basic, obvious behaviour;
- ebtables already provide a powerful abili
LY>> Kernel 2.6 (2.6.11)
LY>>
LY>> When ethernet-bridge forward a packet and such ethernet-frame has
LY>> VLAN-tag, bridge should update skb->prioriry for properly QoS
LY>> handling.
LY>>
LY>> This small patch does this. Currently vlan_TCI-priority directly
LY>> mapped to skb->priority, but this lo
Leo Yuriev wrote:
Kernel 2.6 (2.6.11)
When ethernet-bridge forward a packet and such ethernet-frame has
VLAN-tag, bridge should update skb->prioriry for properly QoS
handling.
This small patch does this. Currently vlan_TCI-priority directly
mapped to skb->priority, but this looks enough.
If this pa
Kernel 2.6 (2.6.11)
When ethernet-bridge forward a packet and such ethernet-frame has
VLAN-tag, bridge should update skb->prioriry for properly QoS
handling.
This small patch does this. Currently vlan_TCI-priority directly
mapped to skb->priority, but this looks enough.
Patch-by: Leo Yuriev <[EM
6 matches
Mail list logo
