netdev - Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Feb 2015 23:58:50 -0500
From:	Scott Feldman <sfeldma@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	roopa <roopa@...ulusnetworks.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	vivien.didelot@...oirfairelinux.com,
	jerome.oufella@...oirfairelinux.com, andrew@...n.ch,
	Chris Healy <cphealy@...il.com>
Subject: Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations

On Thu, Feb 19, 2015 at 11:05 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> On Thu, Feb 19, 2015 at 06:41:34PM -0800, roopa wrote:
>> On 2/19/15, 6:00 PM, Florian Fainelli wrote:
>> >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)?
>>
>>
>> There is no config parameter to set HW aging vs SW aging. But if you want SW
>> aging, an example is the rocker implementation today.
>> And there is BR_LEARNING_SYNC per bridge port flag to sync HW to SW using
>> notifiers (see rocker).
>>
> SW aging is not practical. In my specific use case there can be 800+ mac
> addresses in a single mac domain, connected through an mdio bus on gpio pins.
> Besides, it doesn't really make much sense to burden SW with something that
> can easily be handled in HW, just because SW doesn't have the means to pass
> the necessary parameter - aging time - to the HW.

I have a patch which I'll post shortly as an RFC that addresses ageing
either by SW or by HW.

-scott
--
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