This is the second part of routing subsystem changes initially described in D24141.
First part of these changes has been landed in D24232.
Support for outbound hashing is in D26523.
Implementation
- Follows the same implementation as nexthop objects and reuses parts of the infrastructure.
- Nexthop groups are stored in the resizable hash and are indexed in the same way nexthops do.
- Similarly, there is a private part (contains pointes to nexthops and relative wights) and dataplane-visible part, consisting of array of nexthops to choose from.
- Max nhgrp wifth is set to 64 (no limitations here, can be bumped futher)
- Lazy initialisation: allocate index/hash memory at first attempt to add multipath route.
- rt_nhop can now point to either nexthop or nexthop group (distinguished by NHF_MULTIPATH flag.
- all dataplane functions handle nexthop selection internally
- routing table notifications can now notify on switching between nexthop groups -> rib_decompose_notification() has been created to decompose such notifications to a set of old "simple" add/del/change operations.
User-visible changes
- Backward compatible: all non-multipath functionality continues to work as is
- All routes comes up with weights, default is 1, max is 16M (2^24).
- route delete <prefix> will work for non-multipath prefixes, specifying gateway is required for multipath ones
Hashing
- Relies on mbuf flowid for both transit and outbound traffic.
- For locally-originated connections we don’t currently calculate inp_flowid. As performance optimization, start calculating these hashes after inserting first multipath route (V_hash_outbound).
Rollout stages
- Commit with net.route.multipath=0 by default even with ROUTE_MPATH
- Enable ROUTE_MPATH in amd64 GENERIC.
- Turn on net.route.multipath=1 by default