netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).