From: roopa <roopa@cumulusnetworks•com>
To: Scott Feldman <sfeldma@gmail•com>
Cc: Florian Fainelli <f.fainelli@gmail•com>,
Guenter Roeck <linux@roeck-us•net>, Jiri Pirko <jiri@resnulli•us>,
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: Mon, 30 Mar 2015 07:06:06 -0700 [thread overview]
Message-ID: <5519584E.3050704@cumulusnetworks.com> (raw)
In-Reply-To: <CAE4R7bCtpaonLeRiX9s3yFisONDQUv9z_EOBcGTdgTGLEjC7vA@mail.gmail.com>
On 3/26/15, 12:44 AM, Scott Feldman 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.
>
> 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).
c) might be out of the question if userspace is using any markings and
it may get overwritten.
> 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).
I have this case too and that's why i had the flag in the skb.
Agree, having switchid there will help with the overhead associated with
looking up the switchid again.
> 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.
>
Thanks for keeping this discussion going.
next prev parent reply other threads:[~2015-03-30 14:06 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
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 [this message]
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=5519584E.3050704@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--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=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