Re: [PATCH net-next 4/4] ipv6: Add support for non-equal-cost multipath

Hi David,

On Tue, Jan 09, 2018 at 08:48:37PM -0700, David Ahern wrote:

On 1/9/18 7:40 AM, Ido Schimmel wrote:

quoted

The use of hash-threshold instead of modulo-N makes it trivial to add
support for non-equal-cost multipath.

Instead of dividing the multipath hash function's output space equally
between the nexthops, each nexthop is assigned a region size which is
proportional to its weight.

Signed-off-by: Ido Schimmel <redacted>
---
 include/net/ip6_fib.h |  1 +
 net/ipv6/route.c      | 11 +++++++----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 97cd05d87780..34ec321d6a03 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h

@@ -171,6 +171,7 @@ struct rt6_info {
 	u32				rt6i_metric;
 	u32				rt6i_pmtu;
 	/* more non-fragment space at head required */
+	int				rt6i_nh_weight;
 	unsigned short			rt6i_nfheader_len;
 	u8				rt6i_protocol;
 	u8				exception_bucket_flushed:1,

Since dst is cacheline aligned there is a hole after rt6i_nh_flags. In
patch 1 you put rt6i_nh_upper_bound in that hole. Putting the weight
there too keeps those variables together as well as using the open space.

Before patch 1 there's a hole of 4 bytes after rt6i_nh_flags which I use
for rt6i_nh_upper_bound. If I put rt6i_nh_weight there as well, then I
create a 60 bytes hole because the dst needs to be cached aligned.

Since rt6i_nh_weight isn't used in fast-path, I just put it at the end.