[leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Lennert Buytenhek]

----- Forwarded message from Leo Yuriev <leo@yuriev.ru> -----

From: Leo Yuriev <leo@yuriev.ru>
To: Lennert Buytenhek <buytenh@gnu.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header

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 <leo@yuriev.ru>


-- net/bridge/br_input.c.orig   2005-03-02 10:37:50.000000000 +0300
+++ net/bridge/br_input.c       2005-03-05 16:11:00.000000000 +0300
@@ -5,6 +5,10 @@
  *     Authors:
  *     Lennert Buytenhek               <buytenh@gnu.org>
  *
+ *     Changes:
+ *             03/Mar/2005: Leo Yuriev <leo@yuriev.ru>
+ *             Update skb->priority for packets with VLAN-tag.
+ *
  *     $Id: br_input.c,v 1.10 2001/12/24 04:50:20 davem Exp $
  *
  *     This program is free software; you can redistribute it and/or
@@ -17,6 +21,9 @@
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
 #include <linux/netfilter_bridge.h>
+#ifdef CONFIG_NET_SCHED
+#      include <linux/if_vlan.h>
+#endif /* CONFIG_NET_SCHED*/
 #include "br_private.h"
 
 const unsigned char bridge_ula[6] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 };
@@ -45,6 +52,40 @@ static void br_pass_frame_up(struct net_
                        br_pass_frame_up_finish);
 }
 
+
+#ifdef CONFIG_NET_SCHED
+/*
+ *   Leo Yuriev: Just update skb->priority for properly QoS handling in case
+ *               frame in the skb is contain VLAN-header.
+ *
+ *  SANITY NOTE: We are referencing to the VLAN_HDR frields, which MAY be
+ *               stored UNALIGNED in the memory.
+ *               According to Dave Miller & Alexey, it will always be aligned,
+ *               so there doesn't need to be any of the unaligned stuff.
+ *
+ */
+static __inline__ void br_update_skb_priority_if_vlan(struct sk_buff *skb)
+{
+       unsigned short vlan_TCI;
+       struct vlan_hdr *vhdr;
+
+       if (skb->protocol == __constant_htons(ETH_P_8021Q)) {
+               vhdr = (struct vlan_hdr *)(skb->data);
+               /* vlan_TCI = ntohs(get_unaligned(&vhdr->h_vlan_TCI)); */
+               vlan_TCI = ntohs(vhdr->h_vlan_TCI);
+#ifdef VLAN_DEBUG
+               printk(VLAN_DBG "%s: skb: %p vlan_id: %hx\n",
+                       __FUNCTION__, skb, (vlan_TCI & VLAN_VID_MASK));
+#endif
+               /*
+                *   We map VLAN_TCI priority (0..7) to skb->priority (0..15) 
+                *   most similarly e.g. 0->0, 1->1, .., 7->7
+                */
+               skb->priority = (vlan_TCI >> 13) & 7;
+       }
+}
+#endif /* CONFIG_NET_SCHED */
+
 /* note: already called with rcu_read_lock (preempt_disabled) */
 int br_handle_frame_finish(struct sk_buff *skb)
 {
@@ -54,6 +95,10 @@ int br_handle_frame_finish(struct sk_buf
        struct net_bridge_fdb_entry *dst;
        int passedup = 0;
 
+#ifdef CONFIG_NET_SCHED
+       br_update_skb_priority_if_vlan(skb);
+#endif /* CONFIG_NET_SCHED*/
+
        if (br->dev->flags & IFF_PROMISC) {
                struct sk_buff *skb2;


----- End forwarded message -----

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Patrick McHardy]

Lennert Buytenhek wrote:
> ----- Forwarded message from Leo Yuriev <leo@yuriev.ru> -----
> 
> From: Leo Yuriev <leo@yuriev.ru>
> To: Lennert Buytenhek <buytenh@gnu.org>,
> 	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header
> 
> 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 <leo@yuriev.ru>

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

Regards
Patrick

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Ben Greear]

Patrick McHardy wrote:
> Lennert Buytenhek wrote:
> 
>> ----- Forwarded message from Leo Yuriev <leo@yuriev.ru> -----
>>
>> From: Leo Yuriev <leo@yuriev.ru>
>> To: Lennert Buytenhek <buytenh@gnu.org>,
>>     Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>> Cc: linux-kernel@vger.kernel.org
>> Subject: [PATCH] ethernet-bridge: update skb->priority in case 
>> forwarded frame has VLAN-header
>>
>> 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 <leo@yuriev.ru>
> 
> 
> It needs to verify the tag is present and accessible using
> pskb_may_pull(). But I think an ebtables target similar to the iptables
> CLASSIFY target is a better place for this. It could allow setting
> skb->priority to an arbitary value or derive it from vlan priority or IP
> tos.

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

Ben

> 
> Regards
> Patrick
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[jamal]

On Sat, 2005-03-05 at 14:44, Ben Greear wrote:
> Patrick McHardy wrote:
> > Lennert Buytenhek wrote:

>From looking at the patch:
------
+               /*
+                *   We map VLAN_TCI priority (0..7) to skb->priority (0..15) 
+                *   most similarly e.g. 0->0, 1->1, .., 7->7
+                */
+               skb->priority = (vlan_TCI >> 13) & 7;
------

This is wrong. IEEE priorities are opposite of IETF priorities (as used by
skb->prio).
Unless you install a prio qdisc and rewrite the priomap, you are screwed.
So you should do opposite mapping, i.e something along the lines of
VLAN_TCI priority (0..7) to skb->priority (15..8) i,e

skb->priority = 15 - vlan_TCI;

cheers,
jamal

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Patrick McHardy]

