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: <50F04EDC.9040309@redhat.com>
Date:	Fri, 11 Jan 2013 12:41:48 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Stephen Hemminger <shemminger@...tta.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 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.
>

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