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
| ||
|
Message-ID: <CAE4R7bA7m=_bYc6aZRiGQVG22wTOS0_+Mt2OT2P7tvh1r45AYg@mail.gmail.com> 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
Powered by blists - more mailing lists