forked from rockchip-linux/kernel
-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'Simplify-IPv4-route-offload-API'
Ido Schimmel says: ==================== Simplify IPv4 route offload API 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. Testing ======= To ensure there is no degradation in route insertion rates, I averaged the insertion rate of 512k routes (/24 and /32) over 50 runs. Did not observe any degradation. Functional tests are available here [1]. They rely on route trap indication, which is only added in the last patch set. In addition, I have been running syzkaller for the past week with all four patch sets and debug options enabled. Did not observe any problems. Patch set overview ================== Patches #1-#8 gradually introduce the new FIB notifications Patch #9 converts mlxsw to use the new notifications Patch #10 converts the remaining listeners and removes the old notifications v2: * Extend fib_find_alias() with another argument instead of introducing a new function (David Ahern) RFC: https://patchwork.ozlabs.org/cover/1170530/ [1] https://github.com/idosch/linux/tree/fib-notifier ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
- Loading branch information
Showing
5 changed files
with
104 additions
and
165 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.