Re: [PATCH net-next 1/2] net: store netdevs in an xarray

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 25 Jul 2023 19:54:43 +0200 Sabrina Dubroca wrote:
> > > And if that's not enough we can make the iteration index ulong 
> > > (i.e. something separate from ifindex as ifindex is hardwired to 31b
> > > by uAPI).  
> > 
> > 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.  
> 
> The inconsistent dump mark may be more relevant for changes in device
> properties than link creation/removal. If the MTU on 2 devices changes
> while the dump is running (one low ifindex, one high ifindex), we'll
> see the old MTU for the first device and the new MTU for the 2nd. Or
> by adding/removing bridge ports while the dump runs, I can make it
> look like bridge0 has mulitple ports with the same port_no.
> 
> I don't know how likely those cases are, but if they happen I think
> they'd be more confusing than a missing/extra device.

I believe that for netdevs dev_base_seq_inc() is used to indicate 
a change. It's only called when listing / unlisting devices so
the changes to device config are already not covered :(