From: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>,
Chuck Lever <chuck.lever@oracle.com>,
Donald Hunter <donald.hunter@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>,
Simon Horman <horms@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 0/7] ynl: add ignore-index flag for indexed-array
Date: Thu, 23 Oct 2025 18:37:09 +0000 [thread overview]
Message-ID: <f35cb9c8-7a5d-4fb7-b69b-aa14ab7f1dd5@fiberby.net> (raw)
In-Reply-To: <20251022184517.55b95744@kernel.org>
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.
next prev parent reply other threads:[~2025-10-23 18:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 18:26 Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 1/7] netlink: specs: " Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 2/7] tools: ynl: support ignore-index in indexed-array decoding Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 3/7] tools: ynl: support ignore-index in indexed-array encoding Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 4/7] netlink: specs: nl80211: set ignore-index on indexed-arrays Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 5/7] netlink: specs: nlctrl: " Asbjørn Sloth Tønnesen
2025-10-22 18:26 ` [PATCH net-next 6/7] netlink: specs: rt-link: " Asbjørn Sloth Tønnesen
2025-10-22 18:27 ` [PATCH net-next 7/7] netlink: specs: tc: " Asbjørn Sloth Tønnesen
2025-10-23 1:45 ` [PATCH net-next 0/7] ynl: add ignore-index flag for indexed-array Jakub Kicinski
2025-10-23 18:37 ` Asbjørn Sloth Tønnesen [this message]
2025-10-24 0:03 ` Jakub Kicinski
2025-10-24 19:19 ` Asbjørn Sloth Tønnesen
2025-10-24 23:52 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f35cb9c8-7a5d-4fb7-b69b-aa14ab7f1dd5@fiberby.net \
--to=ast@fiberby.net \
--cc=chia-yu.chang@nokia-bell-labs.com \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matttbe@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®