All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on received packets
Date: Wed, 27 Sep 2017 22:11:20 +0200	[thread overview]
Message-ID: <20170927201120.GG12394@lunn.ch> (raw)
In-Reply-To: <1c4ba973-91c0-ae81-1c4b-d0281f5c7517@gmail.com>

On Wed, Sep 27, 2017 at 12:46:35PM -0700, Florian Fainelli wrote:
> On 09/26/2017 03:25 PM, Andrew Lunn wrote:
> > The software bridge needs to know if a packet has already been bridged
> > by hardware offload to ports in the same hardware offload, in order
> > that it does not re-flood them, causing duplicates. This is
> > particularly true for broadcast and multicast traffic which the host
> > has requested.
> > 
> > By setting offload_fwd_mark in the skb the bridge will only flood to
> > ports in other offloads and other netifs. Set this flag in the DSA and
> > EDSA tag driver.
> 
> Is not there some kind of forwarding code/reason code being provided in
> the EDSA/DSA tag that tell you why this packet was sent to the CPU in
> the first place?

Hi Florian

There are some codes, but nothing specific to broadcast, or ATU
misses. I'm also trying to keep the code generic so it could be a
template for other drivers. Many of the tagging schemes don't provide
a reason code. So i want that any frame that comes from the switch has
no need to go back to the switch. KISS.
 
> What is the impact on non-broadcast traffic, e.g: multicast and unicast?

The bridge uses this flag when flooding. unicast traffic from the
switch should not need flooding. Either it is known in the switch and
hence won't be forwarded to the host, or it is unknown in the switch,
so it probably is on some other interface.

My testing with multicast has not shown issues. The switch pushes down
mdb entries, which causes frames to be replicated out ports. So again,
there should not be a need to pass the frame back to the switch. But
it is possible i missed a corner case or two...
 
> Nit: I don't really have a solution on how to order patches, but until
> the next 4 patches get in, I suppose we temporarily have broadcast
> flooding by the bridge "broken"? Ordering in the opposite way would
> probably result in an equally bad situation so...

Yes, it is an issue. I could put this patch last. We then get
duplication of broadcast...

Which is the lesser of two evils?

      Andrew

  reply	other threads:[~2017-09-27 20:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-26 22:25 [PATCH net-next 0/6] mv88e6xxx broadcast flooding in hardware Andrew Lunn
2017-09-26 22:25 ` [PATCH net-next 1/6] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID Andrew Lunn
2017-09-27 10:15   ` Sergei Shtylyov
2017-09-27 15:31   ` Vivien Didelot
2017-09-26 22:25 ` [PATCH net-next 2/6] net: dsa: {e}dsa: set offload_fwd_mark on received packets Andrew Lunn
2017-09-27 19:46   ` Florian Fainelli
2017-09-27 20:11     ` Andrew Lunn [this message]
2017-09-26 22:26 ` [PATCH net-next 3/6] net: dsa: mv88e6xxx: Fixed port netdev check for VLANs Andrew Lunn
2017-09-26 22:26 ` [PATCH net-next 4/6] net: dsa: mv88e6xxx: Print offending port when vlan check fails Andrew Lunn
2017-09-27 15:49   ` Vivien Didelot
2017-09-26 22:26 ` [PATCH net-next 5/6] net: dsa: mv88e6xxx: Move mv88e6xxx_port_db_load_purge() Andrew Lunn
2017-09-27 15:51   ` Vivien Didelot
2017-09-26 22:26 ` [PATCH net-next 6/6] net: dsa: mv88e6xxx: Flood broadcast frames in hardware Andrew Lunn
2017-09-27 18:24   ` Vivien Didelot
2017-09-27 18:36     ` Andrew Lunn
2017-09-27 18:59       ` Vivien Didelot
2017-09-27 18:37     ` Florian Fainelli
2017-09-27 18:46       ` Andrew Lunn
2017-09-27 19:19         ` Vivien Didelot
2017-09-27 19:33           ` Florian Fainelli
2017-09-27 20:18             ` Andrew Lunn
2017-09-26 22:26 ` [PATCH 6/6] net: dsa: mv88e6xxx: Forward broadcast frames to cpu and dsa ports Andrew Lunn
2017-09-26 22:43   ` Andrew Lunn
2017-09-27  3:20   ` David Miller
2017-09-27 18:28 ` [PATCH net-next 0/6] mv88e6xxx broadcast flooding in hardware Vivien Didelot

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=20170927201120.GG12394@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.