>>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> --
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 This is wrong.
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
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
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
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 looks enough.
PM
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
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
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
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
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
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
12 matches
Mail list logo