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 20:59:30 -0800
From:	roopa <roopa@...ulusnetworks.com>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Florian Fainelli <f.fainelli@...il.com>, 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 2/19/15, 8:05 PM, Guenter Roeck 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 think the question here was how to communicate aging time to the switch chip,
> not SW aging vs. HW aging.

I think florians last email was just a question about HW aging vs SW 
aging and so we were discussing that.
But sure if SW aging is not an option for these chip, Lets only discuss 
HW aging.
And for HW aging, you could leave it at the default hw value or have the 
switch driver set a default aging value.
and if there is a need to make it configurable per bridge we can add an 
API to pass it via the bridge
ageing time to the switch driver.

>
>> There is no netlink based age time sets AFAIK. But there is age time sets
>> from sysctl. And there is no offload support for this today.
>> The offload support has been discussed previously and there was no need to
>> add it immediately.
>>
> Ok with me; just hope it doesn't cause any trouble.
>
> Guenter

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