[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZwXG7Un2jF6HVNQ8@LQ3V64L9R2>
Date: Tue, 8 Oct 2024 16:57:33 -0700
From: Joe Damato <jdamato@...tly.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, mkarsten@...terloo.ca, skhawaja@...gle.com,
sdf@...ichev.me, bjorn@...osinc.com, amritha.nambiar@...el.com,
sridhar.samudrala@...el.com, willemdebruijn.kernel@...il.com,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Donald Hunter <donald.hunter@...il.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Mina Almasry <almasrymina@...gle.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Daniel Jurgens <danielj@...dia.com>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC net-next v4 6/9] netdev-genl: Support setting per-NAPI
config values
On Tue, Oct 08, 2024 at 04:19:19PM -0700, Jakub Kicinski wrote:
> On Tue, 8 Oct 2024 16:00:41 -0700 Joe Damato wrote:
> > > Make sure you edit the spec, not the output. Looks like there may be
> > > a problem here (napi-id vs id in the attributes).
> >
> > I'm not sure I follow this part, sorry if I'm just missing something
> > here.
> >
> > I was referring to NETDEV_A_NAPI_DEFER_HARD_IRQS which in RFCv4 is
> > listed as NLA_S32 (in this patch):
> >
> > static const struct nla_policy netdev_napi_set_nl_policy[NETDEV_A_NAPI_GRO_FLUSH_TIMEOUT + 1] = {
> > [NETDEV_A_NAPI_ID] = { .type = NLA_U32, },
> > [NETDEV_A_NAPI_DEFER_HARD_IRQS] = { .type = NLA_S32 },
> >
> > However, in the yaml spec (patch 2/9):
> >
> > + -
> > + name: defer-hard-irqs
> > + doc: The number of consecutive empty polls before IRQ deferral ends
> > + and hardware IRQs are re-enabled.
> > + type: u32
> > + checks:
> > + max: s32-max
> >
> > So the type is u32 but with a "checks" to match what happens now in
> > sysfs.
> >
> > That's why I mentioned changing NLA_S32 to NLA_U32.
> >
> > Am I missing something?
>
> YNL will generate the correct code for your - the right type
> and the right range validation. Run the command below to see.
>
> > Not sure what you meant by "napi-id vs id" ?
>
> I can't apply the series now, but when it was posted the YNL code
> generation failed here complaining about napi-id not existing in
> the attribute set in which it is used. In the napi attribute set
> the NAPI ID is called just "id", not "napi-id".
Ah, I see what you mean now. It should have been obvious, but the
-gen* files are, uh, auto-generated ;)
And yes, I see now that the attribute set names it "id", so I've
fixed it and the command runs clean and I'll include the generated
output this time in the v5.
Powered by blists - more mailing lists