All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Ratheesh Kannoth <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>,
	<john.fastabend@gmail.com>, <pabeni@redhat.com>,
	<sdf@fomichev.me>, <sgoutham@marvell.com>
Subject: Re: [PATCH v18 net-next 0/2] octeontx2: mqprio bandwidth offload for NIX TX schedulers
Date: Thu, 1 Oct 2026 18:22:48 -0700	[thread overview]
Message-ID: <20261001182248.376c1b01@kernel.org> (raw)
In-Reply-To: <20260929022915.2704627-1-rkannoth@marvell.com>

On Tue, 29 Sep 2026 07:59:13 +0530 Ratheesh Kannoth wrote:
> This series adds hardware offload for channel-mode mqprio with
> TC_MQPRIO_SHAPER_BW_RATE on Marvell octeontx2/cn10k PF and VF RVU
> netdevices. Each non-QoS transmit queue is shaped by programming MDQ CIR/PIR
> on the NIX TX scheduler. When bandwidth offload is active, the driver
> allocates one SMQ per queue, parents every MDQ under TL4[0], and maps each
> traffic class min/max rate to the queue(s) in that class.
> 
> The NIX TX scheduler hierarchy cannot be reprogrammed live today, so
> mqprio add, replace, delete, and failed-replace rollback rebuild it by
> bouncing the netdev through ndo_stop()/ndo_open(). That intentionally
> drops in-flight traffic on each change. otx2_mqprio_restart_netdev() clears
> __LINK_STATE_START before ndo_stop() and does not call
> dev_deactivate()/dev_activate(); carrier and TX queues are restored after
> ndo_open() via the normal link-event path when the link is up. Cache the
> active rates and restore MDQ shapers from otx2_mqprio_up() during ndo_open();
> fail closed if restoration fails, leaving ndo_open() unsuccessful and the
> interface administratively down.
> 
> Track mqprio configuration in mq_offload_snap snapshots (TC layout and
> rates). On tc qdisc replace, stage the new configuration while keeping
> the previous snapshot for rollback: failed setup restores the old
> snapshot via netdev restart when the interface is running, successful
> graft is recorded through TC_ROOT_GRAFT, and teardown of the replaced
> qdisc instance commits the staged snapshot without tearing down the live
> offload.
> 
> Patch 1 converts PF/VF and representor flag access to atomic bitops.
> Patch 2 depends on it for safe OTX2_FLAG_INTF_DOWN and OTX2_FLAG_PORT_UP
> updates on asynchronous mbox paths and during the mqprio netdev bounce.
> 
> The driver rejects offload unless the interface is running and the device
> advertises CIR+PIR support. PF and VF RVU netdevices share the same TC
> offload path via ndo_setup_tc / otx2_open(); SDP representors are not
> supported. Per-TC rates are rejected when a traffic class spans more than
> one queue. Concurrent PFC, XDP, SDP rep, or HTB use is blocked, and ethtool
> channel count changes are blocked while mqprio bandwidth offload is active.

coccicheck

drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c:2182:7-74: WARNING avoid newline at end of message in NL_SET_ERR_MSG_MOD

Obviously please still wait for the AI feedback before sending v19
-- 
pw-bot: cr

  parent reply	other threads:[~2026-10-02  1:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29  2:29 [PATCH v18 net-next 0/2] octeontx2: mqprio bandwidth offload for NIX TX schedulers Ratheesh Kannoth
2026-09-29  2:29 ` [PATCH v18 net-next 1/2] octeontx2: use atomic bitops for PF/VF and rep flags Ratheesh Kannoth
2026-09-30  2:30   ` sashiko-bot
2026-10-02  8:31   ` netdev-bot+sashiko
2026-10-05  4:16     ` Ratheesh Kannoth
2026-09-29  2:29 ` [PATCH v18 net-next 2/2] octeontx2: add mqprio bandwidth offload for NIX TX schedulers Ratheesh Kannoth
2026-09-30  2:30   ` sashiko-bot
2026-10-02  8:31   ` netdev-bot+sashiko
2026-10-02  1:22 ` Jakub Kicinski [this message]
2026-10-02  9:37 ` [PATCH v18 net-next 0/2] octeontx2: " David Laight
2026-10-05  2:58   ` Ratheesh Kannoth
2026-10-05  8:14     ` David Laight
2026-10-05  9:49       ` 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=20261001182248.376c1b01@kernel.org \
    --to=kuba@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=john.fastabend@gmail.com \
    --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 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.