Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Jiri Pirko]

Mon, Sep 19, 2016 at 04:53:07PM CEST, ro...@cumulusnetworks.com wrote:
>On 9/18/16, 11:06 PM, Jiri Pirko wrote:
>> Mon, Sep 19, 2016 at 01:23:47AM CEST, ro...@cumulusnetworks.com wrote:
>>> On 9/6/16, 5:01 AM, Jiri Pirko wrote:
 From: Jiri Pirko 

 This allows to pass information about added/deleted fib entries to
 whoever is interested. This is done in a very similar way as devinet
 notifies address additions/removals.

 Signed-off-by: Jiri Pirko 
 ---
>
>[snip]
  
  #define KEYLENGTH (8*sizeof(t_key))
 @@ -1190,6 +1221,10 @@ int fib_table_insert(struct fib_table *tb, struct 
 fib_config *cfg)
fib_release_info(fi_drop);
if (state & FA_S_ACCESSED)
rt_cache_flush(cfg->fc_nlinfo.nl_net);
 +
 +  call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi,
 + new_fa->fa_tos, cfg->fc_type,
 + tb->tb_id, cfg->fc_nlflags);
rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
tb->tb_id, >fc_nlinfo, NLM_F_REPLACE);
  
 @@ -1241,6 +1276,8 @@ int fib_table_insert(struct fib_table *tb, struct 
 fib_config *cfg)
tb->tb_num_default++;
  
rt_cache_flush(cfg->fc_nlinfo.nl_net);
 +  call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi, tos,
 + cfg->fc_type, tb->tb_id, cfg->fc_nlflags);
>>>
>>> It appears that this is in addition to the existing switchdev_fib_ipv4_add 
>>> call right above this.
>>> Is the intent to do both ?. i don't see a need to do both.
>> I already have patchset improved that it removes the switchdev fib code.
>> Have to do some more testing, will send it soon.
>
>ok, ack.
>>
>>
>>> and switchdev_fib_ipv4_add  offloads before the route is added to the 
>>> kernel.
>>> But the notifier seems to fire after the route is added to the kernel.
>> Yeah, I wanted to align it with rtmsg_fib calls. Also I think it makes
>> sense to have slowpath ready before offload.
>>
>
>ok, ..but..that changes existing behavior though. and if the hw route add 
>fails...,
>you may have inconsistent state between hw and sw.

If the hw route add fails, driver will be responsible for abort,
cleanining up hw and set appropriate traps to get packets to cpu
processing.

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Roopa Prabhu]

On 9/18/16, 11:06 PM, Jiri Pirko wrote:
> Mon, Sep 19, 2016 at 01:23:47AM CEST, ro...@cumulusnetworks.com wrote:
>> On 9/6/16, 5:01 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko 
>>>
>>> This allows to pass information about added/deleted fib entries to
>>> whoever is interested. This is done in a very similar way as devinet
>>> notifies address additions/removals.
>>>
>>> Signed-off-by: Jiri Pirko 
>>> ---

[snip]
>>>  
>>>  #define KEYLENGTH  (8*sizeof(t_key))
>>> @@ -1190,6 +1221,10 @@ int fib_table_insert(struct fib_table *tb, struct 
>>> fib_config *cfg)
>>> fib_release_info(fi_drop);
>>> if (state & FA_S_ACCESSED)
>>> rt_cache_flush(cfg->fc_nlinfo.nl_net);
>>> +
>>> +   call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi,
>>> +  new_fa->fa_tos, cfg->fc_type,
>>> +  tb->tb_id, cfg->fc_nlflags);
>>> rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
>>> tb->tb_id, >fc_nlinfo, NLM_F_REPLACE);
>>>  
>>> @@ -1241,6 +1276,8 @@ int fib_table_insert(struct fib_table *tb, struct 
>>> fib_config *cfg)
>>> tb->tb_num_default++;
>>>  
>>> rt_cache_flush(cfg->fc_nlinfo.nl_net);
>>> +   call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi, tos,
>>> +  cfg->fc_type, tb->tb_id, cfg->fc_nlflags);
>>
>> It appears that this is in addition to the existing switchdev_fib_ipv4_add 
>> call right above this.
>> Is the intent to do both ?. i don't see a need to do both.
> I already have patchset improved that it removes the switchdev fib code.
> Have to do some more testing, will send it soon.