On Mon, 7 Mar 2005, jamal wrote:

> This is wrong. IEEE priorities are opposite of IETF priorities (as used by
> skb->prio).
> Unless you install a prio qdisc and rewrite the priomap, you are screwed.
> So you should do opposite mapping, i.e something along the lines of
> VLAN_TCI priority (0..7) to skb->priority (15..8) i,e
>
> skb->priority = 15 - vlan_TCI;

The priority should still start at 0. You don't want to create a 16-band
queue just to have 8 bands unused.

Regards
Patrick

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[jamal]

On Mon, 2005-03-07 at 14:36, Patrick McHardy wrote: 
> On Mon, 7 Mar 2005, jamal wrote:
> 
> > This is wrong. IEEE priorities are opposite of IETF priorities (as used by
> > skb->prio).
> > Unless you install a prio qdisc and rewrite the priomap, you are screwed.
> > So you should do opposite mapping, i.e something along the lines of
> > VLAN_TCI priority (0..7) to skb->priority (15..8) i,e
> >
> > skb->priority = 15 - vlan_TCI;
> 
> The priority should still start at 0. You don't want to create a 16-band
> queue just to have 8 bands unused.

say what?;-> Nothing has to start at 0. 16 priorities does not equate to
16 queues. 

cheers,
jamal

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Patrick McHardy]

jamal wrote:
>>
>>The priority should still start at 0. You don't want to create a 16-band
>>queue just to have 8 bands unused.
> 
> 
> say what?;-> Nothing has to start at 0. 16 priorities does not equate to
> 16 queues. 

Right. But the default pfifo_fast/prio mapping maps the upper 8 values
to queue 1, which seems to make this effort kind of useless. I don't
know if the default-mapping of the lower 8 values is useable in this
context, I need to inform myself more on this subject (thanks for the
IEEE vs. IETF pointers).

Regards
Patrick

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[jamal]

On Mon, 2005-03-07 at 18:53, Patrick McHardy wrote:
> jamal wrote:
> >>
> >>The priority should still start at 0. You don't want to create a 16-band
> >>queue just to have 8 bands unused.
> > 
> > 
> > say what?;-> Nothing has to start at 0. 16 priorities does not equate to
> > 16 queues. 
> 
> Right. But the default pfifo_fast/prio mapping maps the upper 8 values
> to queue 1, which seems to make this effort kind of useless. 
> I don't know if the default-mapping of the lower 8 values is useable 
> in this context, 

Indeed that looks bad. But wouldnt have helped if we started at 0
either. You need monotonically increasing values to make proper
sense. So i suppose to do proper qos with L2, one must install the prio
qdisc and rewrite the priomap.

The mapping used in pfifo_fast is derived from RFC1349 4 bit TOS which
is really considered toast these days. We need to revamp things - but
this would require some surgery in the route code as well (so maybe safe
to leave as is).

> I need to inform myself more on this subject (thanks for the
> IEEE vs. IETF pointers).
> 

Has bitten me a few times when trying to do Qos between switches and
routers.

cheers,
jamal

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Patrick McHardy]

jamal wrote:
> Indeed that looks bad. But wouldnt have helped if we started at 0
> either. You need monotonically increasing values to make proper
> sense. So i suppose to do proper qos with L2, one must install the prio
> qdisc and rewrite the priomap.

One reason more to move it to an optional ebtables target. Or leave it
all to prio + u32. But I guess a CLASSIFY target similar to iptables
could also be useful otherwise.

> The mapping used in pfifo_fast is derived from RFC1349 4 bit TOS which
> is really considered toast these days. We need to revamp things - but
> this would require some surgery in the route code as well (so maybe safe
> to leave as is).

Are there any changes required besides ip_tos2prio ? More importantly,
it there a different meaningful mapping to priorities we can apply ?

Regards
Patrick

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[jamal]

