All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <razor@blackwall.org>
To: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org
Cc: roopa@nvidia.com, donaldsharp72@gmail.com, idosch@idosch.org,
	Nikolay Aleksandrov <nikolay@nvidia.com>
Subject: Re: [RFC iproute2-next 00/11] ip: nexthop: cache nexthops and print routes' nh info
Date: Thu, 30 Sep 2021 10:17:03 +0300	[thread overview]
Message-ID: <b700e57b-3687-9c36-c741-a25e423562ff@blackwall.org> (raw)
In-Reply-To: <0ffec3e8-63ba-ce85-7a5a-d092420749df@gmail.com>

On 30/09/2021 06:42, David Ahern wrote:
> On 9/29/21 9:28 AM, Nikolay Aleksandrov wrote:
>> From: Nikolay Aleksandrov <nikolay@nvidia.com>
>>
>> Hi,
>> This set tries to help with an old ask that we've had for some time
>> which is to print nexthop information while monitoring or dumping routes.
>> The core problem is that people cannot follow nexthop changes while
>> monitoring route changes, by the time they check the nexthop it could be
>> deleted or updated to something else. In order to help them out I've
>> added a nexthop cache which is populated (only used if -d / show_details
>> is specified) while decoding routes and kept up to date while monitoring.
>> The nexthop information is printed on its own line starting with the
>> "nh_info" attribute and its embedded inside it if printing JSON. To
>> cache the nexthop entries I parse them into structures, in order to
>> reuse most of the code the print helpers have been altered so they rely
>> on prepared structures. Nexthops are now always parsed into a structure,
>> even if they won't be cached, that structure is later used to print the
>> nexthop and destroyed if not going to be cached. New nexthops (not found
>> in the cache) are retrieved from the kernel using a private netlink
>> socket so they don't disrupt an ongoing dump, similar to how interfaces
>> are retrieved and cached.
>>
>> I have tested the set with the kernel forwarding selftests and also by
>> stressing it with nexthop create/update/delete in loops while monitoring.
>>
>> Comments are very welcome as usual. :)
> 
> overall it looks fine and not surprised a cache is needed.
> 
> Big comment is to re-order the patches - do all of the refactoring first
> to get the code where you need it and then add what is needed for the cache.
> 

Thanks for the comments, apart from pairing the add parse/use parse functions
in the first few patches only patch 08 seems out of place, although it's there
because it was first needed in patch 09, I don't mind pulling it back.
All other patches after 06 are adding the new cache and print functions and
using them in iproute/ipmonitor, there is no refactoring done in those, so I
plan to keep those as they are.

Cheers,
 Nik


      reply	other threads:[~2021-09-30  7:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 15:28 [RFC iproute2-next 00/11] ip: nexthop: cache nexthops and print routes' nh info Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 01/11] ip: print_rta_if takes ifindex as device argument instead of attribute Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 02/11] ip: export print_rta_gateway version which outputs prepared gateway string Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 03/11] ip: nexthop: add nh struct and a helper to parse nhmsg into it Nikolay Aleksandrov
2021-09-30  3:33   ` David Ahern
2021-09-29 15:28 ` [RFC iproute2-next 04/11] ip: nexthop: parse resilient nexthop group attribute into structure Nikolay Aleksandrov
2021-09-30  3:35   ` David Ahern
2021-09-29 15:28 ` [RFC iproute2-next 05/11] ip: nexthop: always parse attributes for printing Nikolay Aleksandrov
2021-09-30  3:37   ` David Ahern
2021-09-30  7:10     ` Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 06/11] ip: nexthop: pull ipnh_get_id rtnl talk into a helper Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 07/11] ip: nexthop: add cache helpers Nikolay Aleksandrov
2021-09-30  3:39   ` David Ahern
2021-09-30  6:53     ` Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 08/11] ip: nexthop: factor out entry printing Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 09/11] ip: nexthop: add a helper which retrieves and prints cached nh entry Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 10/11] ip: route: print and cache detailed nexthop information when requested Nikolay Aleksandrov
2021-09-29 15:28 ` [RFC iproute2-next 11/11] ip: nexthop: add print_cache_nexthop which prints and manages the nh cache Nikolay Aleksandrov
2021-09-30  3:42 ` [RFC iproute2-next 00/11] ip: nexthop: cache nexthops and print routes' nh info David Ahern
2021-09-30  7:17   ` Nikolay Aleksandrov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b700e57b-3687-9c36-c741-a25e423562ff@blackwall.org \
    --to=razor@blackwall.org \
    --cc=donaldsharp72@gmail.com \
    --cc=dsahern@gmail.com \
    --cc=idosch@idosch.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=roopa@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.