ok, ack.
>
>
>> and switchdev_fib_ipv4_add  offloads before the route is added to the kernel.
>> But the notifier seems to fire after the route is added to the kernel.
> Yeah, I wanted to align it with rtmsg_fib calls. Also I think it makes
> sense to have slowpath ready before offload.
>

ok, ..but..that changes existing behavior though. and if the hw route add 
fails...,
you may have inconsistent state between hw and sw.

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Jiri Pirko]

Mon, Sep 19, 2016 at 01:23:47AM CEST, ro...@cumulusnetworks.com wrote:
>On 9/6/16, 5:01 AM, Jiri Pirko wrote:
>> From: Jiri Pirko 
>>
>> This allows to pass information about added/deleted fib entries to
>> whoever is interested. This is done in a very similar way as devinet
>> notifies address additions/removals.
>>
>> Signed-off-by: Jiri Pirko 
>> ---
>>  include/net/ip_fib.h | 19 +++
>>  net/ipv4/fib_trie.c  | 43 +++
>>  2 files changed, 62 insertions(+)
>>
>> diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
>> index 4079fc1..9ad7ba9 100644
>> --- a/include/net/ip_fib.h
>> +++ b/include/net/ip_fib.h
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  struct fib_config {
>>  u8  fc_dst_len;
>> @@ -184,6 +185,24 @@ __be32 fib_info_update_nh_saddr(struct net *net, struct 
>> fib_nh *nh);
>>  #define FIB_RES_PREFSRC(net, res)   ((res).fi->fib_prefsrc ? : \
>>   FIB_RES_SADDR(net, res))
>>  
>> +struct fib_notifier_info {
>> +u32 dst;
>> +int dst_len;
>> +struct fib_info *fi;
>> +u8 tos;
>> +u8 type;
>> +u32 tb_id;
>> +u32 nlflags;
>> +};
>> +
>> +enum fib_event_type {
>> +FIB_EVENT_TYPE_ADD,
>> +FIB_EVENT_TYPE_DEL,
>> +};
>> +
>> +int register_fib_notifier(struct notifier_block *nb);
>> +int unregister_fib_notifier(struct notifier_block *nb);
>> +
>>  struct fib_table {
>>  struct hlist_node   tb_hlist;
>>  u32 tb_id;
>> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
>> index e2ffc2a..19ec471 100644
>> --- a/net/ipv4/fib_trie.c
>> +++ b/net/ipv4/fib_trie.c
>> @@ -73,6 +73,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -84,6 +85,36 @@
>>  #include 
>>  #include "fib_lookup.h"
>>  
>> +static BLOCKING_NOTIFIER_HEAD(fib_chain);
>> +
>> +int register_fib_notifier(struct notifier_block *nb)
>> +{
>> +return blocking_notifier_chain_register(_chain, nb);
>> +}
>> +EXPORT_SYMBOL(register_fib_notifier);
>> +
>> +int unregister_fib_notifier(struct notifier_block *nb)
>> +{
>> +return blocking_notifier_chain_unregister(_chain, nb);
>> +}
>> +EXPORT_SYMBOL(unregister_fib_notifier);
>> +
>> +static int call_fib_notifiers(enum fib_event_type event_type, u32 dst,
>> +  int dst_len, struct fib_info *fi,
>> +  u8 tos, u8 type, u32 tb_id, u32 nlflags)
>> +{
>> +struct fib_notifier_info info = {
>> +.dst = dst,
>> +.dst_len = dst_len,
>> +.fi = fi,
>> +.tos = tos,
>> +.type = type,
>> +.tb_id = tb_id,
>> +.nlflags = nlflags,
>> +};
>> +return blocking_notifier_call_chain(_chain, event_type, );
>> +}
>> +
>>  #define MAX_STAT_DEPTH 32
>>  
>>  #define KEYLENGTH   (8*sizeof(t_key))
>> @@ -1190,6 +1221,10 @@ int fib_table_insert(struct fib_table *tb, struct 
>> fib_config *cfg)
>>  fib_release_info(fi_drop);
>>  if (state & FA_S_ACCESSED)
>>  rt_cache_flush(cfg->fc_nlinfo.nl_net);
>> +
>> +call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi,
>> +   new_fa->fa_tos, cfg->fc_type,
>> +   tb->tb_id, cfg->fc_nlflags);
>>  rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
>>  tb->tb_id, >fc_nlinfo, NLM_F_REPLACE);
>>  
>> @@ -1241,6 +1276,8 @@ int fib_table_insert(struct fib_table *tb, struct 
>> fib_config *cfg)
>>  tb->tb_num_default++;
>>  
>>  rt_cache_flush(cfg->fc_nlinfo.nl_net);
>> +call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi, tos,
>> +   cfg->fc_type, tb->tb_id, cfg->fc_nlflags);
>
>
>It appears that this is in addition to the existing switchdev_fib_ipv4_add 
>call right above this.
>Is the intent to do both ?. i don't see a need to do both.

