netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>
Cc: mptcp@lists.linux.dev, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Mat Martineau <martineau@kernel.org>,
	Geliang Tang <geliang@kernel.org>,
	netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/6] selftests: net: lib: remove ns from list after clean-up
Date: Sat, 15 Jun 2024 08:40:05 +0100	[thread overview]
Message-ID: <20240615074005.GB8447@kernel.org> (raw)
In-Reply-To: <54e9c949-da29-4a19-af29-55aac52afbf9@kernel.org>

Hi Matthieu,

Likewise, thanks for your response.

On Fri, Jun 14, 2024 at 04:42:38PM +0200, Matthieu Baerts wrote:
> Hi Simon,
> 
> Thank you for your reply!
> 
> On 14/06/2024 12:40, Simon Horman wrote:
> > On Fri, Jun 07, 2024 at 06:31:03PM +0200, Matthieu Baerts (NGI0) wrote:
> >> Instead of only appending items to the list, removing them when the
> >> netns has been deleted.
> >>
> >> By doing that, we can make sure 'cleanup_all_ns()' is not trying to
> >> remove already deleted netns.
> > 
> > I do wonder if we can go a step further and use an associative array for
> > ns_list (maybe renamed).  I think this would reduce remove_ns_list to
> > something like:
> > 
> > 	unset ns_list["$item"]
> 
> I agree that it would ease the removal of one item -- which is not
> complex to deal with the new helper :) -- but do you see any other benefits?
> 
> For the moment, there is no other value to associate with, so we would
> do something like NS_MAP["$ns"]=1. We could link the name of the global
> variable, but that's not needed for the tests for the moment.
> 
> Also, I don't know if it is important, but when we will iterate over the
> list of netns, it will not be done following the same order items have
> been added into the hashmap. So we will change the order in which items
> are deleted.

I agree that it would probably end up being a NS_MAP["$ns"]=1,
i.e. a dummy value as there is no natural one to use.

I had not considered the order issue.

And yes, the benefit I see would be limited to removal.
Which as you point out is not a terrible burden with the helper you added.
While, OTOH, my idea adds complexity and unknowns elsewhere.

So overall, perhaps it's best left as an idea for later.
As the code changes for other reasons (who knows what?)
an associative array may make more sense than it does now.

> > OTOH, perhaps this breaks with older versions of bash that we still
> > care about.
> 
> Good point. I don't have the answer, but associative arrays are starting
> to be quite old now :)

Yes, I think so too.
But I also thought it was worth mentioning.

  reply	other threads:[~2024-06-15  7:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 16:31 [PATCH net-next 0/6] selftests: mptcp: use net/lib.sh to manage netns Matthieu Baerts (NGI0)
2024-06-07 16:31 ` [PATCH net-next 1/6] selftests: net: lib: ignore possible errors Matthieu Baerts (NGI0)
2024-06-07 16:31 ` [PATCH net-next 2/6] selftests: net: lib: remove ns from list after clean-up Matthieu Baerts (NGI0)
2024-06-14 10:40   ` Simon Horman
2024-06-14 14:42     ` Matthieu Baerts
2024-06-15  7:40       ` Simon Horman [this message]
2024-06-07 16:31 ` [PATCH net-next 3/6] selftests: net: lib: do not set ns var as readonly Matthieu Baerts (NGI0)
2024-06-07 16:31 ` [PATCH net-next 4/6] selftests: net: lib: remove 'ns' var in setup_ns Matthieu Baerts (NGI0)
2024-06-07 16:31 ` [PATCH net-next 5/6] selftests: mptcp: lib: use setup/cleanup_ns helpers Matthieu Baerts (NGI0)
2024-06-07 16:31 ` [PATCH net-next 6/6] selftests: mptcp: lib: use wait_local_port_listen helper Matthieu Baerts (NGI0)
2024-06-12  3:00 ` [PATCH net-next 0/6] selftests: mptcp: use net/lib.sh to manage netns patchwork-bot+netdevbpf

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=20240615074005.GB8447@kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=geliang@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    /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 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 NNTP newsgroup(s).