From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vlad Yasevich <vyasevic@redhat.com>
Cc: john.r.fastabend@intel.com, netdev@vger.kernel.org,
shemminger@vyatta.com, bridge@lists.linux-foundation.org,
jhs@mojatatu.com
Subject: Re: [PATCH net-next 0/8] Non-promisc bidge ports support
Date: Wed, 14 May 2014 18:21:37 +0300 [thread overview]
Message-ID: <20140514152137.GA11339@redhat.com> (raw)
In-Reply-To: <1400080168-16625-1-git-send-email-vyasevic@redhat.com>
On Wed, May 14, 2014 at 11:09:20AM -0400, Vlad Yasevich wrote:
> This series adds functionality to the bridge device to enable
> operations without setting all ports to promiscuous mode.
>
> The basic concept is this. The bridge keeps track of the ports
> that support learning and flooding packets to unknown destinations.
> We call these ports auto-discovery ports since they automatically
> discover who is behind them through learning and flooding.
>
> If flooding and learning are disabled via flags, then the port
> requires static configuration to tell it which mac addresses
> are behind it. This is accomplished through adding of fdbs.
> These fdbs should be static as dynamic fdbs can expire and systems
> will become unreachable due to lack of flooding.
>
> If the user marks all ports as needing static configuration then
> we can safely make them non-promiscuous since we will know all the
> information about them.
>
> If the user leaves only 1 port as automatic, then we can mark
> that port as not-promiscuous as well. One could think of
> this a edge relay similar to what's support by embedded switches
> in SRIOV devices. Since we have all the information about the
> other ports, we can just program the mac addresses into the
> single automatic port to receive all necessary traffic.
> More information about this is patch 6.
>
> In other cases, we keep all ports promiscuous as before.
>
> There are some other cases when promiscuous mode has to be turned
> back on. One is when the bridge itself if placed in promiscuous
> mode (user sets promisc flag). The other is if vlan filtering is
> turned off. Since this is the default configuration, the default
> bridge operation is not changed.
>
> Changes since rfc v2:
> - Better description of in the commit logs
> - Leave port in promiscuous mode if IFF_UNICAST_FLT is disabled on the
> device.
> - Fix issue with flag masking
> - Rework patch ordering a bit.
>
> Changes since rfc v1:
> - Removed private list. We now traverse the fdb hashtable itself
> to write necessary addresses to the ports (Stephen's concern)
> - Add learning flag to the mask for flags that decides if the port
> is 'auto' or not (suggest by MST and Jamal).
> - Simplified tracking of such ports at the cost of a loop over all
> ports (suggested by MST)
>
> I've played with quite a large number of ports and the current approach
> seems to work fairly well.
>
> Thanks
> -vlad
For the series
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Vlad Yasevich (8):
> bridge: Turn flag change macro into a function.
> bridge: Keep track of ports capable of automatic discovery.
> bridge: Add functionality to sync static fdb entries to hw
> bridge: Introduce BR_PROISC flag
> bridge: Add addresses from static fdbs to non-promisc ports
> bridge: Automatically manage port promiscuous mode.
> bridge: Correctly manage promiscuity when user requested it.
> bridge: Automatically manage promisc mode when vlan filtering is on.
>
> net/bridge/br_device.c | 7 +++
> net/bridge/br_fdb.c | 132 ++++++++++++++++++++++++++++++++++++++++++++---
> net/bridge/br_if.c | 126 ++++++++++++++++++++++++++++++++++++++++++--
> net/bridge/br_netlink.c | 3 ++
> net/bridge/br_private.h | 20 +++++++
> net/bridge/br_sysfs_if.c | 31 +++++++----
> net/bridge/br_vlan.c | 1 +
> 7 files changed, 300 insertions(+), 20 deletions(-)
>
> --
> 1.9.0
next prev parent reply other threads:[~2014-05-14 15:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 15:09 [PATCH net-next 0/8] Non-promisc bidge ports support Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 1/8] bridge: Turn flag change macro into a function Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 2/8] bridge: Keep track of ports capable of automatic discovery Vlad Yasevich
2014-05-14 15:40 ` Stephen Hemminger
2014-05-14 15:42 ` Stephen Hemminger
2014-05-15 16:04 ` Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 3/8] bridge: Add functionality to sync static fdb entries to hw Vlad Yasevich
2014-05-14 20:47 ` Sergei Shtylyov
2014-05-14 15:09 ` [PATCH net-next 4/8] bridge: Introduce BR_PROMISC flag Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 5/8] bridge: Add addresses from static fdbs to non-promisc ports Vlad Yasevich
2014-05-14 20:44 ` Sergei Shtylyov
2014-05-14 15:09 ` [PATCH net-next 6/8] bridge: Automatically manage port promiscuous mode Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 7/8] bridge: Correctly manage promiscuity when user requested it Vlad Yasevich
2014-05-14 15:09 ` [PATCH net-next 8/8] bridge: Automatically manage promisc mode when vlan filtering is on Vlad Yasevich
2014-05-14 20:41 ` Sergei Shtylyov
2014-05-14 15:21 ` Michael S. Tsirkin [this message]
2014-05-14 19:29 ` [PATCH net-next 0/8] Non-promisc bidge ports support David Miller
2014-05-15 16:09 ` Vlad Yasevich
2014-05-15 12:55 ` Toshiaki Makita
2014-05-15 13:02 ` Toshiaki Makita
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=20140514152137.GA11339@redhat.com \
--to=mst@redhat.com \
--cc=bridge@lists.linux-foundation.org \
--cc=jhs@mojatatu.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=vyasevic@redhat.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).