2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Simon Arlott]

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

If I remove eth0 from the bridge, eth0.3840 starts working again. It
still works if eth0.3840 is part of a bridge but eth0 isn't (the device
is in promiscuous mode). I've only tested with broadcast traffic.

This works with 2.6.36.

git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
first bad commit.

The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
use).

-- 
Simon Arlott

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Ben Hutchings]

On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
> 
> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
> to receive packets. Using tcpdump on eth0 shows the packets being
> received with a VLAN tag but they don't appear on eth0.3840. They appear
> with the VLAN tag on the bridge interface.
[...]

This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled.  (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
would consider this an improvement.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Simon Arlott]

On 17/01/11 16:00, Ben Hutchings wrote:
> On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
>> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
>> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
>> 
>> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
>> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
>> to receive packets. Using tcpdump on eth0 shows the packets being
>> received with a VLAN tag but they don't appear on eth0.3840. They appear
>> with the VLAN tag on the bridge interface.
> [...]
> 
> This means the behaviour is now consistent, whether or not hardware VLAN
> tag stripping is enabled.  (I previously pointed out the inconsistent
> behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
> would consider this an improvement.

Shouldn't the kernel also prevent a device from being both part of a
bridge and having VLANs? Instead everything appears to work except
incoming traffic.

-- 
Simon Arlott

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Mon, Jan 17, 2011 at 10:17 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
> On 17/01/11 16:00, Ben Hutchings wrote:
>> On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
>>> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
>>> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
>>>
>>> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
>>> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
>>> to receive packets. Using tcpdump on eth0 shows the packets being
>>> received with a VLAN tag but they don't appear on eth0.3840. They appear
>>> with the VLAN tag on the bridge interface.
>> [...]
>>
>> This means the behaviour is now consistent, whether or not hardware VLAN
>> tag stripping is enabled.  (I previously pointed out the inconsistent
>> behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
>> would consider this an improvement.
>
> Shouldn't the kernel also prevent a device from being both part of a
> bridge and having VLANs? Instead everything appears to work except
> incoming traffic.

It might make sense, although you have similar effects with non-vlan
traffic to the device as well.  You could make the same argument that
we shouldn't allow IP addresses, etc. to be assigned to bridged
devices.  There are also other components that use the bridge hooks
that would need to be checked.  All this starts to get a bit messy.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Maciej Rutecki]

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there, thanks!

On niedziela, 16 stycznia 2011 o 15:09:32 Simon Arlott wrote:
> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16,
> addr 00:e0:81:4d:2b:ec [    1.666767] forcedeth 0000:00:08.0: highdma csum
> vlan pwrctl mgmt gbit lnktim msi desc-v3
> 
> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
> to receive packets. Using tcpdump on eth0 shows the packets being
> received with a VLAN tag but they don't appear on eth0.3840. They appear
> with the VLAN tag on the bridge interface.
> 
> If I remove eth0 from the bridge, eth0.3840 starts working again. It
> still works if eth0.3840 is part of a bridge but eth0 isn't (the device
> is in promiscuous mode). I've only tested with broadcast traffic.
> 
> This works with 2.6.36.
> 
> git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
> first bad commit.
> 
> The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
> ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
> likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
> use).

-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
<maciej.rutecki@gmail.com> wrote:
> I created a Bugzilla entry at
> https://bugzilla.kernel.org/show_bug.cgi?id=27432
> for your bug report, please add your address to the CC list in there, thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Maciej Rutecki]

On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:
> On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
> 
> <maciej.rutecki@gmail.com> wrote:
> > I created a Bugzilla entry at
> > https://bugzilla.kernel.org/show_bug.cgi?id=27432
> > for your bug report, please add your address to the CC list in there,
> > thanks!
> 
> This isn't a bug - the change resolved behavior that varied depending
> on what NIC was in use.

Thanks for the update. Closing.

Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Maciej Rutecki <maciej.rutecki <at> gmail.com> writes:

