From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
sfeldma@gmail.com, bcrl@kvack.org, tgraf@suug.ch,
john.fastabend@gmail.com, stephen@networkplumber.org,
linville@tuxdriver.com, vyasevic@redhat.com,
netdev@vger.kernel.org, davem@davemloft.net,
shm@cumulusnetworks.com, gospo@cumulusnetworks.com
Subject: Re: [PATCH net-next v2 2/4] swdevice: add new api to set and del bridge port attributes
Date: Mon, 15 Dec 2014 09:20:18 -0800 [thread overview]
Message-ID: <548F1852.7090507@cumulusnetworks.com> (raw)
In-Reply-To: <548EFD94.8070905@mojatatu.com>
On 12/15/14, 7:26 AM, Jamal Hadi Salim wrote:
>
> Sorry - i didnt quiet follow the discussion, but i can see the value
> of propagating things from parent to children netdevs as part of the
> generic approach. And in that spirit:
>
> Ben's patches (and I am sure the cumulus folk do this) expose ports.
> i.e you boot up the hardware and you see ports. You can then put these
> ports in a bridge and you can offload fdbs and do other parametrization
> to the ASIC. IOW, this only becomes a bridge because you created one
> in the kernel and attached bridge ports to it.
>
> Lets say i didnt want a bridge. I want instead to take these exposed
> ports and create a bond (and maybe play with LACP). How does this
> propagation from parent->child->child work then? I think the idea
> of just bonding and not exposing it as a switch is a reasonable use
> case.
We have not come to pure bonding and lacp yet (but i have mentioned it
in many contexts before).
The use case you mention is offloading bond attributes. This will be
addressed as part of ongoing switchdev work
for all other offloads (bonds, vxlans etc).
Right now we are only talking bridge port attribute offload
(learn/flood/port state etc). This could still be a bridge port
attribute on a bond
when the bond is a bridge port.
> Also how does it work when i start doing L3 and the bond's port doesnt
> support L3? Is it time to revive the thing we called TheThing in Du?
yes, exactly. This is what i had indicated in my initial emails on this
thread when the stacked devices topic came up.
Since there was reluctance in introducing a switch device (theThing), My
current patch tries to do that without a switch device.
Since this is still l2, and we are dealing with bridge port attributes,
my current patch traverses the stacked netdevs to call the
ndo_bridge_setlink on the switch port.
When it comes to l3, we can follow the same.., but as discussed in Du,
there are other reasons where a switch device becomes necessary.
I can submit an alternate series to cover the switch device approach for
l2 as well.
Thanks,
Roopa
next prev parent reply other threads:[~2014-12-15 17:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 9:05 [PATCH net-next v2 2/4] swdevice: add new api to set and del bridge port attributes roopa
2014-12-10 9:37 ` Jiri Pirko
2014-12-11 16:52 ` Roopa Prabhu
2014-12-11 17:11 ` Jiri Pirko
2014-12-11 17:59 ` Roopa Prabhu
2014-12-11 18:07 ` Jiri Pirko
2014-12-11 18:27 ` Roopa Prabhu
2014-12-11 22:25 ` Jiri Pirko
2014-12-14 14:13 ` Roopa Prabhu
2014-12-14 15:35 ` Jiri Pirko
2014-12-14 19:41 ` Roopa Prabhu
2014-12-15 15:26 ` Jamal Hadi Salim
2014-12-15 17:20 ` Roopa Prabhu [this message]
2014-12-15 18:03 ` Benjamin LaHaise
2014-12-15 17:25 ` Arad, Ronen
2014-12-15 17:57 ` Benjamin LaHaise
2014-12-15 17:57 ` John Fastabend
2014-12-15 18:36 ` Arad, Ronen
2014-12-15 23:27 ` Jamal Hadi Salim
2014-12-16 0:58 ` Arad, Ronen
2014-12-16 1:20 ` Roopa Prabhu
2014-12-16 11:01 ` Arad, Ronen
2014-12-16 15:54 ` Samudrala, Sridhar
2014-12-16 16:41 ` John Fastabend
2014-12-16 17:29 ` Arad, Ronen
2014-12-16 19:23 ` B Viswanath
2014-12-16 20:52 ` Arad, Ronen
2014-12-16 21:51 ` B Viswanath
2014-12-16 22:46 ` Arad, Ronen
2014-12-16 19:25 ` Roopa Prabhu
2014-12-16 19:20 ` Roopa Prabhu
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=548F1852.7090507@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=gospo@cumulusnetworks.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=shm@cumulusnetworks.com \
--cc=stephen@networkplumber.org \
--cc=tgraf@suug.ch \
--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).