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
| ||
|
Date: Mon, 23 Dec 2019 15:28:11 +0200 From: Ido Schimmel <idosch@...sch.org> To: netdev@...r.kernel.org Cc: davem@...emloft.net, dsahern@...il.com, roopa@...ulusnetworks.com, jakub.kicinski@...ronome.com, jiri@...lanox.com, Ido Schimmel <idosch@...lanox.com> Subject: [PATCH net-next 0/9] Simplify IPv6 route offload API From: Ido Schimmel <idosch@...lanox.com> Motivation ========== This is the IPv6 counterpart of "Simplify IPv4 route offload API" [1]. The aim of this patch set is to simplify the IPv6 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 IPv6 route insertion logic in their driver, which is error-prone. Details ======= Today, whenever an IPv6 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 / 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 IPv6 route insertion logic and store multiple identical routes. The route that is notified is the first route in the IPv6 FIB node, which represents a single prefix and length in a given table. 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. Unlike IPv4, in IPv6 it is possible to append individual nexthops to an existing multipath route. Therefore, in addition to the replace and delete notifications present in IPv4, an append notification is also used. Testing ======= To ensure there is no degradation in route insertion rates, I averaged the insertion rate of 512k routes (/64 and /128) over 50 runs. Did not observe any degradation. Functional tests are available here [2]. They rely on route trap indication, which is added in a subsequent patch set. In addition, I have been running syzkaller for the past couple of weeks with debug options enabled. Did not observe any problems. Patch set overview ================== Patches #1-#7 gradually introduce the new FIB notifications Patch #8 converts mlxsw to use the new notifications Patch #9 remove the old notifications [1] https://patchwork.ozlabs.org/cover/1209738/ [2] https://github.com/idosch/linux/tree/fib-notifier Ido Schimmel (9): net: fib_notifier: Add temporary events to the FIB notification chain ipv6: Notify newly added route if should be offloaded ipv6: Notify route if replacing currently offloaded one ipv6: Notify multipath route if should be offloaded ipv6: Only Replay routes of interest to new listeners ipv6: Handle route deletion notification ipv6: Handle multipath route deletion notification mlxsw: spectrum_router: Start using new IPv6 route notifications ipv6: Remove old route notifications and convert listeners .../ethernet/mellanox/mlxsw/spectrum_router.c | 218 ++++++------------ drivers/net/netdevsim/fib.c | 1 - include/net/ip6_fib.h | 1 + net/ipv6/ip6_fib.c | 108 +++++++-- net/ipv6/route.c | 86 +++++-- 5 files changed, 238 insertions(+), 176 deletions(-) -- 2.24.1
Powered by blists - more mailing lists