[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230725095622.33fedff7@kernel.org>
Date: Tue, 25 Jul 2023 09:56:22 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
mkubecek@...e.cz, lorenzo@...nel.org
Subject: Re: [PATCH net-next 1/2] net: store netdevs in an xarray
On Tue, 25 Jul 2023 13:11:50 +0200 Paolo Abeni wrote:
> > We can get the create, delete ordering with this or the list, but the
> > inverse theoretical case of delete, create ordering can't be covered.
> > A case where user wants to make sure at most one device is visible.
> >
> > I'm not sure how much we should care about this. The basic hash table
> > had the very real problem of hiding devices which were there *before
> > and after* the dump.
> >
> > Inconsistent info on devices which were created / deleted *during* the
> > dump seems to me like something that's best handled with notifications.
> >
> > I'm not sure whether we should set the inconsistency mark on the dump
> > when del/add operation happened in the meantime either, as
> > the probability that the user space will care is minuscule.
>
> You convinced me the 'missed device' scenario is not very relevant.
>
> The cursor with the dummy placeholder looks error-prone and/or too
> invasive to me.
>
> I'm fine with this approach.
I'll post a v2 with the fix Leon pointed out.
But do feel free to change your mind.
It seems like a problem where there's no perfect solution but
there are multiple non-perfect ones, each with its advantages
and disadvantages.
Powered by blists - more mailing lists