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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.