netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	netdev@vger.kernel.org, davem@davemloft.net,
	bridge@lists.linux-foundation.org, mst@redhat.com
Subject: Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure
Date: Fri, 11 Jan 2013 10:33:35 -0500	[thread overview]
Message-ID: <50F030CF.20800@redhat.com> (raw)
In-Reply-To: <20130111155354.4ff8aeac.shmulik.ladkani@gmail.com>

On 01/11/2013 08:53 AM, Shmulik Ladkani wrote:
> Hi,
>
> On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic@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.

Right.

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

-vlad

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

  reply	other threads:[~2013-01-11 15:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 17:17 [PATCH net-next V5 00/14] Add basic VLAN support to bridges Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions Vlad Yasevich
2013-01-10 18:25   ` Stephen Hemminger
2013-01-10 18:41     ` Vlad Yasevich
2013-01-10 22:07       ` Stephen Hemminger
2013-01-11  1:08         ` Vlad Yasevich
2013-01-11 17:20           ` Stephen Hemminger
2013-01-11 17:41             ` Vlad Yasevich
2013-01-11 18:23               ` Stephen Hemminger
2013-01-11 18:53                 ` Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure Vlad Yasevich
2013-01-10 18:36   ` Stephen Hemminger
2013-01-10 19:01     ` Vlad Yasevich
2013-01-10 19:23       ` Vlad Yasevich
2013-01-10 22:10         ` Stephen Hemminger
2013-01-11  1:14           ` Vlad Yasevich
2013-01-11 13:53             ` Shmulik Ladkani
2013-01-11 15:33               ` Vlad Yasevich [this message]
2013-01-09 17:17 ` [PATCH net-next v5 03/14] bridge: Validate that vlan is permitted on ingress Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 04/14] bridge: Verify that a vlan is allowed to egress on give port Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 05/14] bridge: Cache vlan in the cb for faster egress lookup Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 06/14] bridge: Add vlan to unicast fdb entries Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 07/14] bridge: Add vlan id to multicast groups Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 08/14] bridge: Add netlink interface to configure vlans on bridge ports Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 09/14] bridge: Add vlan support to static neighbors Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 10/14] bridge: Add the ability to configure pvid Vlad Yasevich
2013-01-09 17:17 ` [PATCH 10/14] bridge: Add the ability to pvid Vlad Yasevich
2013-01-09 17:24   ` Vlad Yasevich
2013-01-09 17:17 ` [PATCH net-next v5 11/14] bridge: API to configure egress policy Vlad Yasevich
2013-01-09 17:18 ` [PATCH net-next v5 12/14] bridge: Implement vlan ingress/egress policy Vlad Yasevich
2013-01-09 17:18 ` [PATCH net-next v5 13/14] bridge: Dump vlan information from a bridge port Vlad Yasevich
2013-01-09 17:18 ` [PATCH net-next v5 14/14] bridge: Add vlan support for local fdb entries Vlad Yasevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F030CF.20800@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=shmulik.ladkani@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).