> 
> On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:
> > On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
> > 
> > <maciej.rutecki <at> gmail.com> wrote:
> > > I created a Bugzilla entry at
> > > https://bugzilla.kernel.org/show_bug.cgi?id=27432
> > > for your bug report, please add your address to the CC list in there,
> > > thanks!
> > 
> > This isn't a bug - the change resolved behavior that varied depending
> > on what NIC was in use.
> 
> Thanks for the update. Closing.
> 
> Regards


Hi

How am i supposed to put my eth to a bridge and have a seprate vlan besides that
bridge?

regards

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Sat, Feb 5, 2011 at 7:34 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Maciej Rutecki <maciej.rutecki <at> gmail.com> writes:
>
>>
>> On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:
>> > On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
>> >
>> > <maciej.rutecki <at> gmail.com> wrote:
>> > > I created a Bugzilla entry at
>> > > https://bugzilla.kernel.org/show_bug.cgi?id=27432
>> > > for your bug report, please add your address to the CC list in there,
>> > > thanks!
>> >
>> > This isn't a bug - the change resolved behavior that varied depending
>> > on what NIC was in use.
>>
>> Thanks for the update. Closing.
>>
>> Regards
>
>
> Hi
>
> How am i supposed to put my eth to a bridge and have a seprate vlan besides that
> bridge?

You should either attached a bridge to a vlan device or stack a vlan
device on the bridge port depending on what you are trying to achieve.

The bridge handler takes all packets of the device that it is attached
to, so having a vlan also attached to the same device will not work.
You may get different results on older kernels depending on what NIC
you were using but that was a bug.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Jesse Gross <jesse <at> nicira.com> writes:

>
> You should either attached a bridge to a vlan device or stack a vlan
> device on the bridge port depending on what you are trying to achieve.
> 
> The bridge handler takes all packets of the device that it is attached
> to, so having a vlan also attached to the same device will not work.
> You may get different results on older kernels depending on what NIC
> you were using but that was a bug.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


Hi and thanks for your reply

I tried that.

I had under 2.6.36.3 following combination:

eth1 in br0 -> all traffic without vlan id
eth1.3 -> traffic with vlan 3

with 2.6.37 i should do the following
eth1 in br0 -> traffic w/o vlans
and br0.3 -> traffic with vlan id 3

But still there is no rx for vlan 3.
Any suggestions? Or am i missing something?


regards

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Nicolas de Pesloüan]

Le 06/02/2011 20:37, chriss a écrit :
> Jesse Gross<jesse<at>  nicira.com>  writes:
>
>>
>> You should either attached a bridge to a vlan device or stack a vlan
>> device on the bridge port depending on what you are trying to achieve.
>>
>> The bridge handler takes all packets of the device that it is attached
>> to, so having a vlan also attached to the same device will not work.
>> You may get different results on older kernels depending on what NIC
>> you were using but that was a bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo<at>  vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> Hi and thanks for your reply
>
> I tried that.
>
> I had under 2.6.36.3 following combination:
>
> eth1 in br0 ->  all traffic without vlan id
> eth1.3 ->  traffic with vlan 3
>
> with 2.6.37 i should do the following
> eth1 in br0 ->  traffic w/o vlans
> and br0.3 ->  traffic with vlan id 3
>
> But still there is no rx for vlan 3.
> Any suggestions? Or am i missing something?

I think you should have a look at ebtables command, in particular, the BROUTING chain of broute 
table. If this chain ask the packet to be dropped, then bridge will ignore it and give a chance to 
the upper layer to use it. Upper layer might be IP, or in your particular setup, VLAN.

HTH,

	Nicolas.



In order for eth1.3 to receive the traffic with VLANID=3, while having the bridge get everything 
else, you should add an entry to the

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:

> I think you should have a look at ebtables command, in particular, the
BROUTING chain of broute 
> table. If this chain ask the packet to be dropped, then bridge will ignore it
and give a chance to 
> the upper layer to use it. Upper layer might be IP, or in your particular
setup, VLAN.
> 
> HTH,
> 
> 	Nicolas.

Thank you very much for the ebtables hint.

I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.

I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!

Thanks nicolas

