[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <E4CD12F19ABA0C4D8729E087A761DC3505D999EA@ORSMSX106.amr.corp.intel.com>
Date: Mon, 15 Dec 2014 17:25:00 +0000
From: "Arad, Ronen" <ronen.arad@...el.com>
To: Jamal Hadi Salim <jhs@...atatu.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Jiri Pirko <jiri@...nulli.us>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "sfeldma@...il.com" <sfeldma@...il.com>,
"bcrl@...ck.org" <bcrl@...ck.org>, "tgraf@...g.ch" <tgraf@...g.ch>,
"john.fastabend@...il.com" <john.fastabend@...il.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"linville@...driver.com" <linville@...driver.com>,
"vyasevic@...hat.com" <vyasevic@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"shm@...ulusnetworks.com" <shm@...ulusnetworks.com>,
"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>
Subject: RE: [PATCH net-next v2 2/4] swdevice: add new api to set and del
bridge port attributes
> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Jamal Hadi Salim
> Sent: Monday, December 15, 2014 5:26 PM
> To: Roopa Prabhu; Jiri Pirko
> Cc: sfeldma@...il.com; bcrl@...ck.org; tgraf@...g.ch;
> john.fastabend@...il.com; stephen@...workplumber.org;
> linville@...driver.com; vyasevic@...hat.com; netdev@...r.kernel.org;
> davem@...emloft.net; shm@...ulusnetworks.com;
> gospo@...ulusnetworks.com
> Subject: Re: [PATCH net-next v2 2/4] swdevice: add new api to set and del
> bridge port attributes
>
>
> 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.
Are you saying that the software should reflect the same functionality the HW provides?
In other words is creating a bridge device mandatory for supporting standard VLAN-bridging (as in IEEE 802.1Q) in the HW?
VLAN-bridging including port VLAN membership, VLAN filtering, PVID, Egress un-tagging could be supported without an explicit bridge device when port devices implement bridge ndos (ndo_bridge_{set,del,get}link). What is lost is the ability to have common handling of VLAN-aware FDB in the bridge module.
Do we expect switch port devices to support L2 functionality both ways (with and without an explicit bridge device)?
Will the decision about using a bridge device or avoiding it be left to the end-user?
(This requires switch port drivers to be able to work and provide similar functionality in both setups).
I think that we need to outline the handling of L3 as it could determine or at least impact some of the answers to my above questions.
cheers,
ronen
> 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?
>
> cheers,
> jamal
>
> On 12/14/14 14:41, Roopa Prabhu wrote:
> > On 12/14/14, 7:35 AM, Jiri Pirko wrote:
>
> [..chopped off for brevity and saving electrons..]
>
> cheers,
> jamal
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in the body
> of a message to majordomo@...r.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists