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]
Date:   Wed, 27 Jan 2021 11:46:16 +0000
From:   Amit Cohen <amcohen@...dia.com>
To:     David Ahern <dsahern@...il.com>, Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        Roopa Prabhu <roopa@...dia.com>,
        Donald Sharp <sharpd@...dia.com>,
        Benjamin Poirier <bpoirier@...dia.com>,
        mlxsw <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



>-----Original Message-----
>From: David Ahern <dsahern@...il.com>
>Sent: Wednesday, January 27, 2021 7:03
>To: Ido Schimmel <idosch@...sch.org>; netdev@...r.kernel.org
>Cc: davem@...emloft.net; kuba@...nel.org; Amit Cohen <amcohen@...dia.com>; Roopa Prabhu <roopa@...dia.com>; Donald
>Sharp <sharpd@...dia.com>; Benjamin Poirier <bpoirier@...dia.com>; mlxsw <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

Actually no, we didn't check all the existing daemons, just assume that not everyone will want to activate the notifications at all.
So there is no point in sending notifications for users which aren't interested in them.

>
>> - Convergence reasons in routing daemons.
>> - The extra notifications will negatively impact the insertion rate.
>
>any numbers on the overhead?

For addition of 256k routes in mlxsw, the overhead is 3.6% of the total time.

>
>> - 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(+)
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