On Mon, 2005-03-07 at 22:38, Patrick McHardy wrote:
> jamal wrote:
> > Indeed that looks bad. But wouldnt have helped if we started at 0
> > either. You need monotonically increasing values to make proper
> > sense. So i suppose to do proper qos with L2, one must install the prio
> > qdisc and rewrite the priomap.
> 
> One reason more to move it to an optional ebtables target. Or leave it
> all to prio + u32. But I guess a CLASSIFY target similar to iptables
> could also be useful otherwise.

I think you still want (perhaps the vlan) driver to come up with some
sane defaults. From what i read from bgrear he has arbitrary values.

The only problem is we get conflicting goals with skb->priority between
IEEE/IETF so you cant have them both interworking; 
I dont know what CLASSIFY target but a meta action on ingress of a
device would easily set the skb->priority as well. So yes, if you want
to have both L2 and L3, you will need something that overwrites the
priority according to whatever the map is for one of them. Like i said
earlier though you need to have some sane value being set in the vlan
driver.

> Are there any changes required besides ip_tos2prio ? 

Theres also the user space->kernel setsockopt semantics; Unfortunately
just ridding of this is like killing an ABI interface, so it is
untouchable. However, it may be time to introudce a new setsockopt to
enable DSCP setting. 
ip_tos2prio is becoming less important if we are killing TOS routing
(which Dave may have done a while back - i have to look); however, we
can probably have a ip_dscp2prio or  ip_prec2prio map. 

> More importantly,
> it there a different meaningful mapping to priorities we can apply ?

Well, old 4 bit TOS is really obsoleted - Look at RFC 2474. 

Two schools of thoughts exist on mappings - we oughta support both.
One is the app controls these settings (MS is big on this approach).
The other is network providers control the network and dont give a squat
about what you set you values to be - we do that for example in qdiscs.
I would say the second is more prelevant.

cheers,
jamal

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Ben Greear]

jamal wrote:
> On Mon, 2005-03-07 at 22:38, Patrick McHardy wrote:
> 
>>jamal wrote:
>>
>>>Indeed that looks bad. But wouldnt have helped if we started at 0
>>>either. You need monotonically increasing values to make proper
>>>sense. So i suppose to do proper qos with L2, one must install the prio
>>>qdisc and rewrite the priomap.
>>
>>One reason more to move it to an optional ebtables target. Or leave it
>>all to prio + u32. But I guess a CLASSIFY target similar to iptables
>>could also be useful otherwise.
> 
> 
> I think you still want (perhaps the vlan) driver to come up with some
> sane defaults. From what i read from bgrear he has arbitrary values.

By default, everything is mapped to priority of zero, but the user can
specify a mapping to any integer they desire.

If you have some suggestions for some defaults better than zero, I'm
willing to consider it.

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[jamal]

On Tue, 2005-03-08 at 12:45, Ben Greear wrote:
[..]
> jamal wrote:
> > I think you still want (perhaps the vlan) driver to come up with some
> > sane defaults. From what i read from bgrear he has arbitrary values.
> 
> By default, everything is mapped to priority of zero, but the user can
> specify a mapping to any integer they desire.
>
> If you have some suggestions for some defaults better than zero, I'm
> willing to consider it.
> 

Everything going to zero may not be such a bad default.
You could do better by creating a map that resembles what
the default 3 band scheduler does. Just keep in mind that  
the reverse semantics of priorities. If you need help we can take it
offline.

cheers,
jamal

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

[Leo Yuriev]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

>>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. IEEE priorities are opposite of IETF priorities (as used by
skb->>prio).
j> Unless you install a prio qdisc and rewrite the priomap, you are screwed.
j> So you should do opposite mapping, i.e something along the lines of
j> VLAN_TCI priority (0..7) to skb->priority (15..8) i,e skb->priority = 15 - vlan_TCI;
j> cheers,
j> jamal


Jamal, you are wrong!

802.1p defines priority as "linear" from 0 to 7,
the 0 is lowest priority and 7 is highest.

couple FoC links:
http://www.linktionary.com/q/qos.html
http://www.nwfusion.com/details/475.html

-- 
С уважением,
 Leo                          mailto:leo@yuriev.ru

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQCPA0HMImkBbQEEALnWXpnchl1dHaCfwnXe2RO8ft9e7K5IGRW1lE9RERMy6R3L
JnMXMPiuWm/4tx6H/yTRUML8LbuACzf2Np9oHTxbDWxP40wGxQKrPDlzv/9gLEp6
ZwGF8mSfvZrPHux1LwIbryQxjlmwfNCkE+qiVOBWMsD7yAFCWrZztbWTWJ6pABEB
AAG0GkxlbyBZdXJpZXYgPGxlb0B5dXJpZXYucnU+iQCVAwUQQcwiabZztbWTWJ6p
AQG6cAP9H0O+MMa0WDlGE2JGG+SWuu9Iuqg76Hp6tjtrz2pLWEzbq8oqCkE0THff
/YUUaKqnrLELwEaptE+MrWSv9Zt1K/PauMpKUWXhlYqGcGB2NqJL69AONQte0M4B
rPSSts4CU7gK2Zuds1DOLiON7e9Sbpjc5T+4D7Jw5XGKMz66nhY=
=qGIk
-----END PGP PUBLIC KEY BLOCK-----

