From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f172.google.com ([209.85.192.172]:41052 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751079AbeBZWr6 (ORCPT ); Mon, 26 Feb 2018 17:47:58 -0500 Received: by mail-pf0-f172.google.com with SMTP id f80so2034323pfa.8 for ; Mon, 26 Feb 2018 14:47:58 -0800 (PST) Subject: Re: [PATCH RFC net-next 07/20] net/ipv6: Move nexthop data to fib6_nh To: Wei Wang Cc: Linux Kernel Network Developers , "David S . Miller" , Ido Schimmel , roopa@cumulusnetworks.com, Eric Dumazet , Martin KaFai Lau , Hideaki YOSHIFUJI References: <20180225194730.30063-1-dsahern@gmail.com> <20180225194730.30063-8-dsahern@gmail.com> From: David Ahern Message-ID: <2d706063-6ffd-5c71-59de-d8f8cf3c5a20@gmail.com> Date: Mon, 26 Feb 2018 15:47:55 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: On 2/26/18 3:28 PM, Wei Wang wrote: > On Sun, Feb 25, 2018 at 11:47 AM, David Ahern wrote: >> Introduce fib6_nh structure and move nexthop related data from >> rt6_info and rt6_info.dst to fib6_nh. References to dev, gateway or >> lwtstate from a FIB lookup perspective are converted to use fib6_nh; >> datapath references to dst version are left as is. >> > > My understanding is that after your whole patch series, sibling routes > will still have their own fib6_info. Does it make sense to make this > fib6_nh as an array in fib6_info so that sibling routes will share > fib6_info but will have their own fib6_nh as a future improvement? It > matches ipv4 behavior. And I think it will make the sibling route > handling code easier? I was not planning to. IPv6 allowing individual nexthops to be added and deleted is very convenient. I do agree the existing sibling route linkage makes the code much more complicated than it needs to be. After this set, I plan to send patches for nexthops as separate objects - which will have an impact on how multipath routes are done. With nexthop objects there will be 1 prefix route pointing to a nexthop object that is multipath (meaning it points in turn to a series of nexthop objects). This provides the simplification (no sibling linkage) without losing the individual nexhtop add / delete option.