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
