netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* TX VLAN acceleration on bridges broken in 2.6.37?
@ 2011-02-21 23:29 Jan Niehusmann
  2011-02-23  1:32 ` Jesse Gross
  2011-02-25 22:53 ` Jesse Gross
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Niehusmann @ 2011-02-21 23:29 UTC (permalink / raw)
  To: linux-kernel; +Cc: netdev

With the following configuration, sending vlan tagged traffic from a
bridged interface doesn't work in 2.6.37.
The same configuration does work with 2.6.36:

- bridge br0 with physical interface eth0
- eth0 being an e1000e device (don't know if that's important)
- vlan interface br0.10
- (on 2.6.37) tx vlan acceleration active on br0 (default)

Networking on br0.10 doesn't work, and tcpdump on eth0 shows packets
sent on br0.10 as untagged, instead of vlan 10 tagged.

After turning vlan tx offloading off with 'ethtool -K br0 txvlan off',
everything works as expected, again.

The workaround is made permanent by reverting "bridge: Add support for
TX vlan offload.", 361ff8a6cf90d62c0071b7e532e37369bfd3ae77, turning
of the feature on bridges completely.

Jan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TX VLAN acceleration on bridges broken in 2.6.37?
  2011-02-21 23:29 TX VLAN acceleration on bridges broken in 2.6.37? Jan Niehusmann
@ 2011-02-23  1:32 ` Jesse Gross
  2011-02-25 22:53 ` Jesse Gross
  1 sibling, 0 replies; 6+ messages in thread
From: Jesse Gross @ 2011-02-23  1:32 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: linux-kernel, netdev

On Mon, Feb 21, 2011 at 3:29 PM, Jan Niehusmann <jan@gondor.com> wrote:
> With the following configuration, sending vlan tagged traffic from a
> bridged interface doesn't work in 2.6.37.
> The same configuration does work with 2.6.36:
>
> - bridge br0 with physical interface eth0
> - eth0 being an e1000e device (don't know if that's important)
> - vlan interface br0.10
> - (on 2.6.37) tx vlan acceleration active on br0 (default)
>
> Networking on br0.10 doesn't work, and tcpdump on eth0 shows packets
> sent on br0.10 as untagged, instead of vlan 10 tagged.
>
> After turning vlan tx offloading off with 'ethtool -K br0 txvlan off',
> everything works as expected, again.
>
> The workaround is made permanent by reverting "bridge: Add support for
> TX vlan offload.", 361ff8a6cf90d62c0071b7e532e37369bfd3ae77, turning
> of the feature on bridges completely.

I tested this at one point and it worked but it sounds like something
broke after that.  It's probably fairly simple, so I'd rather just fix
the problem instead of reverting the commit.  I'm just coming back
from vacation and am trying to catch up but I'll try to look at it in
the next couple of days.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TX VLAN acceleration on bridges broken in 2.6.37?
  2011-02-21 23:29 TX VLAN acceleration on bridges broken in 2.6.37? Jan Niehusmann
  2011-02-23  1:32 ` Jesse Gross
@ 2011-02-25 22:53 ` Jesse Gross
  2011-02-26  0:19   ` Jan Niehusmann
  1 sibling, 1 reply; 6+ messages in thread
From: Jesse Gross @ 2011-02-25 22:53 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: linux-kernel, netdev

On Mon, Feb 21, 2011 at 3:29 PM, Jan Niehusmann <jan@gondor.com> wrote:
> With the following configuration, sending vlan tagged traffic from a
> bridged interface doesn't work in 2.6.37.
> The same configuration does work with 2.6.36:
>
> - bridge br0 with physical interface eth0
> - eth0 being an e1000e device (don't know if that's important)
> - vlan interface br0.10
> - (on 2.6.37) tx vlan acceleration active on br0 (default)
>
> Networking on br0.10 doesn't work, and tcpdump on eth0 shows packets
> sent on br0.10 as untagged, instead of vlan 10 tagged.

I looked at this and wasn't able to reproduce it with either 2.6.37 or
net-next on either of my NICs (ixgbe and bnx2).  I'm guessing that it
is specific to the e1000e driver.  I know that some other Intel NICs
require vlan stripping on receive to be enabled for vlan insertion on
transmit to work.  Since this driver has not been converted over to
use the new vlan model yet, it only enables these things if a vlan is
directly configured on it.  To confirm this can you try a few things:

* Directly configure the vlan on the device instead of going through the bridge.
* Use the bridge but also configure an unused vlan device on the
physical interface.
* Double check that tcpdump with the settings that you are using shows
vlan tags in other situations.  In some cases you need to use the 'e'
flag with tcpdump in order for it show vlan tags.  If it is the
driver/NIC that is dropping the tags, tcpdump should still show them.

Thanks.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TX VLAN acceleration on bridges broken in 2.6.37?
  2011-02-25 22:53 ` Jesse Gross
@ 2011-02-26  0:19   ` Jan Niehusmann
  2011-02-26  1:16     ` Jesse Gross
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Niehusmann @ 2011-02-26  0:19 UTC (permalink / raw)
  To: Jesse Gross; +Cc: linux-kernel, netdev

On Fri, Feb 25, 2011 at 02:53:21PM -0800, Jesse Gross wrote:
> is specific to the e1000e driver.  I know that some other Intel NICs
> require vlan stripping on receive to be enabled for vlan insertion on
> transmit to work.  Since this driver has not been converted over to
> use the new vlan model yet, it only enables these things if a vlan is
> directly configured on it.  To confirm this can you try a few things:

