[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160922094356.GA1830@nanopsycho.orion>
Date: Thu, 22 Sep 2016 11:43:56 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
eladr@...lanox.com, yotamg@...lanox.com, nogahf@...lanox.com,
ogerlitz@...lanox.com, roopa@...ulusnetworks.com,
nikolay@...ulusnetworks.com, linville@...driver.com,
andy@...yhouse.net, f.fainelli@...il.com, dsa@...ulusnetworks.com,
jhs@...atatu.com, vivien.didelot@...oirfairelinux.com,
andrew@...n.ch, ivecera@...hat.com, kaber@...sh.net,
john@...ozen.org
Subject: Re: [patch net-next 1/6] fib: introduce FIB notification
infrastructure
Thu, Sep 22, 2016 at 07:13:50AM CEST, idosch@...sch.org wrote:
>On Wed, Sep 21, 2016 at 01:53:09PM +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> This allows to pass information about added/deleted FIB entries/rules to
>> whoever is interested. This is done in a very similar way as devinet
>> notifies address additions/removals.
>>
>> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>
>[...]
>
>> #include <linux/slab.h>
>> #include <linux/export.h>
>> #include <linux/vmalloc.h>
>> +#include <linux/notifier.h>
>> #include <net/net_namespace.h>
>> #include <net/ip.h>
>> #include <net/protocol.h>
>> @@ -84,6 +85,44 @@
>> #include <trace/events/fib.h>
>> #include "fib_lookup.h"
>>
>> +static BLOCKING_NOTIFIER_HEAD(fib_chain);
>> +
>> +int register_fib_notifier(struct notifier_block *nb)
>> +{
>> + return blocking_notifier_chain_register(&fib_chain, nb);
>> +}
>> +EXPORT_SYMBOL(register_fib_notifier);
>
>If we remove and insert the switch driver, then the existing FIB entries
>should be replayed when we register our notification block. Otherwise,
>all of these entries will be missing from the switch's tables. I believe
>it should be handled like register_netdevice_notifier(), where
>"registration and up events are replayed".
Agreed. This patchset does not change this behaviour as the original
switchdev solution has the same "ordering" issue. We should take care of
it as a part of yours ordering patchsets.
Powered by blists - more mailing lists