netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Cc: ivecera@redhat.com, jiri@resnulli.us, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org,
	sergey.matyukevich.os@quantenna.com, ashevchenko@quantenna.com,
	smaksimenko@quantenna.com, dlebed@quantenna.com
Subject: Re: [RFC PATCH net-next 3/5] bridge: allow switchdev port to handle flooding by itself
Date: Sat, 10 Mar 2018 17:55:40 +0100	[thread overview]
Message-ID: <20180310165540.GH29174@lunn.ch> (raw)
In-Reply-To: <20180310030308.12947-4-igor.mitsyanko.os@quantenna.com>

On Fri, Mar 09, 2018 at 07:03:06PM -0800, Igor Mitsyanko wrote:
> Introduce BR_FLOOD_OFFLOAD bridge port flag that can be used by
> switchdev-capable hardware to advertize that it wants to handle all
> flooding by itself.
> In that case there is no need for a driver to set skb::offload_fwd_mark
> on each offloaded packet as it is implied by BR_FLOOD_OFFLOAD bridge
> port flag.

Is this sufficiently granular? There are a few different use cases for
flooding:

There is no fdb entry in the software switch for the destination MAC
address, so flood the packet out all ports of the bridge. The hardware
switch might have an entry in its fdb to the destination switch, so it
could unicast out the correct hardware port. If not, it should flood
the packet.

A point to remember here, the software switch and the hardware switch
can have different forwarding data bases.

A broadcast packet. Send it out all ports.

A multicast packet. If the hardware switch is capable of IGMP
snooping, it could have FDB entries indicating which ports it should
send the frame out of, and which is should not. Otherwise it needs to
flood.

Is one flag sufficient for all of these, and any other use cases i
might of missed?

As far as DSA switches go, i don't know of any of them which could
implement anything like this, so BR_FLOOD_OFFLOAD will never be
set. But maybe some of the TOR switches supported by switchdev can do
some of these, and not others....

     Andrew

  reply	other threads:[~2018-03-10 16:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10  3:03 [PATCH net-next 0/5] Switchdev: flooding offload option Igor Mitsyanko
2018-03-10  3:03 ` [PATCH net-next 1/5] bridge: initialize port flags with switchdev defaults Igor Mitsyanko
2018-03-10 16:30   ` Andrew Lunn
2018-03-12 18:44     ` Igor Mitsyanko
2018-03-10 16:32   ` Stephen Hemminger
2018-03-12 19:03     ` Igor Mitsyanko
2018-03-10  3:03 ` [PATCH net-next 2/5] bridge: propagate BR_ flags updates through sysfs to switchdev Igor Mitsyanko
2018-03-10 16:38   ` Andrew Lunn
2018-03-12 20:07     ` Igor Mitsyanko
2018-03-10  3:03 ` [RFC PATCH net-next 3/5] bridge: allow switchdev port to handle flooding by itself Igor Mitsyanko
2018-03-10 16:55   ` Andrew Lunn [this message]
2018-03-12 23:00     ` Igor Mitsyanko
2018-03-13  1:11       ` Andrew Lunn
2018-03-13 14:41         ` Roopa Prabhu
2018-03-10  3:03 ` [RFC PATCH net-next 4/5] bridge: provide sysfs and netlink interface to set BR_FLOOD_OFFLOAD Igor Mitsyanko
2018-03-10  3:03 ` [RFC PATCH net-next 5/5] bridge: verify "HW only" flags can't be set without HW support Igor Mitsyanko
2018-03-10 22:08 ` [PATCH net-next 0/5] Switchdev: flooding offload option Andrew Lunn
2018-03-12 23:08   ` Igor Mitsyanko

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=20180310165540.GH29174@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=ashevchenko@quantenna.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=dlebed@quantenna.com \
    --cc=igor.mitsyanko.os@quantenna.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=sergey.matyukevich.os@quantenna.com \
    --cc=smaksimenko@quantenna.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).