[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FFEDCF9956066D4D97C463CC178C7F69F21C8A@SJEXCHMB06.corp.ad.broadcom.com>
Date: Fri, 20 Feb 2015 03:53:34 +0000
From: Viswanath Bandaru <vbandaru@...adcom.com>
To: Andy Gospodarek <gospo@...ulusnetworks.com>,
Florian Fainelli <f.fainelli@...il.com>
CC: roopa <roopa@...ulusnetworks.com>,
Guenter Roeck <linux@...ck-us.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"vivien.didelot@...oirfairelinux.com"
<vivien.didelot@...oirfairelinux.com>,
"jerome.oufella@...oirfairelinux.com"
<jerome.oufella@...oirfairelinux.com>,
"andrew@...n.ch" <andrew@...n.ch>,
"cphealy@...il.com" <cphealy@...il.com>,
"sfeldma@...il.com" <sfeldma@...il.com>
Subject: RE: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging
operations
> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Andy Gospodarek
> Sent: Friday, February 20, 2015 8:51 AM
> To: Florian Fainelli
> Cc: roopa; Guenter Roeck; 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 Thu, Feb 19, 2015 at 06:00:22PM -0800, 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)?
>
> Yes, the setting of the BR_LEARNING_SYNC bit in bridge port flags should
> signal to the hardware that it should send learning notifications up to the
> kernel bridge. This is set via the IFLA_BRPORT_LEARNING attribute in a
> setlink message.
>
We had a recent discussion on this subject on roker and ageing. Siva submitted a patch for bridge not to age the 'externally learnt entries'. This broke Rocker because it depended on bridge to age out entries even if they are 'externally learnt'.
After some discussion, Scott agreed that rocker should also take care of ageing out the entries (in addition to learning them), just like a real silicon would do. He is going to submit a patch for Rocker soon.
Vissu
> --
> 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
--
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