regards//chriss

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Mon, Feb 14, 2011 at 5:22 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:
>
>> I think you should have a look at ebtables command, in particular, the
> BROUTING chain of broute
>> table. If this chain ask the packet to be dropped, then bridge will ignore it
> and give a chance to
>> the upper layer to use it. Upper layer might be IP, or in your particular
> setup, VLAN.
>>
>> HTH,
>>
>>       Nicolas.
>
> Thank you very much for the ebtables hint.
>
> I also tried to add the vlan to my bridge device but only droping the vlan
> tagged paket with ebtables got it working.
>
> I'm not sure if this is the wanted behavior for bridging vlan actions.
> ..or my network setup is just to ..f%%%'ed up?!

It should work even without ebtables (running vlan on top of bridge,
not side by side).  I'll try to look at this in the next couple of
days.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Mon, Feb 14, 2011 at 5:22 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:
>
>> I think you should have a look at ebtables command, in particular, the
> BROUTING chain of broute
>> table. If this chain ask the packet to be dropped, then bridge will ignore it
> and give a chance to
>> the upper layer to use it. Upper layer might be IP, or in your particular
> setup, VLAN.
>>
>> HTH,
>>
>>       Nicolas.
>
> Thank you very much for the ebtables hint.
>
> I also tried to add the vlan to my bridge device but only droping the vlan
> tagged paket with ebtables got it working.
>
> I'm not sure if this is the wanted behavior for bridging vlan actions.
> ..or my network setup is just to ..f%%%'ed up?!

What driver is in use with the NIC you are seeing this on?

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Jesse Gross <jesse <at> nicira.com> writes:

> 
> What driver is in use with the NIC you are seeing this on?
>

He there

the device in question is (as lspci told)
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit
Ethernet (rev 10)

handled by kernel module r8169.

I also tried to set up the vlan on the bridge. like br0.3. but that did not work.

regards//chriss

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Fri, Feb 25, 2011 at 4:16 PM, chriss <mail_to_chriss@gmx.net> wrote:
> Jesse Gross <jesse <at> nicira.com> writes:
>
>>
>> What driver is in use with the NIC you are seeing this on?
>>
>
> He there
>
> the device in question is (as lspci told)
> Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit
> Ethernet (rev 10)
>
> handled by kernel module r8169.

I'm guessing that you're hitting the special case in this code in
r8169.c:rtl8169_vlan_rx_register():

         /*
          * Do not disable RxVlan on 8110SCd.
          */
         if (tp->vlgrp || (tp->mac_version == RTL_GIGA_MAC_VER_05))
                 tp->cp_cmd |= RxVlan;
         else
                 tp->cp_cmd &= ~RxVlan;

Since before you were getting the vlans directly off the device there
was a vlan group configured.  However, now that the packets are going
through the bridge, the group is not being configured on the device
and the tag gets dropped.  Assuming that this is the case, the
solution is to convert the driver to use the new vlan model, which
does not require knowledge of the vlan group.

Can you confirm this by running tcpdump -eni br0?  I would expect that
you see the correct packets but without vlan tags.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Jesse Gross <jesse <at> nicira.com> writes:

> 
> Can you confirm this by running tcpdump -eni br0?  I would expect that
> you see the correct packets but without vlan tags.
> 

Thats correct. i see the packets in br0 without tags and tagged in eth1. thats
why i added the brouting rule in ebtables to drop it at eth1 and the it apears
in eth1.3 (untagged)...

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Sat, Feb 26, 2011 at 3:51 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Jesse Gross <jesse <at> nicira.com> writes:
>
>>
>> Can you confirm this by running tcpdump -eni br0?  I would expect that
>> you see the correct packets but without vlan tags.
>>
>
> Thats correct. i see the packets in br0 without tags and tagged in eth1. thats
> why i added the brouting rule in ebtables to drop it at eth1 and the it apears
> in eth1.3 (untagged)...

Putting a vlan device on eth1 actually affects the behavior of the
driver, which is why that works.  I suspect that if you put the vlan
device on both the physical interface and the bridge you would see
packets with tags on the bridge.

Regardless, the solution is to remove the dependency on vlan devices
by converting over to the new vlan model.  Francois, any chance that
you might have some time to look at this?

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Francois Romieu]

