netdev - Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130111102318.579abe94@nehalam.linuxnetplumber.net>
Date:	Fri, 11 Jan 2013 10:23:18 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	vyasevic@...hat.com
Cc:	netdev@...r.kernel.org, davem@...emloft.net, stephen@...hat.com,
	bridge@...ts.linux-foundation.org, shmulik.ladkani@...il.com,
	mst@...hat.com
Subject: Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in
 separate functions.

On Fri, 11 Jan 2013 12:41:48 -0500
Vlad Yasevich <vyasevic@...hat.com> wrote:

> On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
> > What I think is the least intrusive and allows for maximum flexibility
> > is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
> > There already is drivers that depend on that value to enable filtering.
> >
> 
> The only thing that I see depending on CONFIG_VLAN_8021Q is 
> CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
> There are currently no other drivers depending on 8021Q functionality
> and vlan filtering in drivers doesn't depend on 8021Q support in
> the kernel.
> 
> I admit that I've thought of having a dependency on 8021Q as it would 
> have allowed me to re-use a bit more code, but decided that bridge 
> should be able to stand on its own in this regard.  8021Q is not 
> necessary to turn on VLAN accelerated filtering on the nics as anyone 
> can do it through the ndo_vlan_rx_add_vid() call.
> 
> The reason for this patch was to make the nic vlan filter code reusable
> and address Jiri Pirko's comment in the V2 series.
> (http://marc.info/?l=linux-netdev&m=135590565719164&w=2).  This way,
> bridge wouldn't need to make direct ndo_ calls and all call sights will
> be consistent.
> 
> > And make the support of VLAN filtering in the bridge conditional like
> > IGMP snooping is optional
> 
> I could certainly make the VLAN filtering conditional, but I am not sure 
> what it would buy us other then a lot of ifdefs.
> 
> Thanks
> -vlad
> 
> >
> > --- a/net/bridge/Kconfig
> > +++ b/net/bridge/Kconfig
> > @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
> >            Say N to exclude this support and reduce the binary size.
> >
> >            If unsure, say Y.
> > +
> > +config BRIDGE_VLAN_FILTERING
> > +       bool "VLAN filtering"
> > +       depends on BRIDGE
> > +       depends on VLAN_8021Q
> > +       default n
> > +       ---help---
> > +         If you say Y here, then the Ethernet bridge will be able to
> > +        selectively filter traffic based on VLAN tag.
> > +
> > +        Say N to exclude this support and reduce the binary size.
> > +
> > +        If unsure, say Y.
> >
> 

Doing the following shows several drivers that still depend on VLAN_8021Q being
enabled to do VLAN tagging.
$ git grep -l CONFIG_VLAN_8021Q
ethernet/3com/3c59x.c
ethernet/adaptec/starfire.c
ethernet/amd/amd8111e.c
ethernet/broadcom/cnic.c
ethernet/broadcom/tg3.c
ethernet/dlink/sundance.c
ethernet/natsemi/ns83820.c
ethernet/sis/sis900.c
ethernet/sis/sis900.h
ethernet/stmicro/stmmac/common.h

 
--
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