Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
On 3/24/18 9:59 AM, Ido Schimmel wrote: >> As you know, my preference is to move to nexthop objects (makes fib6_nh >> optional). I have IPv4 done; IPv6 requires this patch set. > > After going over your presentation [1] I was under the impression that > the fib6_info will be optional, not fib6_nh: "Idea is similar to adding > id to fib_info that is exposed to userspace. Subsequent routes pass id > to avoid fib_info overhead". Just using that as an analogy to explain the idea in terms of something that already exists. > > But I think misunderstood you. You want to introduce the nexthop API > that will allow you to have multiple fib6_info pointing to the same > fib6_nh? > > 1. http://vger.kernel.org/netconf2017_files/nexthop-objects.pdf > I see nexthop specs as device, gateway, lwtunnel_state and flags. That's the basic building block. A nexthop group is multiple nexthops where each nexthop in the group as its own weight. The fib_info struct has more than that -- data unrelated to a netxthop and is really a next level struct.
Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
On Sat, Mar 24, 2018 at 09:28:01AM -0600, David Ahern wrote: > On 3/24/18 9:05 AM, Ido Schimmel wrote: > > On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: > >> This set is the first of many changes to improve the scalability of the > >> IPv6 code. Follow on changes include: > >> - consolidating duplicate fib6_info references like IPv4 does with > >> duplicate fib_info > > > > Before that you need to further break fib6_info into fib6_info and > > fib6_alias, or I misunderstood you? > > > > I was only listing the high level intent - to consolidate duplication. I > have not looked into that step yet, but I suspect that split can be done > in the same patch set as consolidating duplicate fib6_info. I don't think you can perform consolidation of fib6_info as long as it describes both the route and the nexthop info. > As you know, my preference is to move to nexthop objects (makes fib6_nh > optional). I have IPv4 done; IPv6 requires this patch set. After going over your presentation [1] I was under the impression that the fib6_info will be optional, not fib6_nh: "Idea is similar to adding id to fib_info that is exposed to userspace. Subsequent routes pass id to avoid fib_info overhead". But I think misunderstood you. You want to introduce the nexthop API that will allow you to have multiple fib6_info pointing to the same fib6_nh? 1. http://vger.kernel.org/netconf2017_files/nexthop-objects.pdf
Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
On 3/24/18 9:05 AM, Ido Schimmel wrote: > On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: >> This set is the first of many changes to improve the scalability of the >> IPv6 code. Follow on changes include: >> - consolidating duplicate fib6_info references like IPv4 does with >> duplicate fib_info > > Before that you need to further break fib6_info into fib6_info and > fib6_alias, or I misunderstood you? > I was only listing the high level intent - to consolidate duplication. I have not looked into that step yet, but I suspect that split can be done in the same patch set as consolidating duplicate fib6_info. As you know, my preference is to move to nexthop objects (makes fib6_nh optional). I have IPv4 done; IPv6 requires this patch set. To get there the patch sequence is: 1. separate data structures for fib and dst paths (this set), 2. cleanup set on top of this one (separate set only because this one is at 21 patches), and 3. nexthop API.
Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: > This set is the first of many changes to improve the scalability of the > IPv6 code. Follow on changes include: > - consolidating duplicate fib6_info references like IPv4 does with > duplicate fib_info Before that you need to further break fib6_info into fib6_info and fib6_alias, or I misunderstood you?
Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
From: David Ahern Date: Sun, 18 Mar 2018 20:36:01 -0700 > RFC v2 changes > - improved commit messages > - move common metrics code from dst.c to net/ipv4/metrics.c (comment > from DaveM) > - address comments from Wei Wang and Martin KaFai Lau (let me know if > I missed something) > - fixes detected by kernel test robots > + added fib6_metric_set to change metric on a FIB entry which could > be pointing to read-only dst_default_metrics > + 0day testing found a problem with an intermediate patch; added > dst_hold_safe on rt->from. Code is removed 3 patches later > - allow cacheinfo to handle NULL dst; means only expires is pushed to > userspace Series looks great to me. Nice work David.
