All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: Daniel Machon <daniel.machon@microchip.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<lars.povlsen@microchip.com>, <Steen.Hegelund@microchip.com>,
	<UNGLinuxDriver@microchip.com>, <joe@perches.com>,
	<error27@gmail.com>, <horatiu.vultur@microchip.com>,
	<Julia.Lawall@inria.fr>, <petrm@nvidia.com>,
	<vladimir.oltean@nxp.com>, <maxime.chevallier@bootlin.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/6] Introduce new DCB rewrite table
Date: Fri, 13 Jan 2023 17:11:50 +0100	[thread overview]
Message-ID: <87wn5qxu9u.fsf@nvidia.com> (raw)
In-Reply-To: <20230112201554.752144-1-daniel.machon@microchip.com>


Daniel Machon <daniel.machon@microchip.com> writes:

> There is currently no support for per-port egress mapping of priority to PCP and
> priority to DSCP. Some support for expressing egress mapping of PCP is supported
> through ip link, with the 'egress-qos-map', however this command only maps
> priority to PCP, and for vlan interfaces only. DCB APP already has support for
> per-port ingress mapping of PCP/DEI, DSCP and a bunch of other stuff. So why not
> take advantage of this fact, and add a new table that does the reverse.
>
> This patch series introduces the new DCB rewrite table. Whereas the DCB
> APP table deals with ingress mapping of PID (protocol identifier) to priority,
> the rewrite table deals with egress mapping of priority to PID.
>
> It is indeed possible to integrate rewrite in the existing APP table, by
> introducing new dedicated rewrite selectors, and altering existing functions
> to treat rewrite entries specially. However, I feel like this is not a good
> solution, and will pollute the APP namespace. APP is well-defined in IEEE, and
> some userspace relies of advertised entries - for this fact, separating APP and
> rewrite into to completely separate objects, seems to me the best solution.
>
> The new table shares much functionality with the APP table, and as such, much
> existing code is reused, or slightly modified, to work for both.
>
> ================================================================================
> DCB rewrite table in a nutshell
> ================================================================================
> The table is implemented as a simple linked list, and uses the same lock as the
> APP table. New functions for getting, setting and deleting entries have been
> added, and these are exported, so they can be used by the stack or drivers.
> Additionnaly, new dcbnl_setrewr and dcnl_delrewr hooks has been added, to
> support hardware offload of the entries.

Looks good to me overall.

I just want to add that to configure rewrite, mlxsw currently reverses
the APP prioritization table. That's not ideal, and is lossy as
well--certain configurations simply can't be expressed however you set
up in-driver heuristics. The proposed interfaces would make
configuration of the rewrite functionality very straightforward.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Petr Machata <petrm@nvidia.com>
To: Daniel Machon <daniel.machon@microchip.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<lars.povlsen@microchip.com>, <Steen.Hegelund@microchip.com>,
	<UNGLinuxDriver@microchip.com>, <joe@perches.com>,
	<error27@gmail.com>, <horatiu.vultur@microchip.com>,
	<Julia.Lawall@inria.fr>, <petrm@nvidia.com>,
	<vladimir.oltean@nxp.com>, <maxime.chevallier@bootlin.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/6] Introduce new DCB rewrite table
Date: Fri, 13 Jan 2023 17:11:50 +0100	[thread overview]
Message-ID: <87wn5qxu9u.fsf@nvidia.com> (raw)
In-Reply-To: <20230112201554.752144-1-daniel.machon@microchip.com>


Daniel Machon <daniel.machon@microchip.com> writes:

> There is currently no support for per-port egress mapping of priority to PCP and
> priority to DSCP. Some support for expressing egress mapping of PCP is supported
> through ip link, with the 'egress-qos-map', however this command only maps
> priority to PCP, and for vlan interfaces only. DCB APP already has support for
> per-port ingress mapping of PCP/DEI, DSCP and a bunch of other stuff. So why not
> take advantage of this fact, and add a new table that does the reverse.
>
> This patch series introduces the new DCB rewrite table. Whereas the DCB
> APP table deals with ingress mapping of PID (protocol identifier) to priority,
> the rewrite table deals with egress mapping of priority to PID.
>
> It is indeed possible to integrate rewrite in the existing APP table, by
> introducing new dedicated rewrite selectors, and altering existing functions
> to treat rewrite entries specially. However, I feel like this is not a good
> solution, and will pollute the APP namespace. APP is well-defined in IEEE, and
> some userspace relies of advertised entries - for this fact, separating APP and
> rewrite into to completely separate objects, seems to me the best solution.
>
> The new table shares much functionality with the APP table, and as such, much
> existing code is reused, or slightly modified, to work for both.
>
> ================================================================================
> DCB rewrite table in a nutshell
> ================================================================================
> The table is implemented as a simple linked list, and uses the same lock as the
> APP table. New functions for getting, setting and deleting entries have been
> added, and these are exported, so they can be used by the stack or drivers.
> Additionnaly, new dcbnl_setrewr and dcnl_delrewr hooks has been added, to
> support hardware offload of the entries.

Looks good to me overall.

I just want to add that to configure rewrite, mlxsw currently reverses
the APP prioritization table. That's not ideal, and is lossy as
well--certain configurations simply can't be expressed however you set
up in-driver heuristics. The proposed interfaces would make
configuration of the rewrite functionality very straightforward.

  parent reply	other threads:[~2023-01-13 16:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 20:15 [PATCH net-next 0/6] Introduce new DCB rewrite table Daniel Machon
2023-01-12 20:15 ` Daniel Machon
2023-01-12 20:15 ` [PATCH net-next 1/6] net: dcb: modify dcb_app_add to take list_head ptr as parameter Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-12 20:15 ` [PATCH net-next 2/6] net: dcb: add new common function for set/del of app/rewr entries Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-13 14:52   ` Petr Machata
2023-01-13 14:52     ` Petr Machata
2023-01-16 13:00     ` Daniel.Machon
2023-01-16 13:00       ` Daniel.Machon
2023-01-12 20:15 ` [PATCH net-next 3/6] net: dcb: add new rewrite table Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-13  7:04   ` Dan Carpenter
2023-01-13  7:04     ` Dan Carpenter
2023-01-16 12:52     ` Daniel.Machon
2023-01-16 12:52       ` Daniel.Machon
2023-01-13 15:51   ` Petr Machata
2023-01-13 15:51     ` Petr Machata
2023-01-12 20:15 ` [PATCH net-next 4/6] net: dcb: add helper functions to retrieve PCP and DSCP rewrite maps Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-12 20:15 ` [PATCH net-next 5/6] net: microchip: sparx5: add support for PCP rewrite Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-12 20:15 ` [PATCH net-next 6/6] net: microchip: sparx5: add support for DSCP rewrite Daniel Machon
2023-01-12 20:15   ` Daniel Machon
2023-01-13 16:11 ` Petr Machata [this message]
2023-01-13 16:11   ` [PATCH net-next 0/6] Introduce new DCB rewrite table 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=87wn5qxu9u.fsf@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=Julia.Lawall@inria.fr \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=error27@gmail.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=joe@perches.com \
    --cc=kuba@kernel.org \
    --cc=lars.povlsen@microchip.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 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.