[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikVvjsaG94-gtauvTLjH_RW5fmva8+N7Lk-ryQ0@mail.gmail.com>
Date: Fri, 25 Feb 2011 17:16:35 -0800
From: Jesse Gross <jesse@...ira.com>
To: Jan Niehusmann <jan@...dor.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
"Tantilov, Emil S" <emil.s.tantilov@...el.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: Re: TX VLAN acceleration on bridges broken in 2.6.37?
On Fri, Feb 25, 2011 at 4:19 PM, Jan Niehusmann <jan@...dor.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists