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]

Message-ID: <CAE4R7bDypUjrSAned55XRpcp+iEHNkF7H_8JJy63jt+5Hd3Pzg@mail.gmail.com>
Date:	Thu, 5 Feb 2015 17:45:32 -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 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.

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.
--
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