DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "skori@marvell.com" <skori@marvell.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	Ray Kinsella <mdr@ashroe.eu>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>
Subject: RE: [PATCH v3 1/1] ethdev: mtr: support input color selection
Date: Tue, 1 Mar 2022 17:48:19 +0000	[thread overview]
Message-ID: <DM8PR11MB56708EA1BAF7C5BF82281F57EB029@DM8PR11MB5670.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220301085824.1041009-1-skori@marvell.com>

HI Jerin,

Thanks for your patch! I think we are making great progress, here are a few more comments: 

<snip>

> +/**
> + * Input color method
> + */
> +enum rte_mtr_input_color_method {

We should clean up the names of these methods a bit: we should not mix header names (VLAN, IP) with header field names (DSCP, PCP), in the sense that to me METHOD_VLAN_DSCP should be replaced with either:
* METHOD_OUTER_VLAN_IP :shorter name, as only the headers are mentioned (my preference, but I am OK with both)
* METHOD_OUTER_VLAN_PCP_IP_DSCP: longer name, as both the headers and the header fields are mentioned

Please put a blank line in between these methods to better readability.

I see some issues in the list of methods below, I am trying to do my best to catch them all:

> +	/**
> +	 * The input color is always green.
> +	 * The default_input_color is ignored for this method.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_COLOR_BLIND  = RTE_BIT64(0),

OK.

> +	/**
> +	 * If the input packet has at least one VLAN label, its input color is
> +	 * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> +	 * indexing into the struct rte_mtr_params::vlan_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::vlan_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_VLAN = RTE_BIT64(1),

OK.
Does your HW use PCP+DEI , or just PCP?

> +	/**
> +	 * If the input packet is IPv4 or IPv6, its input color is detected by
> +	 * the outermost DSCP field indexing into the
> +	 * struct rte_mtr_params::dscp_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::dscp_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_DSCP = RTE_BIT64(2),

OK.
Please change name to METHOD_IP.
Description: Change the "outermost DSCP" to "the DSCP field of the outermost IP header".
I would move this up on the second position (to follow immediately after the color blind method).

> +	/**
> +	 * If the input packet has at least one VLAN label, its input color is
> +	 * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> +	 * indexing into the struct rte_mtr_params::vlan_table.
> +	 * If the input packet is IPv4 or IPv6, its input color is detected by
> +	 * the outermost DSCP field indexing into the
> +	 * struct rte_mtr_params::dscp_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::vlan_table
> +	 * @see struct rte_mtr_params::dscp_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_VLAN_DSCP = RTE_BIT64(3),

OK.
Please change name to METHOD_VLAN_IP.
This should follow immediately after the METHOD_VLAN.
Description: please use "Otherwise" before "if the input packet is IP"; please replace "outermost DSCP" as above.
Is your HW using DEI + PCP or just PCP?

> +	/**
> +	 * If the input packet has at least one VLAN label, its input color is
> +	 * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> +	 * indexing into the struct rte_mtr_params::vlan_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::vlan_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN = RTE_BIT64(4),

OK.
Is your HW using DEI + PCP or just PCP?

> +	/**
> +	 * If the input packet is IPv4 or IPv6, its input color is detected by
> +	 * the innermost DSCP field indexing into the
> +	 * struct rte_mtr_params::dscp_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::dscp_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_INNER_DSCP = RTE_BIT64(5),

This is very confusing to me, I don't get what this one is about: The "inner" word in the name suggests that inner VLAN is attempted first, then IP DSCP (if no VLAN is present), but the description only talks about IP.

> +	/**
> +	 * If the input packet has at least one VLAN label, its input color is
> +	 * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> +	 * indexing into the struct rte_mtr_params::vlan_table.
> +	 * If the input packet is IPv4 or IPv6, its input color is detected by
> +	 * the innermost DSCP field indexing into the
> +	 * struct rte_mtr_params::dscp_table.
> +	 * Otherwise, the default_input_color is applied.
> +	 * @see struct rte_mtr_params::default_input_color
> +	 * @see struct rte_mtr_params::vlan_table
> +	 * @see struct rte_mtr_params::dscp_table
> +	 */
> +	RTE_MTR_INPUT_COLOR_METHOD_INNER_VLAN_DSCP =
> RTE_BIT64(6),

OK.
Description fixes: Use "otherwise" before "if IP"; replace innermost DSCP with "DSCP field of the outermost IP header".

<snip>

Regards,
Cristian

  parent reply	other threads:[~2022-03-01 17:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20  8:24 [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features jerinj
2021-08-30  9:23 ` Jerin Jacob
2021-09-27 16:20   ` Ferruh Yigit
2021-10-11 15:14 ` Dumitrescu, Cristian
2021-11-17 12:00   ` Jerin Jacob
2021-12-07  9:55     ` Jerin Jacob
2021-12-07 18:00       ` Dumitrescu, Cristian
2022-01-10  9:35         ` Jerin Jacob
2022-02-14 11:56 ` [dpdk-dev] [v22.07] [PATCH] ethdev: mtr: support input color selection jerinj
2022-02-14 12:02   ` [dpdk-dev] [v22.07] [PATCH v2] " jerinj
2022-03-01  8:58     ` [PATCH v3 1/1] " skori
2022-03-01 10:49       ` [EXT] " Sunil Kumar Kori
2022-03-01 17:48       ` Dumitrescu, Cristian [this message]
2022-04-05 21:14         ` Dumitrescu, Cristian
2022-04-07 10:51         ` Jerin Jacob
2022-04-07 13:25           ` Dumitrescu, Cristian
2022-04-07 14:39             ` Jerin Jacob
2022-04-11 14:45               ` Dumitrescu, Cristian
2022-04-12  6:48                 ` Ori Kam
2022-04-21 18:02       ` [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based " jerinj
2022-04-26 10:19         ` Ray Kinsella
2022-05-01 12:52           ` Jerin Jacob
2022-04-26 12:08         ` Dumitrescu, Cristian
2022-05-01 12:56           ` Jerin Jacob
2022-05-01 14:46         ` [dpdk-dev] [PATCH v5] " jerinj
2022-05-04  8:52           ` Ray Kinsella
2022-05-05 10:56           ` Dumitrescu, Cristian
2022-05-12  7:36           ` Andrew Rybchenko
2022-05-12 11:03             ` Jerin Jacob
2022-05-19  7:05               ` Andrew Rybchenko

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=DM8PR11MB56708EA1BAF7C5BF82281F57EB029@DM8PR11MB5670.namprd11.prod.outlook.com \
    --to=cristian.dumitrescu@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=mdr@ashroe.eu \
    --cc=skori@marvell.com \
    --cc=thomas@monjalon.net \
    /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).