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]

Date:   Thu, 28 Jan 2021 20:33:22 -0700
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>, Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, 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/28/21 8:04 PM, Jakub Kicinski wrote:
> On Tue, 26 Jan 2021 15:23:06 +0200 Ido Schimmel wrote:
>> 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.
> 
> What does the daemon in the user space do with it?

You don't want FRR for example to advertise a route to a peer until it
is really programmed in h/w. This notification gives routing daemons
that information.

> 
> The notification will only be generated for the _first_ ASIC which
> offloaded the object. Which may be fine for you today but as an uAPI 
> it feels slightly lacking.
> 
> If the user space just wants to make sure the devices are synced to
> notifications from certain stage, wouldn't it be more idiomatic to
> provide some "fence" operation?
> 
> WDYT? David?
> 

This feature was first discussed I think about 2 years ago - when I was
still with Cumulus, so I already knew the intent and end goal.

I think support for multiple ASICs / NICs doing this kind of offload
will have a whole lot of challenges. I don't think this particular user
notification is going to be a big problem - e.g., you could always delay
the emit until all have indicated the offload.