[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54E69536.3040303@gmail.com>
Date: Thu, 19 Feb 2015 18:00:22 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: roopa <roopa@...ulusnetworks.com>,
Guenter Roeck <linux@...ck-us.net>
CC: netdev@...r.kernel.org, davem@...emloft.net,
vivien.didelot@...oirfairelinux.com,
jerome.oufella@...oirfairelinux.com, andrew@...n.ch,
cphealy@...il.com
Subject: Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations
On 19/02/15 17:46, roopa wrote:
> On 2/19/15, 5:03 PM, Guenter Roeck wrote:
>> On Thu, Feb 19, 2015 at 04:51:30PM -0800, roopa wrote:
>>>> Not sure yet what to do about setting the fdb aging time. I don't see a
>>>> mechanism to do that. No idea how important that is.
>>> rocker, the only consumer today relies on the bridge driver aging of
>>> learnt
>>> entries.
>>> You could do the same.
>>>
>> Remember that we are dealing with hardware switch chips. Those chips
>> won't time out fdb entries just because the kernel's bridge driver
>> thinks that it should.
> Oh, they dont..?. sorry, I dont know the details about your hardware.
> But, if these are entries learnt by hw, there should be a hw config to
> age them (I guess that is what you are talking about). Which the swicth
> driver can set.
> If you disable hw aging, you can sync these entries to the bridge
> driver, and make the bridge driver age them followed by a subsequent
> delete in hw.
The SF2 HW has and aging and a valid bit available, I guess my question
would be, do we have anything today in "net-next" that allows
configuring HW aging vs. SW aging (implying doing a HW to SW sync)?
--
Florian
--
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