[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54820264.8000008@cumulusnetworks.com>
Date: Fri, 05 Dec 2014 11:07:16 -0800
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Scott Feldman <sfeldma@...il.com>
CC: Jiri Pirko <jiri@...nulli.us>, Jamal Hadi Salim <jhs@...atatu.com>,
Benjamin LaHaise <bcrl@...ck.org>, Thomas Graf <tgraf@...g.ch>,
john fastabend <john.fastabend@...il.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
John Linville <linville@...driver.com>,
"nhorman@...driver.com" <nhorman@...driver.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
"vyasevic@...hat.com" <vyasevic@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
Aviad Raveh <aviadr@...lanox.com>,
Netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>, shm@...ulusnetworks.com,
Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature
flag for switch device offloads
On 12/5/14, 10:53 AM, Scott Feldman wrote:
> On Fri, Dec 5, 2014 at 6:16 AM, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>> On 12/4/14, 11:41 PM, Jiri Pirko wrote:
>>> Fri, Dec 05, 2014 at 03:26:39AM CET, roopa@...ulusnetworks.com wrote:
>>>> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>>>>
>>>> This is a generic high level feature flag for all switch asic features
>>>> today.
>>>>
>>>> switch drivers set this flag on switch ports. Logical devices like
>>>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>>
>>> Can you please elaborate on how exactly would this inheritance look
>>> like?
>>
>> My thought there was, when a port with the hw offload flag is added to the
>> bridge, the same flag gets set on the bridge. And, for any bridge attributes
>> (not port attributes), this flag on the bridge can be used to offload those
>> bridge attributes.
>> bridge attribute examples: IFLA_BR_FORWARD_DELAY, IFLA_BR_HELLO_TIME,
>> IFLA_BR_MAX_AGE.
> Ah, wait, why do those need to be pushed down to driver/HW? Letting
> the bridge (or external process like mstpd) own the ctrl-plane means
> HW isn't running STP machine or aging out FDB entries. Let Linux take
> care of that.
>
> Same goes for bonding, since that was mentioned earlier. Keep LACP
> ctrl processing in the kernel/bonding driver, and there is no need to
> push bonding settings down to port driver/hw. driver/hw just need to
> know port membership and LACP status.
scott, agreed these are stp attributes. Wont go into hardware. I picked
the wrong example.
But, I was just trying to point out that there maybe bridge attributes
that need to be passed to hw.
Like the bridge ageing timer etc. We don't use it today. But others may
in the future.
I was just trying to say that ...this maybe useful in the future. The
current in-kernel implementation
nor my patches do anything for this. We can add it in the future if need
be.
--
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