public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Martin Schitter <ms+git@mur.at>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v2 3/3] Optimize route dependency solver.
Date: Mon, 21 Sep 2026 11:34:50 +0200	[thread overview]
Message-ID: <ae1a2a79-c592-4eec-809a-314dcde0f738@mur.at> (raw)
In-Reply-To: <20260919150739.5d1f34ca@elisabeth>



On 9/19/26 15:07, Stefano Brivio wrote:
> Just a quick comment before you risk losing a lot of time (I'm really
> not sure though): there*might* be interdependencies between routes in
> 1. and between routes in 2., especially with 'nexthop' objects. And
> IPv6 has several scopes. Maybe it all works thought, I haven't checked
> your iproute reference yet.

This alternative approach is looking for route table entries in exactly 
the same tables and scopes. There is no difference in this regard. It's 
just using a more rational strategy to minimize dependency errors.

The most common cause for EHOSTUNREACH and ENETUNREACH errors are 
related to attempts adding a route without having defined the local exit 
capabilities first. There are still a few other possible reasons causing 
these particular errors (policy routing, disabled interfaces, etc.), but 
those cases are also not solved by any of our previous solutions! The 
errors just got ignored after many useless loops and costly operations.

You can iterate as often as you like over this list of route entries and 
try to add them, but the amount of dependency errors will stay the same 
after just a few attempts (those, which define the elementary local host 
and network route connectivity information).

We don't have to solve a complex network of transitive dependency 
relations, but only respect the much simpler order of dependency 
relations between very few different classes of entries.

Well, that's at least my current understanding of this issue.
But I still have to further think about it and test it in practice...

      reply	other threads:[~2026-09-21  9:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 18:13 [PATCH v2] Fix for Bug #221 -- Issue concerning bigger routing tables Martin Schitter
2026-09-08 18:13 ` [PATCH v2 1/3] Fix handling of netlink multipart route dumps Martin Schitter
2026-09-17 19:08   ` Stefano Brivio
2026-09-19 12:56     ` Martin Schitter
2026-09-08 18:13 ` [PATCH v2 2/3] Timekeeping: Resolving Route Dependencies Martin Schitter
2026-09-17 19:08   ` Stefano Brivio
2026-09-19 12:56     ` Martin Schitter
2026-09-08 18:13 ` [PATCH v2 3/3] Optimize route dependency solver Martin Schitter
2026-09-17 19:08   ` Stefano Brivio
2026-09-19 12:56     ` Martin Schitter
2026-09-19 13:07       ` Stefano Brivio
2026-09-21  9:34         ` Martin Schitter [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=ae1a2a79-c592-4eec-809a-314dcde0f738@mur.at \
    --to=ms+git@mur.at \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).