Re[2]: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header

[Leo Yuriev]

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> It needs to verify the tag is present and accessible using
PM> pskb_may_pull(). But I think an ebtables target similar to the iptables
PM> CLASSIFY target is a better place for this. It could allow setting
PM> skb->priority to an arbitary value or derive it from vlan priority or IP
PM> tos.

BG> The VLAN code has it's own (user-configurable) mapping from skb->priority to .1q priority,
BG> and .1q priority to skb->priority.  You might want to clone or somehow
BG> use the .1q mapping logic to allow something other than just a
BG> straight .1q -> skb->priority mapping.

BG> If this packet came in from an 802.1Q VLAN device, the VLAN code already
BG> has the logic necessary to map the .1q priority to an arbitrary skb->priority.

- Yes, but linux-box can be a all-vlan-bridge without the 8021q
module. So, in a some cases of configuration (like currently is my
own) nobody in kernel can set skb->priority in the forwarded packets.
But I (as a user) can expect than the bridge with QoS will able to
plain and evident prioritization without my immersion into ebtables...

1) I will put the verification by pskb_may_pull() as pointed Patrick
McHardy. It is just my mistake/bug.

2) Despite of opportunities ebtables I think, that this addition is
necessary. As small forces, by default, provide more correct and
expected behaviour of system, without conflicts to other
opportunities.

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 abilities;
    - user can expect that the bridge will not require more
      configuration that currently is provided;


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/