From: Jiri Pirko <jiri@resnulli•us>
To: Scott Feldman <sfeldma@gmail•com>
Cc: roopa <roopa@cumulusnetworks•com>,
Florian Fainelli <f.fainelli@gmail•com>,
Guenter Roeck <linux@roeck-us•net>,
John Fastabend <john.fastabend@gmail•com>,
Andrew Lunn <andrew@lunn•ch>, David Miller <davem@davemloft•net>,
"Arad, Ronen" <ronen.arad@intel•com>,
Netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets
Date: Thu, 26 Mar 2015 09:20:11 +0100 [thread overview]
Message-ID: <20150326082011.GA2010@nanopsycho.orion> (raw)
In-Reply-To: <CAE4R7bCtpaonLeRiX9s3yFisONDQUv9z_EOBcGTdgTGLEjC7vA@mail.gmail.com>
Thu, Mar 26, 2015 at 08:44:27AM CET, sfeldma@gmail•com wrote:
>On Wed, Mar 25, 2015 at 10:01 AM, roopa <roopa@cumulusnetworks•com> wrote:
>
>[cut]
>
>So just to keep the discussion alive (because we really need to solve
>this problem), my current thinking is back to Roopa's RFC patch to
>mark the skb to avoid fwding in bridge driver. One idea (sorry if
>this was already suggested, thread is long) is to use
>swdev_parent_id_get op in the following way:
>
>1) when port interface is added to bridge, bridge calls
>swdev_parent_id_get() on port to get switch id.
>swdev_parent_id_get() needs to be modified to work on stacked drivers.
>For example, if a bond is the new bridge port, swdev_parent_id_get()
>on the bond interface should get switch_id for bond member. We stash
>the switch_id in the bridge port private structure for later
>comparison.
Nope, that cannot work. You can bond 2 ports each belonging to a
different switch.
swdev_parent_id_get should not work on stacked devices ever.
>
>2) port driver knows the switch_id for the port, so any pkts it sends
>up to the CPU which has already been flooded/fwded by the device are
>marked with the switch_id. So the skb is marked, somehow. Some
>options:
>
> a) add a new skb switch_id field that's wrapped with
>CONFIG_NET_SWITCHDEV; seems bad, to add a new field.
> b) put switch_id into skb->cb, but not sure how this doesn't get
>stomped on by upper drivers, or how
> bridge knows if something valid is in there or not. Too bad we
>don't have a TLV format for skb->cb, so
> layers could pile things on. But 48 bytes isn't much to play with.
> c) squash switch_id into u32 skb->mark. We loose information here
>and could collide between switch_ids.
>
>3) bridge driver, in br_flood(), does check if skb switch_id mark
>matches dst port switch_id. If so, skips fwding pkt to that port.
>The switch_id compare check compares switch_id len and contents. If
>skb has no switch_id mark, then compare can be skipped.
>
>
>The only tough part is figuring out 2). Just need someway to stuff
>switch_id into skb. With bridge driver doing match on switch_id on a
>per-packet basis, we can support Florian's case where sometimes we
>want the bridge driver to fwd pkts (in those cases, the driver just
>leaves skb switch_id mark empty). Mixed offloaded and non-offloaded
>ports works because switch_id comparison fails for non-offload ports.
>Same for mixed switches bridged together. The per-pkt overhead
>concerns are minimized.
>
>-scott
next prev parent reply other threads:[~2015-03-26 8:20 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 16:58 [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets roopa
2015-03-20 17:11 ` John Fastabend
2015-03-20 18:13 ` Scott Feldman
2015-03-20 18:30 ` John Fastabend
2015-03-20 22:06 ` roopa
2015-03-20 22:37 ` Scott Feldman
2015-03-20 23:30 ` roopa
2015-03-21 0:26 ` Scott Feldman
2015-03-21 5:53 ` roopa
2015-03-20 21:03 ` roopa
2015-03-20 21:23 ` John Fastabend
2015-03-20 22:04 ` Andrew Lunn
2015-03-20 23:12 ` roopa
2015-03-20 18:03 ` Scott Feldman
2015-03-20 21:20 ` roopa
2015-03-20 20:36 ` David Miller
2015-03-20 21:36 ` roopa
2015-03-20 22:09 ` Andrew Lunn
2015-03-20 23:43 ` Florian Fainelli
2015-03-23 0:22 ` Guenter Roeck
2015-03-23 1:33 ` John Fastabend
2015-03-23 2:57 ` Guenter Roeck
2015-03-23 3:18 ` John Fastabend
2015-03-23 3:33 ` Guenter Roeck
2015-03-23 17:12 ` roopa
2015-03-24 5:59 ` Scott Feldman
2015-03-24 13:13 ` Guenter Roeck
2015-03-24 18:08 ` Scott Feldman
2015-03-24 14:29 ` Jiri Pirko
2015-03-24 16:01 ` Guenter Roeck
2015-03-24 17:45 ` roopa
2015-03-24 17:58 ` Guenter Roeck
2015-03-24 18:14 ` Scott Feldman
2015-03-25 3:10 ` Guenter Roeck
2015-03-25 3:46 ` Florian Fainelli
2015-03-25 5:06 ` Scott Feldman
2015-03-25 17:01 ` roopa
2015-03-26 7:44 ` Scott Feldman
2015-03-26 8:20 ` Jiri Pirko [this message]
2015-03-26 14:28 ` Scott Feldman
2015-03-26 14:49 ` Jiri Pirko
2015-03-27 1:08 ` Simon Horman
2015-03-27 6:02 ` Jiri Pirko
2015-03-27 6:43 ` Scott Feldman
2015-03-27 7:01 ` Jiri Pirko
2015-03-27 23:19 ` Scott Feldman
2015-03-30 14:06 ` roopa
2015-03-24 18:48 ` David Christensen
2015-03-24 17:58 ` Scott Feldman
2015-03-23 17:10 ` roopa
2015-03-23 14:00 ` roopa
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=20150326082011.GA2010@nanopsycho.orion \
--to=jiri@resnulli$(echo .)us \
--cc=andrew@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=linux@roeck-us$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=ronen.arad@intel$(echo .)com \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=sfeldma@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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