From: Jakub Kicinski <kuba@kernel.org>
To: Cosmin Ratiu <cratiu@nvidia.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"horms@kernel.org" <horms@kernel.org>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
Tariq Toukan <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
"jiri@resnulli.us" <jiri@resnulli.us>,
Leon Romanovsky <leonro@nvidia.com>,
"edumazet@google.com" <edumazet@google.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Carolina Jubran <cjubran@nvidia.com>,
"pabeni@redhat.com" <pabeni@redhat.com>
Subject: Re: net-shapers plan
Date: Fri, 28 Mar 2025 05:13:50 -0700 [thread overview]
Message-ID: <20250328051350.5055efe9@kernel.org> (raw)
In-Reply-To: <d9831d0c940a7b77419abe7c7330e822bbfd1cfb.camel@nvidia.com>
On Thu, 6 Mar 2025 14:03:54 +0000 Cosmin Ratiu wrote:
> It is not important which entity (kernel or hw) classifies packets as
> long as the condition that a given txq only sends traffic for a single
> traffic class holds.
> Furthermore, this cannot be done by simply grouping txqs for a given TC
> with NET_SHAPER_SCOPE_NODE, because the TC for a txq is not always
> known to the kernel and might only be known to the driver or the NIC.
> With the new roots, net-shapers can relay the intent to shape traffic
> for a particular TC to the driver without having knowledge of which
> txqs service a TC. The association between txqs and TCs they service
> doesn't need to be known to the kernel.
As mentioned in Zagreb the part of HW reclassifying traffic does not
make sense to me. Is this a real user scenario you have or more of
an attempt to "maximize flexibility"?
next prev parent reply other threads:[~2025-03-28 12:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 14:03 net-shapers plan Cosmin Ratiu
2025-03-11 1:42 ` Samudrala, Sridhar
2025-03-12 11:02 ` Carolina Jubran
2025-03-11 13:38 ` Jiri Pirko
2025-03-26 15:55 ` Cosmin Ratiu
2025-03-28 12:13 ` Jakub Kicinski [this message]
2025-04-01 8:35 ` Carolina Jubran
2025-04-01 14:50 ` Jakub Kicinski
2025-04-08 14:43 ` Carolina Jubran
2025-04-09 22:06 ` Jakub Kicinski
2025-04-10 15:23 ` Carolina Jubran
2025-04-10 23:16 ` Jakub Kicinski
2025-04-14 8:27 ` Carolina Jubran
2025-04-14 16:27 ` Jakub Kicinski
2025-04-23 6:50 ` Carolina Jubran
2025-04-30 12:12 ` Carolina Jubran
2026-05-13 20:53 ` plan Dave Ertman
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=20250328051350.5055efe9@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=cjubran@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=leonro@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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.