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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 Feb 2015 21:53:14 -0800
From:	Scott Feldman <sfeldma@...il.com>
To:	Siva Mannem <siva.mannem.lnx@...il.com>
Cc:	B Viswanath <marichika4@...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 7:27 PM, Siva Mannem <siva.mannem.lnx@...il.com> wrote:
> On Fri, Feb 6, 2015 at 7:15 AM, Scott Feldman <sfeldma@...il.com> wrote:
>> On Thu, Feb 5, 2015 at 10:31 AM, B Viswanath <marichika4@...il.com> wrote:
>>> On 5 February 2015 at 23:25, Scott Feldman <sfeldma@...il.com> wrote:
>>> <snip>
>>>>
>>>> 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?
>>>
>>> There is one more
>>>
>>> 4. On links with wirespeed traffic, software ageing FDB entries
>>> independently without having the knowledge of the traffic means that
>>> CPU will ageout entries it should not. I don't know if this breaks
>>> some RFC, but it can certainly cause big packet loss.
>>
>> SW would only age out expired entries.  An entry not refreshed by HW
>> will expire.  But HW will refresh (to SW) active entries based on
>> traffic seen.  So I'm not seeing how SW will age out entries
>> prematurely.  I'm missing something.
>
> Hardware does not refresh(to SW) active entries based on the traffic
> seen, at least on the switches that I worked on. Even if it were to
> refresh, if the traffic is flowing at line rate(say x packets per
> sec), the refresh rate to SW is equal to x, which is very huge for cpu
> to handle.

I meant refresh as in re-sending learn notification for entry on a
periodic basis, say once a second.  Not refreshing by presenting pkt
to SW...that wouldn't scale at all, as you say.

> There are only two notifications to SW.
>
> 1)learn notification(when packet arrives that has smac which is not in
> hardware's FDB)
> 2)When the hardware ages the entry, it sends a age notification.

I think I'm coming around to your thinking of letting HW manage ageing
on HW-learned FDB entries.  I was hoping to keep ageing in SW for the
PROs I mentioned earlier, but it's not aligning very well with real
HW.  If we modify rocker to work like real HW (that was the point of
rocker in the first place), then we can re-introduce your patch to let
bridge ignore ageing on entries marked with added_by_external_learn.
Let me work on the rocker mods and followup.

-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