Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 18/05/2026 à 14:46, Ilya Maximets a écrit :

[snip]

> True and also not really.  The main problem is that ID can be allocated
> at any point in time, so the application needs to listen for NEW messages
> on the same socket that it is listening for the events that are interesting
> to it (to avoid races), if it doesn't want to make a separate GET request
> per notification or track all the IDs that were previously checked.  It's a
> non-trivial amount of code depending on the application structure.
iproute2 handles it ;-)
You certainly need to maintain a cache, but once a nsid is allocated, it never
changes until the netns is deleted.

> 
> Alternative is to always try and allocate the self-referential mapping on
> the application startup and remember it, and then check that no-id, -1 and
> the allocated one all mean 'current'.Yep.

> 
>>
>>>
>>> A search though open-source projects doesn't reveal any projects
>>> that use NETNSA_NSID_NOT_ASSIGNED and rely on metadata to contain
>>> self-referential NSIDs.  Quite the opposite, ovs-vswitchd relies
>>> on the metadata to not be present to separate local and remote
>>> events.  And the 'ip monitor' relies on the metadata to not be present
>>> to show '[nsid current]', though this is more like "print 'current'
>>> if there is nothing to print" situation, but still can be a little
>>> confusing for the user to see an ID for a local event.
>>
>> We (6WIND) are using NETLINK_LISTEN_ALL_NSID. Like iproute2, 'current' is
>> assumed if there is no nsid, else the corresponding netns is checked (which may
>> match the current netns).
> 
> OK.  It sounds like this one patch will not affect your use case than,
> which is good to know.  Thanks!
Probably not, but I didn't say this ;-)
I need to make some tests with your series.

Regards,
Nicolas