Message-ID: <ee3b6ed7-a00d-4679-9aa6-482b8064d18f@fiberby.net>
Date: Fri, 24 Oct 2025 19:19:10 +0000
From: Asbjørn Sloth Tønnesen <ast@...erby.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>,
 Chuck Lever <chuck.lever@...cle.com>, Donald Hunter
 <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>,
 "Matthieu Baerts (NGI0)" <matttbe@...nel.org>,
 Simon Horman <horms@...nel.org>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 "Jason A. Donenfeld" <Jason@...c4.com>,
 Zahari Doychev <zahari.doychev@...ux.com>
Subject: Re: [PATCH net-next 0/7] ynl: add ignore-index flag for indexed-array

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.

Powered by blists - more mailing lists