[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161123160453.GB1873@nanopsycho>
Date: Wed, 23 Nov 2016 17:04:53 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
eladr@...lanox.com, yotamg@...lanox.com, nogahf@...lanox.com,
arkadis@...lanox.com, ogerlitz@...lanox.com,
roopa@...ulusnetworks.com, dsa@...ulusnetworks.com,
nikolay@...ulusnetworks.com, andy@...yhouse.net,
vivien.didelot@...oirfairelinux.com, andrew@...n.ch,
f.fainelli@...il.com, alexander.h.duyck@...el.com, kaber@...sh.net
Subject: Re: [patch net-next v2 10/11] mlxsw: spectrum_router: Request a dump
of FIB tables during init
Wed, Nov 23, 2016 at 05:00:00PM CET, hannes@...essinduktion.org wrote:
>On Wed, Nov 23, 2016, at 15:48, Jiri Pirko wrote:
>> From: Ido Schimmel <idosch@...lanox.com>
>>
>> Make sure the device has a complete view of the FIB tables by invoking
>> their dump during module init.
>>
>> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
>> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 16
>> ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
>> b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
>> index 14bed1d..36a71d2 100644
>> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
>> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
>> @@ -2027,6 +2027,21 @@ static int mlxsw_sp_router_fib_event(struct
>> notifier_block *nb,
>> return NOTIFY_DONE;
>> }
>>
>> +static void mlxsw_sp_router_fib_dump(struct mlxsw_sp *mlxsw_sp)
>> +{
>> + while (!fib_notifier_dump(&mlxsw_sp->fib_nb)) {
>> + /* Flush pending FIB notifications and then flush the
>> + * device's table before requesting another dump. Do
>> + * that with RTNL held, as FIB notification block is
>> + * already registered.
>> + */
>> + mlxsw_core_flush_owq();
>> + rtnl_lock();
>> + mlxsw_sp_router_fib_flush(mlxsw_sp);
>> + rtnl_unlock();
>> + }
>> +}
>
>I think it is fine to use this kind of synchronization.
>
>But I think that this part of the logic still belongs into the core
Core does not know how driver handles the offloaded fibs. So only driver
knows how/if he needs to do flush in case of retry.
>kernel. I still think it could happen that we will loop here
>indefinitely because of a lot of routing updates and as such would need
>to abort this loop after a number of tries.
In theory, it is possible, howevery quite unlikely.
>
>I would like that the kernel has one function to do this decision
>instead of later patching all users of this API. Do you think it is
>worth it?
For the reason I stated above, I'm not sure that could be done...
Powered by blists - more mailing lists