netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: <Daniel.Machon@microchip.com>
Cc: <vladimir.oltean@nxp.com>, <Allan.Nielsen@microchip.com>,
	<kuba@kernel.org>, <petrm@nvidia.com>, <netdev@vger.kernel.org>,
	<vinicius.gomes@intel.com>, <thomas.petazzoni@bootlin.com>,
	<maxime.chevallier@bootlin.com>, <roopa@nvidia.com>
Subject: Re: Basic PCP/DEI-based queue classification
Date: Thu, 8 Sep 2022 13:18:17 +0200	[thread overview]
Message-ID: <871qsmf6rk.fsf@nvidia.com> (raw)
In-Reply-To: <Yxj5smlnHEMn0sq2@DEN-LT-70577>


<Daniel.Machon@microchip.com> writes:

>> On Wed, Sep 07, 2022 at 10:41:10AM +0000, Daniel.Machon@microchip.com wrote:
>> > > Regarding the topic at hand, and the apparent lack of PCP-based
>> > > prioritization in the software data path. VLAN devices have an
>> > > ingress-qos-map and an egress-qos-map. How would prioritization done via
>> > > dcbnl interact with those (who would take precedence)?
>> >
>> > Hi Vladimir,
>> >
>> > They shouldn't interact (at least this is my understanding).
>> >
>> > The ingress and egress maps are for vlan interfaces, and dcb operates
>> > on physical interfaces (dcbx too). You cannot use dcbnl to do
>> > prioritization for vlan interfaces.
>> >
>> > Anyway, I think much of the stuff in DCB is for hw offload only, incl. the
>> > topic at hand. Is the APP table even consulted by the sw stack at all - I
>> > dont think so (apart from drivers).
>> 
>> Not directly, but at least ocelot (or in fact felix) does set
>> skb->priority based on the QoS class from the Extraction Frame Header.
>> So the stack does end up consulting and meaningfully using something
>> that was set based on the dcbnl APP table.
>> 
>> In this sense, for ocelot, there is a real overlap between skb->priority
>> being initially set based on ocelot_xfh_get_qos_class(), and later being
>> overwritten based on the QoS maps of a VLAN interface.
>
> Right, so VLAN QoS maps currently takes precedence, if somebody would choose
> to add a tagged vlan interface on-top of a physical interface with existing
> PCP prioritization - is this a real problem, or just a question of configuration?

We have the same deal going on with TC BTW. Whatever prioritization is
transferred from HW to SW is lost when the packet is passed through the
SW TC rules.

And at least on Spectrum, we don't even have a way to transfer the
priority to SW, as far as I know. So in this sense it's exactly like
DCB, where the in-HW prioritization is completely separate from the SW
one. Except that all DCB APP rules are "skip_sw" and can't not be.

  parent reply	other threads:[~2022-09-08 11:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  9:09 Basic PCP/DEI-based queue classification Daniel.Machon
2022-08-19 10:50 ` Petr Machata
2022-08-21 20:58   ` Daniel.Machon
2022-08-22 10:34     ` Petr Machata
2022-08-24  7:39       ` Daniel.Machon
2022-08-24  9:45         ` Petr Machata
2022-08-24 17:55           ` Daniel.Machon
2022-08-24 19:36             ` Petr Machata
2022-08-25  0:54               ` Jakub Kicinski
2022-08-26 18:11                 ` Petr Machata
2022-08-29  7:53                 ` Allan W. Nielsen
2022-09-02 13:32                   ` Vladimir Oltean
2022-09-07 10:41                     ` Daniel.Machon
2022-09-07 17:26                       ` Vladimir Oltean
2022-09-07 19:57                         ` Daniel.Machon
2022-09-08  8:03                           ` Allan Nielsen - M31684
2022-09-08 11:18                           ` Petr Machata [this message]
2022-09-08 12:01                             ` Daniel.Machon
2022-09-09 12:11                           ` Vladimir Oltean
2022-09-08  8:27                         ` Petr Machata
2022-08-25 11:31               ` Daniel.Machon
2022-08-25 13:30                 ` Petr Machata

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=871qsmf6rk.fsf@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=Allan.Nielsen@microchip.com \
    --cc=Daniel.Machon@microchip.com \
    --cc=kuba@kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@nvidia.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vladimir.oltean@nxp.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).