From: netdev-bot+sashiko@kernel.org
To: rkannoth@marvell.com
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, andrew+netdev@lunn.ch, ast@kernel.org,
daniel@iogearbox.net, davem@davemloft.net, edumazet@google.com,
hawk@kernel.org, horms@kernel.org, jhs@mojatatu.com,
jiri@resnulli.us, john.fastabend@gmail.com, kuba@kernel.org,
pabeni@redhat.com, sdf@fomichev.me, sgoutham@marvell.com
Subject: Re: [v10,net-next,1/2] net/sched: mqprio: pass qdisc handle to offload drivers
Date: Thu, 03 Sep 2026 19:15:00 +0000 [thread overview]
Message-ID: <178846290039.3394541.11839642753647294558@kernel.org> (raw)
In-Reply-To: <20260831131014.2639581-2-rkannoth@marvell.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 0 · Low: 2
- [Low] Concern that the new `u32 handle` member of `struct
tc_mqprio_qopt_offload` (include/net/pkt_sched.h:168) is added with no…
- [Low] The new `handle` member of `struct tc_mqprio_qopt_offload` is
populated by only one of the two in-tree producers of that structure.
--
net/sched: mqprio: pass qdisc handle to offload drivers
This adds a u32 handle member to struct tc_mqprio_qopt_offload and fills it
from sch->handle in both mqprio_enable_offload() and mqprio_disable_offload()
so that offload drivers can tell mqprio setup, teardown and qdisc replace
apart. The second patch in the series consumes the field in the octeontx2
driver.
> diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
> index 90d3e7943b19a..9f8694ecd4363 100644
> --- a/include/net/pkt_sched.h
> +++ b/include/net/pkt_sched.h
> @@ -165,6 +165,7 @@ struct tc_mqprio_caps {
> struct tc_mqprio_qopt_offload {
> /* struct tc_mqprio_qopt must always be the first element */
> struct tc_mqprio_qopt qopt;
> + u32 handle;
[Severity: Low]
This isn't a bug, but could the new member get a short comment describing
its contract, next to the existing "struct tc_mqprio_qopt must always be
the first element" note?
The struct is driver facing and shared, and nothing here states that
handle carries the owning mqprio qdisc handle, that it is never
TC_H_UNSPEC when the command comes from sch_mqprio, or what a value of 0
means for a consumer.
> struct netlink_ext_ack *extack;
> u16 mode;
> u16 shaper;
> diff --git a/net/sched/sch_mqprio.c b/net/sched/sch_mqprio.c
> index 6ced7008ef5c8..adc1393f84eaa 100644
> --- a/net/sched/sch_mqprio.c
> +++ b/net/sched/sch_mqprio.c
> @@ -39,6 +39,7 @@ static int mqprio_enable_offload(struct Qdisc *sch,
> struct net_device *dev = qdisc_dev(sch);
> struct tc_mqprio_qopt_offload mqprio = {
> .qopt = *qopt,
> + .handle = sch->handle,
> .extack = extack,
> };
> int err, i;
[Severity: Low]
Should sch_taprio also fill this field? struct tc_mqprio_qopt_offload is
embedded in struct tc_taprio_qopt_offload, and taprio_enable_offload()
populates the embedded copy member by member:
net/sched/sch_taprio.c:taprio_enable_offload() {
...
offload->cmd = TAPRIO_CMD_REPLACE;
offload->extack = extack;
mqprio_qopt_reconstruct(dev, &offload->mqprio.qopt);
offload->mqprio.extack = extack;
taprio_sched_to_offload(dev, sched, offload, &caps);
mqprio_fp_to_offload(q->fp, &offload->mqprio);
...
}
The object comes from the kzalloc in taprio_offload_alloc(), so
offload->mqprio.handle stays 0 (TC_H_UNSPEC), which is a value the
sch_mqprio path never produces.
Several drivers feed that embedded sub-struct into the same handler they
use for TC_SETUP_QDISC_MQPRIO:
felix_vsc9959.c vsc9959_qos_port_tas_set() -> ocelot_port_mqprio()
enetc_qos.c enetc_setup_tc_taprio() -> enetc_setup_tc_mqprio()
am65-cpsw-qos.c am65_cpsw_setup_taprio() -> am65_cpsw_setup_mqprio()
am65_cpsw_setup_mqprio() memcpy-caches the whole struct, so it would cache
handle == 0 on the taprio path and a real handle on the mqprio path for the
same hardware state.
No current consumer is affected: the only reader added by this series is
octeontx2, and otx2_setup_tc() handles TC_QUERY_CAPS, TC_SETUP_BLOCK,
TC_SETUP_QDISC_HTB, TC_SETUP_QDISC_MQPRIO and TC_SETUP_ROOT_QDISC only, so
it never sees a taprio-produced struct.
Would it be better to set offload->mqprio.handle from sch->handle in
taprio_enable_offload() as well, or to document in pkt_sched.h that the
field is only meaningful for TC_SETUP_QDISC_MQPRIO issued by sch_mqprio,
before drivers start keying committed state off it?
> @@ -79,7 +80,9 @@ static int mqprio_enable_offload(struct Qdisc *sch,
>
> static void mqprio_disable_offload(struct Qdisc *sch)
> {
> - struct tc_mqprio_qopt_offload mqprio = { { 0 } };
> + struct tc_mqprio_qopt_offload mqprio = {
> + .handle = sch->handle,
> + };
> struct mqprio_sched *priv = qdisc_priv(sch);
> struct net_device *dev = qdisc_dev(sch);
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260831131014.2639581-1-rkannoth%40marvell.com
next prev parent reply other threads:[~2026-09-03 19:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 13:10 [PATCH v10 net-next 0/2] octeontx2-pf: mqprio bandwidth offload for NIX TX schedulers Ratheesh Kannoth
2026-08-31 13:10 ` [PATCH v10 net-next 1/2] net/sched: mqprio: pass qdisc handle to offload drivers Ratheesh Kannoth
2026-09-03 19:15 ` netdev-bot+sashiko [this message]
2026-08-31 13:10 ` [PATCH v10 net-next 2/2] octeontx2-pf: add mqprio bandwidth offload for NIX TX schedulers Ratheesh Kannoth
2026-09-01 13:11 ` sashiko-bot
2026-09-03 19:15 ` [v10,net-next,2/2] " netdev-bot+sashiko
2026-09-02 1:39 ` [PATCH v10 net-next 0/2] octeontx2-pf: " Ratheesh Kannoth
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=178846290039.3394541.11839642753647294558@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rkannoth@marvell.com \
--cc=sdf@fomichev.me \
--cc=sgoutham@marvell.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