netdev - Re: [PATCH net-next 05/10] net: ipv4: Emit notification when fib hardware flags are changed

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: <79194116-6d96-eb13-c845-b5d268df7a82@gmail.com>
Date:   Tue, 26 Jan 2021 22:02:50 -0700
From:   David Ahern <dsahern@...il.com>
To:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org, amcohen@...dia.com,
        roopa@...dia.com, sharpd@...dia.com, bpoirier@...dia.com,
        mlxsw@...dia.com, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 05/10] net: ipv4: Emit notification when fib
 hardware flags are changed

On 1/26/21 6:23 AM, Ido Schimmel wrote:
> From: Amit Cohen <amcohen@...dia.com>
> 
> After installing a route to the kernel, user space receives an
> acknowledgment, which means the route was installed in the kernel,
> but not necessarily in hardware.
> 
> The asynchronous nature of route installation in hardware can lead to a
> routing daemon advertising a route before it was actually installed in
> hardware. This can result in packet loss or mis-routed packets until the
> route is installed in hardware.
> 
> It is also possible for a route already installed in hardware to change
> its action and therefore its flags. For example, a host route that is
> trapping packets can be "promoted" to perform decapsulation following
> the installation of an IPinIP/VXLAN tunnel.
> 
> Emit RTM_NEWROUTE notifications whenever RTM_F_OFFLOAD/RTM_F_TRAP flags
> are changed. The aim is to provide an indication to user-space
> (e.g., routing daemons) about the state of the route in hardware.
> 
> Introduce a sysctl that controls this behavior.
> 
> Keep the default value at 0 (i.e., do not emit notifications) for several
> reasons:
> - Multiple RTM_NEWROUTE notification per-route might confuse existing
>   routing daemons.

are you aware of any routing daemons that are affected? Seems like they
should be able to handle redundant notifications

> - Convergence reasons in routing daemons.
> - The extra notifications will negatively impact the insertion rate.

any numbers on the overhead?

> - Not all users are interested in these notifications.
> 
> Signed-off-by: Amit Cohen <amcohen@...dia.com>
> Acked-by: Roopa Prabhu <roopa@...dia.com>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
>  Documentation/networking/ip-sysctl.rst | 20 +++++++++++++++++++
>  include/net/netns/ipv4.h               |  2 ++
>  net/ipv4/af_inet.c                     |  2 ++
>  net/ipv4/fib_trie.c                    | 27 ++++++++++++++++++++++++++
>  net/ipv4/sysctl_net_ipv4.c             |  9 +++++++++
>  5 files changed, 60 insertions(+)
>