netdev - Re: [PATCH net-next v2 00/10] Simplify IPv4 route offload API

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] [day] [month] [year] [list]

Message-Id: <20191216.161513.1612649885729019096.davem@davemloft.net>
Date:   Mon, 16 Dec 2019 16:15:13 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     idosch@...sch.org
Cc:     netdev@...r.kernel.org, dsahern@...il.com,
        roopa@...ulusnetworks.com, jiri@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com,
        idosch@...lanox.com
Subject: Re: [PATCH net-next v2 00/10] Simplify IPv4 route offload API

From: Ido Schimmel <idosch@...sch.org>
Date: Sat, 14 Dec 2019 17:53:05 +0200

> Motivation
> ==========
> 
> The aim of this patch set is to simplify the IPv4 route offload API by
> making the stack a bit smarter about the notifications it is generating.
> This allows driver authors to focus on programming the underlying device
> instead of having to duplicate the IPv4 route insertion logic in their
> driver, which is error-prone.
> 
> This is the first patch set out of a series of four. Subsequent patch
> sets will simplify the IPv6 API, add offload/trap indication to routes
> and add tests for all the code paths (including error paths). Available
> here [1].
> 
> Details
> =======
> 
> Today, whenever an IPv4 route is added or deleted a notification is sent
> in the FIB notification chain and it is up to offload drivers to decide
> if the route should be programmed to the hardware or not. This is not an
> easy task as in hardware routes are keyed by {prefix, prefix length,
> table id}, whereas the kernel can store multiple such routes that only
> differ in metric / TOS / nexthop info.
> 
> This series makes sure that only routes that are actually used in the
> data path are notified to offload drivers. This greatly simplifies the
> work these drivers need to do, as they are now only concerned with
> programming the hardware and do not need to replicate the IPv4 route
> insertion logic and store multiple identical routes.
> 
> The route that is notified is the first FIB alias in the FIB node with
> the given {prefix, prefix length, table ID}. In case the route is
> deleted and there is another route with the same key, a replace
> notification is emitted. Otherwise, a delete notification is emitted.
> 
> The above means that in the case of multiple routes with the same key,
> but different TOS, only the route with the highest TOS is notified.
> While the kernel can route a packet based on its TOS, this is not
> supported by any hardware devices I am familiar with. Moreover, this is
> not supported by IPv6 nor by BIRD/FRR from what I could see. Offload
> drivers should therefore use the presence of a non-zero TOS as an
> indication to trap packets matching the route and let the kernel route
> them instead. mlxsw has been doing it for the past two years.
 ...

Series applied, thanks!