Jesse Gross <jesse@nicira.com> :
[...]
> Putting a vlan device on eth1 actually affects the behavior of the
> driver, which is why that works.  I suspect that if you put the vlan
> device on both the physical interface and the bridge you would see
> packets with tags on the bridge.
> 
> Regardless, the solution is to remove the dependency on vlan devices
> by converting over to the new vlan model.  Francois, any chance that
> you might have some time to look at this?

The completely untested patch below is available for the (really) desperate
souls.

I should do a -next testing session this afternoon for this patch + 
Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0382332..8e7da78 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2235,15 +2235,6 @@ config R8169
 	  To compile this driver as a module, choose M here: the module
 	  will be called r8169.  This is recommended.
 
-config R8169_VLAN
-	bool "VLAN support"
-	depends on R8169 && VLAN_8021Q
-	---help---
-	  Say Y here for the r8169 driver to support the functions required
-	  by the kernel 802.1Q code.
-
-	  If in doubt, say Y.
-
 config SB1250_MAC
 	tristate "SB1250 Gigabit Ethernet support"
 	depends on SIBYTE_SB1xxx_SOC
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bde7d61..5c4f03d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -526,9 +526,6 @@ struct rtl8169_private {
 	u16 napi_event;
 	u16 intr_mask;
 	int phy_1000_ctrl_reg;
-#ifdef CONFIG_R8169_VLAN
-	struct vlan_group *vlgrp;
-#endif
 
 	struct mdio_ops {
 		void (*write)(void __iomem *, int, int);
@@ -1254,8 +1251,6 @@ static int rtl8169_set_rx_csum(struct net_device *dev, u32 data)
 	return 0;
 }
 
-#ifdef CONFIG_R8169_VLAN
-
 static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
 				      struct sk_buff *skb)
 {
@@ -1263,64 +1258,37 @@ static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
 		TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00;
 }
 
-static void rtl8169_vlan_rx_register(struct net_device *dev,
-				     struct vlan_group *grp)
+#define NETIF_F_HW_VLAN_TX_RX	(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX)
+
+static void rtl8169_vlan_mode(struct net_device *dev)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 	void __iomem *ioaddr = tp->mmio_addr;
 	unsigned long flags;
 
 	spin_lock_irqsave(&tp->lock, flags);
-	tp->vlgrp = grp;
-	/*
-	 * Do not disable RxVlan on 8110SCd.
-	 */
-	if (tp->vlgrp || (tp->mac_version == RTL_GIGA_MAC_VER_05))
+	if (dev->features & NETIF_F_HW_VLAN_RX)
 		tp->cp_cmd |= RxVlan;
 	else
 		tp->cp_cmd &= ~RxVlan;
 	RTL_W16(CPlusCmd, tp->cp_cmd);
+	/* PCI commit */
 	RTL_R16(CPlusCmd);
 	spin_unlock_irqrestore(&tp->lock, flags);
+
+	dev->vlan_features = dev->features &~ NETIF_F_HW_VLAN_TX_RX;
 }
 
-static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc,
-			       struct sk_buff *skb, int polling)
+static void rtl8169_rx_vlan_tag(struct RxDesc *desc, struct sk_buff *skb)
 {
 	u32 opts2 = le32_to_cpu(desc->opts2);
-	struct vlan_group *vlgrp = tp->vlgrp;
-	int ret;
 
-	if (vlgrp && (opts2 & RxVlanTag)) {
-		u16 vtag = swab16(opts2 & 0xffff);
+	if (opts2 & RxVlanTag)
+		__vlan_hwaccel_put_tag(skb, swab16(opts2 & 0xffff));
 
-		if (likely(polling))
-			vlan_gro_receive(&tp->napi, vlgrp, vtag, skb);
-		else
-			__vlan_hwaccel_rx(skb, vlgrp, vtag, polling);
-		ret = 0;
-	} else
-		ret = -1;
 	desc->opts2 = 0;
-	return ret;
-}
-
-#else /* !CONFIG_R8169_VLAN */
-
-static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
-				      struct sk_buff *skb)
-{
-	return 0;
-}
-
-static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc,
-			       struct sk_buff *skb, int polling)
-{
-	return -1;
 }
 
