[Bridge] [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure

Vlad Yasevich vyasevic at redhat.com
Fri Jan 11 15:33:41 UTC 2013

On 01/11/2013 08:53 AM, Shmulik Ladkani wrote:
> Hi,
> On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic at redhat.com> wrote:
>> On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
>>> Also the concept of different filters for egress vs ingress is feature
>>> madness. It doesn't make sense to have half-duplex connectivity.
>> I am of the same opinion, but it actually simplified the code quite a
>> bit, but at the cost of additional memory footprint.  If you find this
>> very objectionable, I can easily remove it.
> Haven't looked on the V5 series yet, but just to clarify:
> There's *no* different membership _filter_ for egress vs ingress.
> The vlan's membership map is consulted on both ingress and egress.


> However, upon egress, a vlan egress _policy_ should be applied, which
> determines whether the frame should egress tagged/untagged on the egress
> port.

Right.  This is how it is implemented in this series and this is what 
Stephen finds "mad".  You can configure the policy that on egress the 
packet is untagged, but on ingress it has to be tagged.  This kind of 
half-duplex configuration is very prone to errors.


> The expected logic in detailed in [1] (please read "steps 1..5").
> and the data structures needed are:
>    - per port: PVID
>    - per VLAN: port membership map
>    - per VLAN: port egress policy map
> Altough on 1st look it might look mad ;-)
> But, this is genuinely simple, highly configurable and allows great
> flexibility (IMO with no additional code complexity; Vlad can probably
> comment).
> The motivation is to be aligned with behavior and configurability of
> vlan switches.
> Regards,
> Shmulik
> [1]
> http://marc.info/?l=linux-netdev&m=135603447030826&w=2

More information about the Bridge mailing list