From: roopa <roopa@cumulusnetworks.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Viswanath Bandaru <vbandaru@broadcom.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"sfeldma@gmail.com" <sfeldma@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"gospo@cumulusnetworks.com" <gospo@cumulusnetworks.com>,
"siva.mannem.lnx@gmail.com" <siva.mannem.lnx@gmail.com>
Subject: Re: [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing in SW or HW
Date: Sat, 21 Feb 2015 10:31:11 -0800 [thread overview]
Message-ID: <54E8CEEF.2010200@cumulusnetworks.com> (raw)
In-Reply-To: <20150221155002.GA2092@nanopsycho.orion>
On 2/21/15, 7:50 AM, Jiri Pirko wrote:
> Sat, Feb 21, 2015 at 12:29:38PM CET, vbandaru@broadcom.com wrote:
>>> -----Original Message-----
>>>> I agree, in fact, most of the HW I have access to only has a global age
>>>> timer configuration knob. Is this configurable on a per-port basis for
>>>> higher end switches, or even maybe per-FDB entry?
>>> I'm currently not aware of any hw which does not have global age timer.
>>> But I believe that they will appear. The model that we have now, to
>>> propagate aging setting of bridge down is more general and should be ok.
>>>
>>> Drivers should probably take care of multi bridge setup with different aging
>>> setup. Maybe to find minimal time and print a warning?
>>>
>> Setting up the minimal time in such a scenario is good.
>>
>> Should we also consider the possibility bridges containing ports from different devices (and therefore different drivers) ? If that is a possibility, I think the bridge module should take responsibility of finding out the minimal time to pushing to all involved drivers.
> It is certainly possible to bridge ports from multiple switch devices.
> But that should not be a problem, because 1 bridge has 1 aging setup
> which will be passed to all port drivers.
>
> I believe that the only case which need to be resolved is multiple
> bridges over single switch device. And I believe that it should be
> handled in drivers because only drivers know what the hw is capable of
> (if it supports aging setup per port/bridge/global).
>
>>
I agree.
next prev parent reply other threads:[~2015-02-21 18:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 7:09 [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing in SW or HW sfeldma
2015-02-20 7:09 ` [PATCH net-next RFC 1/5] neighbour: add external aged flag sfeldma
2015-02-20 7:09 ` [PATCH net-next RFC 2/5] switchdev: add ntf_flags to FDB notifier sfeldma
2015-02-20 7:09 ` [PATCH net-next RFC 3/5] bridge: call external learn add if adding FDB entry with NTF_EXT_LEARNED set sfeldma
2015-02-20 7:09 ` [PATCH net-next RFC 4/5] bridge: let HW control FDB ageing by setting NTF_EXT_AGED sfeldma
2015-02-20 17:31 ` David Miller
2015-02-20 7:09 ` [PATCH net-next RFC 5/5] rocker: explicitly set SW ageing for rocker sfeldma
2015-02-20 9:46 ` Jiri Pirko
2015-02-20 14:56 ` Scott Feldman
2015-02-20 17:29 ` [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing in SW or HW roopa
2015-02-20 19:13 ` Florian Fainelli
2015-02-20 19:45 ` Guenter Roeck
2015-02-21 0:20 ` Viswanath Bandaru
2015-02-21 0:39 ` Guenter Roeck
2015-02-21 18:29 ` roopa
[not found] ` <CAE4R7bAPS1GZKaC4M6x9cqfTOkVju1+Po4KzanfSniEFX9oi1w@mail.gmail.com>
2015-02-25 14:31 ` Andrew Lunn
2015-02-25 16:43 ` Guenter Roeck
2015-02-25 17:31 ` B Viswanath
2015-02-25 18:39 ` Guenter Roeck
2015-02-25 18:51 ` B Viswanath
2015-02-25 19:15 ` Guenter Roeck
2015-02-25 19:33 ` B Viswanath
2015-02-25 20:03 ` Guenter Roeck
2015-02-25 17:29 ` David Miller
2015-02-21 11:03 ` Jiri Pirko
2015-02-21 11:29 ` Viswanath Bandaru
2015-02-21 15:50 ` Jiri Pirko
2015-02-21 17:20 ` Viswanath Bandaru
2015-02-21 18:31 ` roopa [this message]
2015-02-21 1:23 ` Siva Mannem
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E8CEEF.2010200@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=gospo@cumulusnetworks.com \
--cc=jiri@resnulli.us \
--cc=linux@roeck-us.net \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=siva.mannem.lnx@gmail.com \
--cc=vbandaru@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.