[-- Attachment #2: Type: application/pgp-signature, Size: 282 bytes --]

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

[jamal]

On Thu, 2005-03-10 at 08:26, Leo Yuriev wrote:
> >>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. IEEE priorities are opposite of IETF priorities (as used by
> skb->>prio).
> j> Unless you install a prio qdisc and rewrite the priomap, you are screwed.
> j> So you should do opposite mapping, i.e something along the lines of
> j> VLAN_TCI priority (0..7) to skb->priority (15..8) i,e skb->priority = 15 - vlan_TCI;
> j> cheers,
> j> jamal
> 
> 
> Jamal, you are wrong!

But i am not, Leo ;->

> 802.1p defines priority as "linear" from 0 to 7,
> the 0 is lowest priority and 7 is highest.
> 

Yes of course this is true for IEEE (I never said this wasnt the case).
 
The issue is this: _which_  queue gets processed first?
In strict priority (default for Linux), queue 0 is always high
priority and will always be processed first even if queue 1 has work
(to use other terms queue 1 will be "starved" by queue 0).
So you need to make sure that "highest" priority(7 in your case) always 
goes to queue 0. As was pointed out in the thread discussion - priority
map in Linux actually doesnt quiet map to a true reverse as i had put
it. 
So you need to change your equation to map to the default map in Linux
in which the  result is always to make sure 802.1p priority 7 is
processed first.
If you have any problems figuring it out email me privately and i can
help.

cheers,
jamal

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Stephen Hemminger]

On Sat, 5 Mar 2005 15:12:25 +0100
Lennert Buytenhek <buytenh@wantstofly.org> wrote:

> ----- Forwarded message from Leo Yuriev <leo@yuriev.ru> -----
> 
> From: Leo Yuriev <leo@yuriev.ru>
> To: Lennert Buytenhek <buytenh@gnu.org>,
> 	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header
> 
> 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.

I don't see why the VLAN code doesn't handle this itself. I don't like special
case layer violations because it becomes a slippery slope with more and
more additions.

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Ben Greear]

Stephen Hemminger wrote:
> On Sat, 5 Mar 2005 15:12:25 +0100
> Lennert Buytenhek <buytenh@wantstofly.org> wrote:
> 
> 
>>----- Forwarded message from Leo Yuriev <leo@yuriev.ru> -----
>>
>>From: Leo Yuriev <leo@yuriev.ru>
>>To: Lennert Buytenhek <buytenh@gnu.org>,
>>	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
>>Cc: linux-kernel@vger.kernel.org
>>Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header
>>
>>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.
> 
> 
> I don't see why the VLAN code doesn't handle this itself. I don't like special
> case layer violations because it becomes a slippery slope with more and
> more additions.

VLAN does handle this.  The main use for the patch is for bridging VLANs
across a normal ethernet device, it appears.  Ie, not really using
the VLAN module at all.

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Patrick McHardy]

Stephen Hemminger wrote:
>>
>>This small patch does this. Currently vlan_TCI-priority directly
>>mapped to skb->priority, but this looks enough.
> 
> I don't see why the VLAN code doesn't handle this itself. I don't like special
> case layer violations because it becomes a slippery slope with more and
> more additions.

The patch is meant for bridges briging vlan frames without doing
vlan themselves. I agree with you, from the bridge point of view
a vlan header is just as outside of its scope as an IP header,
that's why I proposed to put it in an ebtables target and make
it useable for vlan and IP.

Regards
Patrick

Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header]

[Stephen Hemminger]

On Mon, 07 Mar 2005 19:16:50 +0100
Patrick McHardy <kaber@trash.net> wrote:

> Stephen Hemminger wrote:
> >>
> >>This small patch does this. Currently vlan_TCI-priority directly
> >>mapped to skb->priority, but this looks enough.
> > 
> > I don't see why the VLAN code doesn't handle this itself. I don't like special
> > case layer violations because it becomes a slippery slope with more and
> > more additions.
> 
> The patch is meant for bridges briging vlan frames without doing
> vlan themselves. I agree with you, from the bridge point of view
> a vlan header is just as outside of its scope as an IP header,
> that's why I proposed to put it in an ebtables target and make
> it useable for vlan and IP.

That's much better. 
Leave the protocol violations to netfilter modules where they belong ;-)