I already have patchset improved that it removes the switchdev fib code.
Have to do some more testing, will send it soon.


>
>and switchdev_fib_ipv4_add  offloads before the route is added to the kernel.
>But the notifier seems to fire after the route is added to the kernel.

Yeah, I wanted to align it with rtmsg_fib calls. Also I think it makes
sense to have slowpath ready before offload.


>
>>  rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, new_fa->tb_id,
>>>fc_nlinfo, nlflags);
>>  succeeded:
>> @@ -1542,6 +1579,8 @@ int fib_table_delete(struct fib_table *tb, struct 
>> fib_config *cfg)
>>  switchdev_fib_ipv4_del(key, plen, fa_to_delete->fa_info, tos,
>> cfg->fc_type, tb->tb_id);
>>  
>> +call_fib_notifiers(FIB_EVENT_TYPE_DEL, key, plen, fa_to_delete->fa_info,
>> +   tos, 

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Roopa Prabhu]

On 9/6/16, 5:01 AM, Jiri Pirko wrote:
> From: Jiri Pirko 
>
> This allows to pass information about added/deleted fib entries to
> whoever is interested. This is done in a very similar way as devinet
> notifies address additions/removals.
>
> Signed-off-by: Jiri Pirko 
> ---
>  include/net/ip_fib.h | 19 +++
>  net/ipv4/fib_trie.c  | 43 +++
>  2 files changed, 62 insertions(+)
>
> diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
> index 4079fc1..9ad7ba9 100644
> --- a/include/net/ip_fib.h
> +++ b/include/net/ip_fib.h
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct fib_config {
>   u8  fc_dst_len;
> @@ -184,6 +185,24 @@ __be32 fib_info_update_nh_saddr(struct net *net, struct 
> fib_nh *nh);
>  #define FIB_RES_PREFSRC(net, res)((res).fi->fib_prefsrc ? : \
>FIB_RES_SADDR(net, res))
>  
> +struct fib_notifier_info {
> + u32 dst;
> + int dst_len;
> + struct fib_info *fi;
> + u8 tos;
> + u8 type;
> + u32 tb_id;
> + u32 nlflags;
> +};
> +
> +enum fib_event_type {
> + FIB_EVENT_TYPE_ADD,
> + FIB_EVENT_TYPE_DEL,
> +};
> +
> +int register_fib_notifier(struct notifier_block *nb);
> +int unregister_fib_notifier(struct notifier_block *nb);
> +
>  struct fib_table {
>   struct hlist_node   tb_hlist;
>   u32 tb_id;
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index e2ffc2a..19ec471 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -73,6 +73,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -84,6 +85,36 @@
>  #include 
>  #include "fib_lookup.h"
>  
> +static BLOCKING_NOTIFIER_HEAD(fib_chain);
> +
> +int register_fib_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(_chain, nb);
> +}
> +EXPORT_SYMBOL(register_fib_notifier);
> +
> +int unregister_fib_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(_chain, nb);
> +}
> +EXPORT_SYMBOL(unregister_fib_notifier);
> +
> +static int call_fib_notifiers(enum fib_event_type event_type, u32 dst,
> +   int dst_len, struct fib_info *fi,
> +   u8 tos, u8 type, u32 tb_id, u32 nlflags)
> +{
> + struct fib_notifier_info info = {
> + .dst = dst,
> + .dst_len = dst_len,
> + .fi = fi,
> + .tos = tos,
> + .type = type,
> + .tb_id = tb_id,
> + .nlflags = nlflags,
> + };
> + return blocking_notifier_call_chain(_chain, event_type, );
> +}
> +
>  #define MAX_STAT_DEPTH 32
>  
>  #define KEYLENGTH(8*sizeof(t_key))
> @@ -1190,6 +1221,10 @@ int fib_table_insert(struct fib_table *tb, struct 
> fib_config *cfg)
>   fib_release_info(fi_drop);
>   if (state & FA_S_ACCESSED)
>   rt_cache_flush(cfg->fc_nlinfo.nl_net);
> +
> + call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi,
> +new_fa->fa_tos, cfg->fc_type,
> +tb->tb_id, cfg->fc_nlflags);
>   rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen,
>   tb->tb_id, >fc_nlinfo, NLM_F_REPLACE);
>  
> @@ -1241,6 +1276,8 @@ int fib_table_insert(struct fib_table *tb, struct 
> fib_config *cfg)
>   tb->tb_num_default++;
>  
>   rt_cache_flush(cfg->fc_nlinfo.nl_net);
> + call_fib_notifiers(FIB_EVENT_TYPE_ADD, key, plen, fi, tos,
> +cfg->fc_type, tb->tb_id, cfg->fc_nlflags);