My observations confirm your theory:

> * Directly configure the vlan on the device instead of going through the bridge.

- does work, but only if eth0 is not part of bridge (expected behaviour,
  afaik)

> * Use the bridge but also configure an unused vlan device on the
> physical interface.

- does work

> * Double check that tcpdump with the settings that you are using shows
> vlan tags in other situations.  In some cases you need to use the 'e'
> flag with tcpdump in order for it show vlan tags.  If it is the
> driver/NIC that is dropping the tags, tcpdump should still show them.

- indeed, -e is necessary to show the vlan tags. So my prior observation
  regarding tag visibility in tcpdump was wrong. The packets are still
  have a vlan tag in the non-working case. 

  (What actually is affected by the txvlan flag is the ability to filter
  for vlan tags with tcpdump.  so 'tcpdump -e -i eth0' shows the packets,
  'tcpdump -e -i eth0 vlan' only shows them with txvlan off. However,
  filtering for the vlan tag also doesn't work with the vlan interface
  on eth0.1, while the tagging actually works, as verified above.)


Jan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TX VLAN acceleration on bridges broken in 2.6.37?
  2011-02-26  0:19   ` Jan Niehusmann
@ 2011-02-26  1:16     ` Jesse Gross
  2011-02-26  1:22       ` Jeff Kirsher
  0 siblings, 1 reply; 6+ messages in thread
From: Jesse Gross @ 2011-02-26  1:16 UTC (permalink / raw)
  To: Jan Niehusmann; +Cc: linux-kernel, netdev, Tantilov, Emil S, Kirsher, Jeffrey T

On Fri, Feb 25, 2011 at 4:19 PM, Jan Niehusmann <jan@gondor.com> wrote:
> On Fri, Feb 25, 2011 at 02:53:21PM -0800, Jesse Gross wrote:
>> is specific to the e1000e driver.  I know that some other Intel NICs
>> require vlan stripping on receive to be enabled for vlan insertion on
>> transmit to work.  Since this driver has not been converted over to
>> use the new vlan model yet, it only enables these things if a vlan is
>> directly configured on it.  To confirm this can you try a few things:
>
> My observations confirm your theory:

OK, thanks for confirming.  The right solution is convert the driver
over to the new vlan model.  I don't know how soon I might get to
this, maybe it's something that the Intel guys can take a look at?

> - indeed, -e is necessary to show the vlan tags. So my prior observation
>  regarding tag visibility in tcpdump was wrong. The packets are still
>  have a vlan tag in the non-working case.
>
>  (What actually is affected by the txvlan flag is the ability to filter
>  for vlan tags with tcpdump.  so 'tcpdump -e -i eth0' shows the packets,
>  'tcpdump -e -i eth0 vlan' only shows them with txvlan off. However,
>  filtering for the vlan tag also doesn't work with the vlan interface
>  on eth0.1, while the tagging actually works, as verified above.)

Good to know, though that's a separate issue.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TX VLAN acceleration on bridges broken in 2.6.37?
  2011-02-26  1:16     ` Jesse Gross
@ 2011-02-26  1:22       ` Jeff Kirsher
  0 siblings, 0 replies; 6+ messages in thread
From: Jeff Kirsher @ 2011-02-26  1:22 UTC (permalink / raw)
  To: Jesse Gross, Allan, Bruce W
  Cc: Jan Niehusmann, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, Tantilov, Emil S

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

On Fri, 2011-02-25 at 17:16 -0800, Jesse Gross wrote:
> On Fri, Feb 25, 2011 at 4:19 PM, Jan Niehusmann <jan@gondor.com> wrote:
> > On Fri, Feb 25, 2011 at 02:53:21PM -0800, Jesse Gross wrote:
> >> is specific to the e1000e driver.  I know that some other Intel NICs
> >> require vlan stripping on receive to be enabled for vlan insertion on
> >> transmit to work.  Since this driver has not been converted over to
> >> use the new vlan model yet, it only enables these things if a vlan is
> >> directly configured on it.  To confirm this can you try a few things:
> >
> > My observations confirm your theory:
> 
> OK, thanks for confirming.  The right solution is convert the driver
> over to the new vlan model.  I don't know how soon I might get to
> this, maybe it's something that the Intel guys can take a look at?

I have made sure that Bruce is aware of the issue.

We will see what we can do to get some patches created and under
testing.

> 
> > - indeed, -e is necessary to show the vlan tags. So my prior observation
> >  regarding tag visibility in tcpdump was wrong. The packets are still
> >  have a vlan tag in the non-working case.
> >
> >  (What actually is affected by the txvlan flag is the ability to filter
> >  for vlan tags with tcpdump.  so 'tcpdump -e -i eth0' shows the packets,
> >  'tcpdump -e -i eth0 vlan' only shows them with txvlan off. However,
> >  filtering for the vlan tag also doesn't work with the vlan interface
> >  on eth0.1, while the tagging actually works, as verified above.)
> 
> Good to know, though that's a separate issue.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-02-26  1:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-21 23:29 TX VLAN acceleration on bridges broken in 2.6.37? Jan Niehusmann
2011-02-23  1:32 ` Jesse Gross
2011-02-25 22:53 ` Jesse Gross
2011-02-26  0:19   ` Jan Niehusmann
2011-02-26  1:16     ` Jesse Gross
2011-02-26  1:22       ` Jeff Kirsher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).