From: Jakub Kicinski <kuba@kernel.org>
To: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
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 17:03:42 -0700 [thread overview]
Message-ID: <20251023170342.2bb7ce83@kernel.org> (raw)
In-Reply-To: <f35cb9c8-7a5d-4fb7-b69b-aa14ab7f1dd5@fiberby.net>
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.
next prev parent reply other threads:[~2025-10-24 0:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 18:26 [PATCH net-next 0/7] ynl: add ignore-index flag for indexed-array 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
2025-10-24 0:03 ` Jakub Kicinski [this message]
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=20251023170342.2bb7ce83@kernel.org \
--to=kuba@kernel.org \
--cc=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=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;
as well as URLs for NNTP newsgroup(s).