netdev - Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging

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, 5 Feb 2015 09:55:34 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	B Viswanath <marichika4@...il.com>
Cc:	Siva Mannem <siva.mannem.lnx@...il.com>,
	David Miller <davem@...emloft.net>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>
Subject: Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt
 FDB entries, they are removed when 'external' entity notifies the aging

On Thu, Feb 5, 2015 at 9:10 AM, Scott Feldman <sfeldma@...il.com> wrote:
> On Thu, Feb 5, 2015 at 3:05 AM, B Viswanath <marichika4@...il.com> wrote:
>> On 5 February 2015 at 15:56, Siva Mannem <siva.mannem.lnx@...il.com> wrote:
>>> On Thu, Feb 5, 2015 at 1:23 PM, David Miller <davem@...emloft.net> wrote:
>>>> From: Scott Feldman <sfeldma@...il.com>
>>>> Date: Wed, 4 Feb 2015 23:13:07 -0800
>>>>
>>>>> I'd like to see this patch reverted so we can have a more
>>>>> comprehensive discussion/solution.  With this patch applied, the only
>>>>> user (rocker) of NETDEV_SWITCH_FDB_ADD is broken.  So please undo this
>>>>> patch so rocker isn't broken and let's work on a knob to suit both
>>>>> modes: 1) let bridge manage aging, 2) let device manage aging.
>>>>
>>>> Patch reverted.

Thank you.

>>> I now see why rocker is broken. Sorry for the churn.
>>> As Scott/Roopa suggested, a new flag IFLA_BRPORT_AGING_SYNC (similar
>>> to IFLA_BRPORT_LEARNING_SYNC) can be defined and stored in
>>> net_bridge_port->flags when user configures it. Some thing like below.
>>>
>>> $ sudo bridge link set dev swp1 ageing_sync on self
>>>
>>> And bridge ageing logic does not age externally learnt entry *only* if
>>> IFLA_BRPORT_AGING_SYNC flag on fdb entry's net_bridge_port is set.
>>> This ensures that existing behavior continues to be default behavior
>>> and is of no harm to rocker.
>>>
>>> Please let me know your comments on above approach.
>>
>> I am not sure you really want to pass on this burden of deciding who
>> should age to the end user.  I think user should  not be forced to be
>> aware of all the device and driver properties.
>>
>> May be a different way would be that -
>>
>> 1. driver specifies whether it can supporting ageing by itself (the
>> chip) during registration.
>> 2. driver also allows that kernel turn off the driver/device ageing.
>> 3. when a bridge is created with all ports from same device which
>> supports ageing (and which is currently enabled), then bridge defers
>> ageing to driver. Otherwise bridge disables ageing on all
>> participating devices and takes care of ageing by itself.
>> 4. When ageing is disabled on a device, all other bridges that use any
>> ports from that device start ageing themselves.
>>
>> I guess this sounds complicated, but it can ensure that user gets the
>> best default behaviour based on the device. Any alternate suggestions
>> ?

So let me see if I can summarize the PROs and CONs of using the
default behavior of the bridge driver for ageing externally learned
FDB entries:

PROs

1) No new user knobs; just use existing bridge ageing settings for
both internal and
externally learned FDB entries.
2) Because we're using SW bridge, all offloaded switches behave the
same w.r.t. ageing.
3) Because we're using SW bridge, bug fixes and enhancements apply to
all offloaded switches.
4) Switch device model w.r.t. FDB ageing is simple to understand.
5) User's view of the ageing process is the same for internal and
external learned FDB entries.
The last-used stats make sense.
6) Leveraging what's already there...bridge ageing function is
tried-and-true....let's reuse it if we can.

CONs

1) Scale-ability.  The bridge driver can't keep up with ageing many
(10^5, for example) entries.
2) Scale-ability.  Keeping the entries periodically refreshed requires
a refresh sync from
the device to the bridge driver, and the bridge driver/kernel can't keep up.
3) With the bridge driver, the ageing settings are per-bridge, not per-port.

Did I miss any points?

I think it boils down to use-ability vs. scale-ability.  My personal
opinion is I'm skeptical there are real scale-ability issues because
the on-board switch CPU should easily be able to handle the ageing
tasks.  After all, the CPU will for the most part be idle, only
worrying about the occasional ctrl pkt (STP, LLDP, OSPF, etc).  I'm
most interested in keeping the user's experience simple, so if we can
extend the existing bridge ageing model to offloaded devices without
changing the users' experience compared to the non-offloaded case.

So let's draw out the CONs for using the bridge driver's ageing function as-is.

-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