-#endif
-
 static int rtl8169_gset_tbi(struct net_device *dev, struct ethtool_cmd *cmd)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
@@ -1491,6 +1459,28 @@ static void rtl8169_get_strings(struct net_device *dev, u32 stringset, u8 *data)
 	}
 }
 
+static int rtl8169_set_flags(struct net_device *dev, u32 data)
+{
+	struct rtl8169_private *tp = netdev_priv(dev);
+	unsigned long old_feat = dev->features;
+	int rc;
+
+	if ((tp->mac_version == RTL_GIGA_MAC_VER_05) &&
+	    !(data & ETH_FLAG_RXVLAN)) {
+		netif_info(tp, drv, dev, "8110SCd requires hardware Rx VLAN\n");
+		return -EINVAL;
+	}
+
+	rc = ethtool_op_set_flags(dev, data, ETH_FLAG_TXVLAN | ETH_FLAG_RXVLAN);
+	if (rc)
+		return rc;
+
+	if ((old_feat ^ dev->features) & NETIF_F_HW_VLAN_RX)
+		rtl8169_vlan_mode(dev);
+
+	return 0;
+}
+
 static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.get_drvinfo		= rtl8169_get_drvinfo,
 	.get_regs_len		= rtl8169_get_regs_len,
@@ -1510,6 +1500,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.get_strings		= rtl8169_get_strings,
 	.get_sset_count		= rtl8169_get_sset_count,
 	.get_ethtool_stats	= rtl8169_get_ethtool_stats,
+	.set_flags		= rtl8169_set_flags,
+	.get_flags		= ethtool_op_get_flags,
 };
 
 static void rtl8169_get_mac_version(struct rtl8169_private *tp,
@@ -2792,9 +2784,6 @@ static const struct net_device_ops rtl8169_netdev_ops = {
 	.ndo_set_mac_address	= rtl_set_mac_address,
 	.ndo_do_ioctl		= rtl8169_ioctl,
 	.ndo_set_multicast_list	= rtl_set_rx_mode,
-#ifdef CONFIG_R8169_VLAN
-	.ndo_vlan_rx_register	= rtl8169_vlan_rx_register,
-#endif
 #ifdef CONFIG_NET_POLL_CONTROLLER
 	.ndo_poll_controller	= rtl8169_netpoll,
 #endif
@@ -3086,6 +3075,13 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	/* Identify chip attached to board */
 	rtl8169_get_mac_version(tp, ioaddr);
 
+	/*
+	 * Pretend we are using VLANs; This bypasses a nasty bug where
+	 * Interrupts stop flowing on high load on 8110SCd controllers.
+	 */
+	if (tp->mac_version == RTL_GIGA_MAC_VER_05)
+		tp->cp_cmd |= RxVlan;
+
 	rtl_init_mdio_ops(tp);
 	rtl_init_pll_power_ops(tp);
 
@@ -3154,10 +3150,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	netif_napi_add(dev, &tp->napi, rtl8169_poll, R8169_NAPI_WEIGHT);
 
-#ifdef CONFIG_R8169_VLAN
-	dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-#endif
-	dev->features |= NETIF_F_GRO;
+	dev->features |= NETIF_F_HW_VLAN_TX_RX | NETIF_F_GRO;
 
 	tp->intr_mask = 0xffff;
 	tp->hw_start = cfg->hw_start;
@@ -3273,12 +3266,7 @@ static int rtl8169_open(struct net_device *dev)
 
 	rtl8169_init_phy(dev, tp);
 
-	/*
-	 * Pretend we are using VLANs; This bypasses a nasty bug where
-	 * Interrupts stop flowing on high load on 8110SCd controllers.
-	 */
-	if (tp->mac_version == RTL_GIGA_MAC_VER_05)
-		RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | RxVlan);
+	rtl8169_vlan_mode(dev);
 
 	rtl_pll_power_up(tp);
 
@@ -4589,12 +4577,12 @@ static int rtl8169_rx_interrupt(struct net_device *dev,
 			skb_put(skb, pkt_size);
 			skb->protocol = eth_type_trans(skb, dev);
 
-			if (rtl8169_rx_vlan_skb(tp, desc, skb, polling) < 0) {
-				if (likely(polling))
-					napi_gro_receive(&tp->napi, skb);
-				else
-					netif_rx(skb);
-			}
+			rtl8169_rx_vlan_tag(desc, skb);
+
+			if (likely(polling))
+				napi_gro_receive(&tp->napi, skb);
+			else
+				netif_rx(skb);
 
 			dev->stats.rx_bytes += pkt_size;
 			dev->stats.rx_packets++;

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Tue, Mar 1, 2011 at 2:16 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Jesse Gross <jesse@nicira.com> :
> [...]
>> Putting a vlan device on eth1 actually affects the behavior of the
>> driver, which is why that works.  I suspect that if you put the vlan
>> device on both the physical interface and the bridge you would see
>> packets with tags on the bridge.
>>
>> Regardless, the solution is to remove the dependency on vlan devices
>> by converting over to the new vlan model.  Francois, any chance that
>> you might have some time to look at this?
>
> The completely untested patch below is available for the (really) desperate
> souls.
>
> I should do a -next testing session this afternoon for this patch +
> Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

Thanks Francois.  When you are ready this looks good to me.

Reviewed-by: Jesse Gross <jesse@nicira.com>

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Francois Romieu]

Francois Romieu <romieu@fr.zoreil.com> :
> Jesse Gross <jesse@nicira.com> :
> [...]
> > Regardless, the solution is to remove the dependency on vlan devices
> > by converting over to the new vlan model.  Francois, any chance that
> > you might have some time to look at this?
> 
> The completely untested patch below is available for the (really) desperate
> souls.
> 
> I should do a -next testing session this afternoon for this patch + 
> Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

It took a bit longer than expected but the patch seems to work.

Chriss, can you give it a try against current -rc / -git and see if it makes
a difference ?

-- 
Ueimor

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Francois Romieu <romieu <at> fr.zoreil.com> writes:

> 
> Chriss, can you give it a try against current -rc / -git and see if it makes
> a difference ?
> 

I hope i'm doing it right. i checked out the
'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'

and will try to apply the patch you provided. please correct me if i'm wrong.
I will report back.

regards//chriss

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Francois Romieu]

