Documentation/netlink/genetlink-c.yaml | 6 ++++++ Documentation/netlink/genetlink-legacy.yaml | 6 ++++++ Documentation/netlink/netlink-raw.yaml | 6 ++++++ Documentation/netlink/specs/nl80211.yaml | 8 ++++++++ Documentation/netlink/specs/nlctrl.yaml | 2 ++ Documentation/netlink/specs/rt-link.yaml | 2 ++ Documentation/netlink/specs/tc.yaml | 1 + .../userspace-api/netlink/genetlink-legacy.rst | 3 +++ tools/net/ynl/pyynl/lib/ynl.py | 18 ++++++++++++------ 9 files changed, 46 insertions(+), 6 deletions(-)
This patchset adds a way to mark if an indedex array is just an array, and the index is uninteresting, as previously discussed[1]. Which is the case in most of the indexed-arrays in the current specs. As the name indexed-array kinda implies that the index is interesting, then I am using `ignore-index` to mark if the index is unused. This adds some noise to YNL, and as it's only few indexed-arrays which actually use the index, then if we can come up with some good naming, it may be better to reverse it so it's the default behaviour. [1] https://lore.kernel.org/r/7fff6b2f-f17e-4179-8507-397b76ea24bb@intel.com/ Asbjørn Sloth Tønnesen (7): netlink: specs: add ignore-index flag for indexed-array tools: ynl: support ignore-index in indexed-array decoding tools: ynl: support ignore-index in indexed-array encoding netlink: specs: nl80211: set ignore-index on indexed-arrays netlink: specs: nlctrl: set ignore-index on indexed-arrays netlink: specs: rt-link: set ignore-index on indexed-arrays netlink: specs: tc: set ignore-index on indexed-arrays Documentation/netlink/genetlink-c.yaml | 6 ++++++ Documentation/netlink/genetlink-legacy.yaml | 6 ++++++ Documentation/netlink/netlink-raw.yaml | 6 ++++++ Documentation/netlink/specs/nl80211.yaml | 8 ++++++++ Documentation/netlink/specs/nlctrl.yaml | 2 ++ Documentation/netlink/specs/rt-link.yaml | 2 ++ Documentation/netlink/specs/tc.yaml | 1 + .../userspace-api/netlink/genetlink-legacy.rst | 3 +++ tools/net/ynl/pyynl/lib/ynl.py | 18 ++++++++++++------ 9 files changed, 46 insertions(+), 6 deletions(-) -- 2.51.0
On Wed, 22 Oct 2025 18:26:53 +0000 Asbjørn Sloth Tønnesen wrote: > This patchset adds a way to mark if an indedex array is just an > array, and the index is uninteresting, as previously discussed[1]. > > Which is the case in most of the indexed-arrays in the current specs. > > As the name indexed-array kinda implies that the index is interesting, > then I am using `ignore-index` to mark if the index is unused. > > This adds some noise to YNL, and as it's only few indexed-arrays which > actually use the index, then if we can come up with some good naming, > it may be better to reverse it so it's the default behaviour. C code already does this, right? We just collect the attributes completely ignoring the index. So why do we need to extend the spec. Have you found any case where the index matters and can be non-contiguous (other than the known TC kerfuffle). FWIW another concept is what TypeValue does. "Inject" the index into the child nest as an extra member. Most flexible but also prolly a PITA for user space to init those for requests.
On 10/23/25 1:45 AM, Jakub Kicinski wrote: > On Wed, 22 Oct 2025 18:26:53 +0000 Asbjørn Sloth Tønnesen wrote: >> This patchset adds a way to mark if an indedex array is just an >> array, and the index is uninteresting, as previously discussed[1]. >> >> Which is the case in most of the indexed-arrays in the current specs. >> >> As the name indexed-array kinda implies that the index is interesting, >> then I am using `ignore-index` to mark if the index is unused. >> >> This adds some noise to YNL, and as it's only few indexed-arrays which >> actually use the index, then if we can come up with some good naming, >> it may be better to reverse it so it's the default behaviour. > > C code already does this, right? We just collect the attributes > completely ignoring the index. In the userspace C code, for sub-type nest the index is preserved in struct member idx, and elided for other sub-types. > So why do we need to extend the spec. For me it's mostly the naming "indexed-array". Earlier it was "array-nest", then we renamed it to "indexed-array" because it doesn't always contain nests. I think it's counter-intuitive to elide the index by default, for something called "indexed-array". The majority of the families using it don't care about the index. What if we called it "ordered-array", and then always counted from 1 (for families that cares) when packing in user-space code? > Have you found any case where the index matters and can be > non-contiguous (other than the known TC kerfuffle). IFLA_OFFLOAD_XSTATS_HW_S_INFO could be re-defined as a nest, IFLA_OFFLOAD_XSTATS_L3_STATS is the only index atm. IFLA_INET_CONF / IFLA_INET6_CONF is on input, but those are also special by having different types depending on direction. I found a bunch of other ones, using a static index, but they can also be defined as a multi-attr wrapped in an additional outer nest, like IFLA_VF_VLAN_LIST already is. > FWIW another concept is what TypeValue does. > "Inject" the index into the child nest as an extra member. > Most flexible but also prolly a PITA for user space to init those > for requests. Same as is done in the userspace C code for indexed-arrays with sub-type nest. For most families it doesn't matter if the C code inits the index or not.
On Thu, 23 Oct 2025 18:37:09 +0000 Asbjørn Sloth Tønnesen wrote: > > C code already does this, right? We just collect the attributes > > completely ignoring the index. > > In the userspace C code, for sub-type nest the index is preserved > in struct member idx, and elided for other sub-types. I see it now, I guess I added it for get but forgot to obey it for put :( > > So why do we need to extend the spec. > > For me it's mostly the naming "indexed-array". Earlier it was > "array-nest", then we renamed it to "indexed-array" because > it doesn't always contain nests. I think it's counter-intuitive > to elide the index by default, for something called "indexed-array". > The majority of the families using it don't care about the index. > > What if we called it "ordered-array", and then always counted from 1 > (for families that cares) when packing in user-space code? > > > Have you found any case where the index matters and can be > > non-contiguous (other than the known TC kerfuffle). > > IFLA_OFFLOAD_XSTATS_HW_S_INFO could be re-defined as a nest, > IFLA_OFFLOAD_XSTATS_L3_STATS is the only index atm. Isn't that pretty much always true? If the index is significant the whole thing could be redefined as a nest, with names provided in the spec? > IFLA_INET_CONF / IFLA_INET6_CONF is on input, but those are > also special by having different types depending on direction. > > I found a bunch of other ones, using a static index, but they > can also be defined as a multi-attr wrapped in an additional > outer nest, like IFLA_VF_VLAN_LIST already is. Multi-attr with an outer nest should at least solve your wg problem I guess? If all the attrs have type of 0 we can make it a multi-attr. > > FWIW another concept is what TypeValue does. > > "Inject" the index into the child nest as an extra member. > > Most flexible but also prolly a PITA for user space to init those > > for requests. > > Same as is done in the userspace C code for indexed-arrays with > sub-type nest. For most families it doesn't matter if the C code > inits the index or not.
On 10/24/25 12:03 AM, Jakub Kicinski wrote: > On Thu, 23 Oct 2025 18:37:09 +0000 Asbjørn Sloth Tønnesen wrote: >> > C code already does this, right? We just collect the attributes >> > completely ignoring the index. >> >> In the userspace C code, for sub-type nest the index is preserved >> in struct member idx, and elided for other sub-types. > > I see it now, I guess I added it for get but forgot to obey it > for put :( I can fix that up in v2. Do we wanna do the same for sub-type nest in the python client? >> > So why do we need to extend the spec. >> >> For me it's mostly the naming "indexed-array". Earlier it was >> "array-nest", then we renamed it to "indexed-array" because >> it doesn't always contain nests. I think it's counter-intuitive >> to elide the index by default, for something called "indexed-array". >> The majority of the families using it don't care about the index. >> >> What if we called it "ordered-array", and then always counted from 1 >> (for families that cares) when packing in user-space code? >> >> > Have you found any case where the index matters and can be >> > non-contiguous (other than the known TC kerfuffle). >> >> IFLA_OFFLOAD_XSTATS_HW_S_INFO could be re-defined as a nest, >> IFLA_OFFLOAD_XSTATS_L3_STATS is the only index atm. > > Isn't that pretty much always true? If the index is significant > the whole thing could be redefined as a nest, with names provided > in the spec? I guess it depends on the range of indexes, the aboveIFLA_OFFLOAD_XSTATS_L3_STATS is aka. 3, so the new nest policy would be (0..2 = unused, 3 = .._L3_STATS}, which is fine, but for higher indexes it might get a bit silly, but I haven't found any too high indexes. NLBL_CIPSOV4_A_MLSCATLST has NLBL_CIPSOV4_A_MLSCAT which is 11, but that corner seams very dusty, so I don't expect that to get YNL support. Nest + multi-attr is great for the cases where we want per-attr typing, like IFLA_PROP_LIST / IFLA_ALT_IFNAME, but a bit awkward if they all are nests with the same policy. >> IFLA_INET_CONF / IFLA_INET6_CONF is on input, but those are >> also special by having different types depending on direction. >> >> I found a bunch of other ones, using a static index, but they >> can also be defined as a multi-attr wrapped in an additional >> outer nest, like IFLA_VF_VLAN_LIST already is. > > Multi-attr with an outer nest should at least solve your wg problem > I guess? If all the attrs have type of 0 we can make it a multi-attr. WG don't use the index, so it's fine with incrementing from 1. Converting it to nest + multi-attr would require extra pollution in the UAPI, so I don't think I can get that past Jason. It would also be hard to shove in between the elements in the existing naming. I am just trying to get the nits that came up in the previous discussions handled, so they are fixed when I submit the WG spec again, so that I don't have to go back and update it shortly after, as the WG/Jason bandwidth seams pretty limited atm.
On Fri, 24 Oct 2025 19:19:10 +0000 Asbjørn Sloth Tønnesen wrote: > Do we wanna do the same for sub-type nest in the python client? > as the WG/Jason bandwidth seams pretty limited atm. Please focus on what's needed to get WG implemented. My "bandwidth" for pondering cleanups that may not matter in practice is also limited. Main goal for YNL is new families. Polishing the old stuff is a huge time sink.
© 2016 - 2026 Red Hat, Inc.