netdev - Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn

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]

Message-ID: <CAN+pFwKfss3m7+B1ZkauKwvHFEdsO_sUMfYixDc8+vevRhYHbA@mail.gmail.com>
Date:	Sat, 10 Jan 2015 08:01:25 +0530
From:	B Viswanath <marichika4@...il.com>
To:	Scott Feldman <sfeldma@...il.com>
Cc:	"Arad, Ronen" <ronen.arad@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Siva Mannem <siva.mannem.lnx@...il.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
 fdb entries learnt via br_fdb_external_learn_add()

Hi Scot,

I think we can see the problem in case 1 itself.

Driver's can't periodically update kernel about refreshing the fdb
entry in reality. Some of the switches I worked on a while ago have
16K entries in a MAC table, Surely it has grown folds now. For the
driver to be able to refresh kernel periodically would be a nightmare,
performance wise, to poll this many entries from hardware, see which
of them is updated.

The driver is updating the kernel about learnt entry. I think it makes
sence to have driver update the kernel about ageing too.

Thanks
Viswanath

On 10 January 2015 at 00:17, Scott Feldman <sfeldma@...il.com> wrote:
> On Fri, Jan 9, 2015 at 8:15 AM, Arad, Ronen <ronen.arad@...el.com> wrote:
>>
>>
>>>-----Original Message-----
>>>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On
>>>Behalf Of Scott Feldman
>>>Sent: Friday, January 09, 2015 3:47 AM
>>>To: Jiri Pirko
>>>Cc: Siva Mannem; Netdev
>>>Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
>>>fdb entries learnt via br_fdb_external_learn_add()
>>>
>>>On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>>>> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@...il.com wrote:
>>>>>Hi,
>>>>>
>>>>>I am trying to understand the ongoing switch device offload effort and
>>>>>am following the discussions. I have a question regarding
>>>>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>>>>enabled on a port that is attached to a bridge that has vlan filtering
>>>>>enabled.
>>>>>
>>>>>If I understand correctly, when  IFLA_BRPORT_LEARNING_SYNC is set on a
>>>>>bridge port, fdb entries that are learnt externally(may be learnt by
>>>>>hardware and driver is notified) are synced to bridges fdb using
>>>>>br_fdb_external_learn_add(). The fdb
>>>>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>>>>this method are also deleted by the aging logic after the aging time
>>>>>even though L2 data forwadring  happens in hardware.
>>>
>>>This is correct...
>>>
>>>>> Is there a way
>>>>>where aging can be disabled for these entries? and let the entries be
>>>>>removed only via br_fdb_external_learn_delete()? or am I missing
>>>>>something?
>>>>
>>>> Currently extenaly learned fdb entries are indeed removed during aging
>>>> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
>>>> and not remove that fdbs. What do you think Scott?
>>>
>>>Something like that would work, if we added another brport flag to
>>>control that.  With the current arrangement, using bridge for aging
>>>out entries, we want br_fdb_cleanup removing the external_learned
>>>fdbs, but if there was another brport flag we could fine tune that.
>>>Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that.  I'm
>>>not sure how aging settings for the bridge are pushed down to offload
>>>hw, or if there is a different set for hw.
>>>
>>>But, isn't it nice to let Linux bridge control aging?  That way,
>>>bridge -s fdb dump shows nice statistics on fdb entries.  Hardware
>>>isn't involved in the aging processes (other than being told to remove
>>>an entry).  Simple hardware equals simple driver.  Linux remains
>>>control point.
>>>
>> It is indeed simpler. However, if the overhead of reading hit bits from the HW
>> and updating freshness of entries using br_fdb_external_learn_add() is too
>> expensive, it would force such platforms to disable learning sync altogether.
>> Therefore, I believe aging offload flag (could be sufficient at bridge level)
>> and external aging interval (possibly longer than the software aging interval)
>> will encourage drivers to use leaning sync.
>>>-scott
>
> I'm not sure I follow that last part.
>
> Can we list out the use-cases to see what's missing?
>
> Case 1: bridge ages out learned_sync'ed entries
>
> bridge port learning: off
> offload port learning: on
> offload port learning_sync: on
>
> Driver calls br_fdb_external_learn_add() periodically to refresh
> bridge fdb entry
> to keep it from going stale.
> Bridge removes aged out fdb entries (and indirectly tells offload
> device to do the same).
>
> Case 2: offload device/bridge age out entries independently
>
> bridge port learning: on
> offload port learning: on
> offload port learning_sync: off
>
> Bridge ages out its stale learned entries, independent of offload device.
> Offload device ages out its stale learned entries, independent of bridge.
>
> Case 3: ?
>
> Please help me finish the use-case list so we can see what's missing.
>
> -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
--
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