It appears that this is in addition to the existing switchdev_fib_ipv4_add call 
right above this.
Is the intent to do both ?. i don't see a need to do both.

and switchdev_fib_ipv4_add  offloads before the route is added to the kernel.
But the notifier seems to fire after the route is added to the kernel.

>   rtmsg_fib(RTM_NEWROUTE, htonl(key), new_fa, plen, new_fa->tb_id,
> >fc_nlinfo, nlflags);
>  succeeded:
> @@ -1542,6 +1579,8 @@ int fib_table_delete(struct fib_table *tb, struct 
> fib_config *cfg)
>   switchdev_fib_ipv4_del(key, plen, fa_to_delete->fa_info, tos,
>  cfg->fc_type, tb->tb_id);
>  
> + call_fib_notifiers(FIB_EVENT_TYPE_DEL, key, plen, fa_to_delete->fa_info,
> +tos, cfg->fc_type, tb->tb_id, 0);
>   rtmsg_fib(RTM_DELROUTE, htonl(key), fa_to_delete, plen, tb->tb_id,
> >fc_nlinfo, 0);
>  
> @@ -1857,6 +1896,10 @@ int fib_table_flush(struct fib_table *tb)
>   switchdev_fib_ipv4_del(n->key, KEYLENGTH - fa->fa_slen,
>  fi, fa->fa_tos, fa->fa_type,
>

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Jiri Pirko]

Tue, Sep 06, 2016 at 05:13:36PM CEST, d...@cumulusnetworks.com wrote:
>On 9/6/16 6:01 AM, Jiri Pirko wrote:
>> From: Jiri Pirko 
>> 
>> This allows to pass information about added/deleted fib entries to
>> whoever is interested. This is done in a very similar way as devinet
>> notifies address additions/removals.
>> 
>> Signed-off-by: Jiri Pirko 
>> ---
>>  include/net/ip_fib.h | 19 +++
>>  net/ipv4/fib_trie.c  | 43 +++
>>  2 files changed, 62 insertions(+)
>
>Do you intend for this set of notifiers to work with policy routing (FIB 
>rules) as well?


Yes, plan is to put the notifier calls before notify_rule_change. Would
probably make sense to have this in one notifier, only several event
types. Not sure.

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Hannes Frederic Sowa]