chriss <mail_to_chriss@gmx.net> :
[...]
> I hope i'm doing it right. i checked out the
> 'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'
> 
> and will try to apply the patch you provided. please correct me if i'm wrong.
> I will report back.

I have tested it against davem's -next somewhere along -rc5 but it should be
fine as well.

-- 
Ueimor

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[chriss]

Francois Romieu <romieu <at> fr.zoreil.com> writes:

> 
> chriss <mail_to_chriss <at> gmx.net> :
> [...]
> > I hope i'm doing it right. i checked out the
> > 'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'
> > 
> > and will try to apply the patch you provided. please correct me if i'm wrong.
> > I will report back.
> 
> I have tested it against davem's -next somewhere along -rc5 but it should be
> fine as well.
> 

My hat gows of to you kindly sir! Everything works as expected. im looking
forward to see this patch in the stable releases.

thank you very much
//chriss

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Sun, Feb 6, 2011 at 11:37 AM, chriss <mail_to_chriss@gmx.net> wrote:
> Jesse Gross <jesse <at> nicira.com> writes:
>
>>
>> You should either attached a bridge to a vlan device or stack a vlan
>> device on the bridge port depending on what you are trying to achieve.
>>
>> The bridge handler takes all packets of the device that it is attached
>> to, so having a vlan also attached to the same device will not work.
>> You may get different results on older kernels depending on what NIC
>> you were using but that was a bug.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo <at> vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
> Hi and thanks for your reply
>
> I tried that.
>
> I had under 2.6.36.3 following combination:
>
> eth1 in br0 -> all traffic without vlan id
> eth1.3 -> traffic with vlan 3
>
> with 2.6.37 i should do the following
> eth1 in br0 -> traffic w/o vlans
> and br0.3 -> traffic with vlan id 3
>
> But still there is no rx for vlan 3.
> Any suggestions? Or am i missing something?

That configuration should work (and I've tested it in the past).  I
would try running tcpdump on the various interfaces in the path (eth1,
br0, br0.3) to see where traffic is flowing or not.