RE: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces functional after rxvlan off

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@xxxxxxxxxxxxxxxx] On
> Behalf Of Jeff Kirsher
> Sent: Wednesday, May 18, 2016 2:40 PM
> To: Jarod Wilson <jarod@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> Avargil, Raanan <raanan.avargil@xxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; intel-wired-lan@xxxxxxxxxxxxxxxx
> Subject: Re: [Intel-wired-lan] [RFC PATCH net] e1000e: keep vlan interfaces
> functional after rxvlan off
> 
> On Tue, 2016-05-17 at 15:03 -0400, Jarod Wilson wrote:
> > I've got a bug report about an e1000e interface, where a vlan interface
> > is
> > set up on top of it:
> >
> > $ ip link add link ens1f0 name ens1f0.99 type vlan id 99
> > $ ip link set ens1f0 up
> > $ ip link set ens1f0.99 up
> > $ ip addr add 192.168.99.92 dev ens1f0.99
> >
> > At this point, I can ping another host on vlan 99, ip 192.168.99.91.
> > However, if I do the following:
> >
> > $ ethtool -K ens1f0 rxvlan off
> >
> > Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on
> > again. I'm not sure if this is actually intended behavior, or if there's
> > a
> > lack of software vlan stripping fallback, or what, but things continue to
> > work if I simply don't call e1000e_vlan_strip_disable() if there are
> > active vlans (plagiarizing a function from the e1000 driver here) on the
> > interface.
> >
> > Also slipped a related-ish fix to the kerneldoc text for
> > e1000e_vlan_strip_disable here...
> >
> > CC: Jeff Kirsher <jeffrey.t.kirsher@xxxxxxxxx>
> > CC: intel-wired-lan@xxxxxxxxxxxxxxxx
> > CC: netdev@xxxxxxxxxxxxxxx
> > Signed-off-by: Jarod Wilson <jarod@xxxxxxxxxx>
> > ---
> > Âdrivers/net/ethernet/intel/e1000e/netdev.c | 15 +++++++++++++--
> > Â1 file changed, 13 insertions(+), 2 deletions(-)
> 
> Raanan, please review this patch. ÂEven though it is an RFC I will be
> adding it to my queue for testing.
> http://patchwork.ozlabs.org/patch/623238/

Yup, without this patch disabling rxvlan offload does indeed break vlan connectivity and with the patch I can disable and re-enable rxvlan offloads as much as I care to.  It also makes it through my regression tests without problems.

Tested-by: Aaron Brown <aaron.f.brown@xxxxxxxxx>

This is from functional - does it work - testing perspective so review is probably still in order.