On Tue, Sep 6, 2016, at 17:49, Jiri Pirko wrote:
> Tue, Sep 06, 2016 at 05:11:11PM CEST, d...@cumulusnetworks.com wrote:
> >On 9/6/16 8:44 AM, Jiri Pirko wrote:
> >> Tue, Sep 06, 2016 at 04:32:12PM CEST, d...@cumulusnetworks.com wrote:
> >>> On 9/6/16 6:01 AM, Jiri Pirko wrote:
>  From: Jiri Pirko 
> 
>  This allows to pass information about added/deleted fib entries to
>  whoever is interested. This is done in a very similar way as devinet
>  notifies address additions/removals.
> 
>  Signed-off-by: Jiri Pirko 
>  ---
>   include/net/ip_fib.h | 19 +++
>   net/ipv4/fib_trie.c  | 43 +++
>   2 files changed, 62 insertions(+)
> 
> >>>
> >>> The notifier infrastructure should be generalized for use with IPv4 and 
> >>> IPv6. While the data will be family based, the infra can be generic.
> >>>
> >> 
> >> Yeah, that I thought about as well. Thing is, ipv6 notifier has to be
> >> atomic. That is the reason we have:
> >> inetaddr_chain and register_inetaddr_notifier (blocking notifier)
> >> inet6addr_chain and register_inet6addr_notifier (atomic notifier)
> >> 
> >
> >Why is IPv6 atomic? Looking at code paths for adding addresses seems like 
> >all of the locks are dropped before the notifier is called and adding and 
> >deleting ipv6 addresses does not show a hit with this WARN_ON:
> 
> 
> Maybe historic reasons. Would be good to unite the notifiers then. I'll
> look at it.

We add IPs and routes from bottom half layer because of neighbour
discovery router advertisements. They need to run in atomic context
without sleeping.

Bye,
Hannes

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Jiri Pirko]

Tue, Sep 06, 2016 at 05:11:11PM CEST, d...@cumulusnetworks.com wrote:
>On 9/6/16 8:44 AM, Jiri Pirko wrote:
>> Tue, Sep 06, 2016 at 04:32:12PM CEST, d...@cumulusnetworks.com wrote:
>>> On 9/6/16 6:01 AM, Jiri Pirko wrote:
 From: Jiri Pirko 

 This allows to pass information about added/deleted fib entries to
 whoever is interested. This is done in a very similar way as devinet
 notifies address additions/removals.

 Signed-off-by: Jiri Pirko 
 ---
  include/net/ip_fib.h | 19 +++
  net/ipv4/fib_trie.c  | 43 +++
  2 files changed, 62 insertions(+)

>>>
>>> The notifier infrastructure should be generalized for use with IPv4 and 
>>> IPv6. While the data will be family based, the infra can be generic.
>>>
>> 
>> Yeah, that I thought about as well. Thing is, ipv6 notifier has to be
>> atomic. That is the reason we have:
>> inetaddr_chain and register_inetaddr_notifier (blocking notifier)
>> inet6addr_chain and register_inet6addr_notifier (atomic notifier)
>> 
>
>Why is IPv6 atomic? Looking at code paths for adding addresses seems like all 
>of the locks are dropped before the notifier is called and adding and deleting 
>ipv6 addresses does not show a hit with this WARN_ON:


Maybe historic reasons. Would be good to unite the notifiers then. I'll
look at it.


>
>
>diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c
>index bfa941fc1165..4f9f964d95e5 100644
>--- a/net/ipv6/addrconf_core.c
>+++ b/net/ipv6/addrconf_core.c
>@@ -103,6 +103,7 @@ EXPORT_SYMBOL(unregister_inet6addr_notifier);
>
> int inet6addr_notifier_call_chain(unsigned long val, void *v)
> {
>+WARN_ON(in_atomic());
>return atomic_notifier_call_chain(_chain, val, v);
> }
> EXPORT_SYMBOL(inet6addr_notifier_call_chain);

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[David Ahern]

