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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Feb 2015 08:57:22 +0530
From:	Siva Mannem <siva.mannem.lnx@...il.com>
To:	Scott Feldman <sfeldma@...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 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.

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.

>
> Is there a race perhaps?  Maybe that's your point.  I think I see the
> race.  SW has decided entry is expired and sends signal to remove
> entry, while in the meantime HW got a hit on entry and wants to
> refresh it.  So this would cause a service disruption if the entry was
> removed and then re-added.  But this is a boundary condition on the
> hairy edge of the ageing timeout window.  Does it matter in practice?
>
> I really want to understand your case 4, but I'm not getting
> something.  Is there another way to explain it, by example perhaps?
>
>> Such a packet loss is considered bad, and is a primary reason why
>> hardware supports ageing. Otherwise there is no reason hw needs to
>> support it. Based on experience, I can say that it is a necessity, now
>> even more with 10G and 40G links.



-- 
Regards,
Siva Mannem.
--
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