On 9/6/16 6:01 AM, Jiri Pirko wrote:
> From: Jiri Pirko 
> 
> This allows to pass information about added/deleted fib entries to
> whoever is interested. This is done in a very similar way as devinet
> notifies address additions/removals.
> 
> Signed-off-by: Jiri Pirko 
> ---
>  include/net/ip_fib.h | 19 +++
>  net/ipv4/fib_trie.c  | 43 +++
>  2 files changed, 62 insertions(+)

Do you intend for this set of notifiers to work with policy routing (FIB rules) 
as well?

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[David Ahern]

On 9/6/16 8:44 AM, Jiri Pirko wrote:
> Tue, Sep 06, 2016 at 04:32:12PM CEST, d...@cumulusnetworks.com wrote:
>> On 9/6/16 6:01 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko 
>>>
>>> This allows to pass information about added/deleted fib entries to
>>> whoever is interested. This is done in a very similar way as devinet
>>> notifies address additions/removals.
>>>
>>> Signed-off-by: Jiri Pirko 
>>> ---
>>>  include/net/ip_fib.h | 19 +++
>>>  net/ipv4/fib_trie.c  | 43 +++
>>>  2 files changed, 62 insertions(+)
>>>
>>
>> The notifier infrastructure should be generalized for use with IPv4 and 
>> IPv6. While the data will be family based, the infra can be generic.
>>
> 
> Yeah, that I thought about as well. Thing is, ipv6 notifier has to be
> atomic. That is the reason we have:
> inetaddr_chain and register_inetaddr_notifier (blocking notifier)
> inet6addr_chain and register_inet6addr_notifier (atomic notifier)
> 

Why is IPv6 atomic? Looking at code paths for adding addresses seems like all 
of the locks are dropped before the notifier is called and adding and deleting 
ipv6 addresses does not show a hit with this WARN_ON:


diff --git a/net/ipv6/addrconf_core.c b/net/ipv6/addrconf_core.c
index bfa941fc1165..4f9f964d95e5 100644
--- a/net/ipv6/addrconf_core.c
+++ b/net/ipv6/addrconf_core.c
@@ -103,6 +103,7 @@ EXPORT_SYMBOL(unregister_inet6addr_notifier);

 int inet6addr_notifier_call_chain(unsigned long val, void *v)
 {
+WARN_ON(in_atomic());
return atomic_notifier_call_chain(_chain, val, v);
 }
 EXPORT_SYMBOL(inet6addr_notifier_call_chain);

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[Jiri Pirko]

Tue, Sep 06, 2016 at 04:32:12PM CEST, d...@cumulusnetworks.com wrote:
>On 9/6/16 6:01 AM, Jiri Pirko wrote:
>> From: Jiri Pirko 
>> 
>> This allows to pass information about added/deleted fib entries to
>> whoever is interested. This is done in a very similar way as devinet
>> notifies address additions/removals.
>> 
>> Signed-off-by: Jiri Pirko 
>> ---
>>  include/net/ip_fib.h | 19 +++
>>  net/ipv4/fib_trie.c  | 43 +++
>>  2 files changed, 62 insertions(+)
>> 
>
>The notifier infrastructure should be generalized for use with IPv4 and IPv6. 
>While the data will be family based, the infra can be generic.
>

Yeah, that I thought about as well. Thing is, ipv6 notifier has to be
atomic. That is the reason we have:
inetaddr_chain and register_inetaddr_notifier (blocking notifier)
inet6addr_chain and register_inet6addr_notifier (atomic notifier)

Re: [patch net-next RFC 1/2] fib: introduce fib notification infrastructure

[David Ahern]

On 9/6/16 6:01 AM, Jiri Pirko wrote:
> From: Jiri Pirko 
> 
> This allows to pass information about added/deleted fib entries to
> whoever is interested. This is done in a very similar way as devinet
> notifies address additions/removals.
> 
> Signed-off-by: Jiri Pirko 
> ---
>  include/net/ip_fib.h | 19 +++
>  net/ipv4/fib_trie.c  | 43 +++
>  2 files changed, 62 insertions(+)
> 

The notifier infrastructure should be generalized for use with IPv4 and IPv6. 
While the data will be family based, the infra can be generic.