DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Ori Kam <orika@nvidia.com>
Cc: Jerin Jacob <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>,
	 "NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	 Andrew Boyer <aboyer@pensando.io>,
	Beilei Xing <beilei.xing@intel.com>,
	 "Richardson, Bruce" <bruce.richardson@intel.com>,
	Chas Williams <chas3@att.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>,
	Ciara Loftus <ciara.loftus@intel.com>,
	 Devendra Singh Rawat <dsinghrawat@marvell.com>,
	Ed Czeck <ed.czeck@atomicrules.com>,
	 Evgeny Schemeilin <evgenys@amazon.com>,
	Gaetan Rivet <grive@u256.net>, Gagandeep Singh <g.singh@nxp.com>,
	 Guoyang Zhou <zhouguoyang@huawei.com>,
	Haiyue Wang <haiyue.wang@intel.com>,
	 Harman Kalra <hkalra@marvell.com>,
	 "heinrich.kuhn@corigine.com" <heinrich.kuhn@corigine.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	 Hyong Youb Kim <hyonkim@cisco.com>,
	Igor Chauskin <igorch@amazon.com>,
	 Igor Russkikh <irusskikh@marvell.com>,
	Jakub Grajciar <jgrajcia@cisco.com>,
	 Jasvinder Singh <jasvinder.singh@intel.com>,
	Jian Wang <jianwang@trustnetic.com>,
	 Jiawen Wu <jiawenwu@trustnetic.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	 John Daley <johndale@cisco.com>,
	John Miller <john.miller@atomicrules.com>,
	 "John W. Linville" <linville@tuxdriver.com>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	 Kiran Kumar K <kirankumark@marvell.com>,
	Lijun Ou <oulijun@huawei.com>,  Liron Himi <lironh@marvell.com>,
	"NBU-Contact-longli (EXTERNAL)" <longli@microsoft.com>,
	 Marcin Wojtas <mw@semihalf.com>,
	Martin Spinler <spinler@cesnet.cz>,
	Matan Azrad <matan@nvidia.com>,
	Matt Peters <matt.peters@windriver.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	 Michal Krawczyk <mk@semihalf.com>,
	"Min Hu (Connor" <humin29@huawei.com>,
	 Pradeep Kumar Nalla <pnalla@marvell.com>,
	Nithin Dabilpuram <ndabilpuram@marvell.com>,
	 Qiming Yang <qiming.yang@intel.com>,
	Qi Zhang <qi.z.zhang@intel.com>,
	 Radha Mohan Chintakuntla <radhac@marvell.com>,
	Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
	 Rasesh Mody <rmody@marvell.com>, Rosen Xu <rosen.xu@intel.com>,
	 Sachin Saxena <sachin.saxena@oss.nxp.com>,
	 Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>,
	Shahed Shaikh <shshaikh@marvell.com>,
	Shai Brandes <shaibran@amazon.com>,
	Shepard Siegel <shepard.siegel@atomicrules.com>,
	 Somalapuram Amaranath <asomalap@amd.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	 Stephen Hemminger <sthemmin@microsoft.com>,
	Steven Webster <steven.webster@windriver.com>,
	 Sunil Kumar Kori <skori@marvell.com>,
	Tetsuya Mukawa <mtetsuyah@gmail.com>,
	 Veerasenareddy Burru <vburru@marvell.com>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	 Xiao Wang <xiao.w.wang@intel.com>,
	Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>,
	Yisen Zhuang <yisen.zhuang@huawei.com>,
	Yong Wang <yongwang@vmware.com>,
	 Ziyang Xuan <xuanziyang2@huawei.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: support priority based flow control
Date: Wed, 24 Nov 2021 16:18:22 +0530	[thread overview]
Message-ID: <CALBAE1OcZe071oYR4_MPBpada2TPn+tv5Ox3zHkAAVRaWP14Cg@mail.gmail.com> (raw)
In-Reply-To: <DM8PR12MB54005203A1CE15E9B9A1C9CDD6619@DM8PR12MB5400.namprd12.prod.outlook.com>

On Wed, Nov 24, 2021 at 3:01 PM Ori Kam <orika@nvidia.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, November 23, 2021 12:58 PM
> > To: Ori Kam <orika@nvidia.com>
> >
> > On Sun, Nov 21, 2021 at 3:20 PM Ori Kam <orika@nvidia.com> wrote:
> > >
> > > Hi Jerin,
> >
> > Hi Ori,
> >
> > >
> > > Sorry for my late response,
> >
> > Thanks for the review.
> >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, November 17, 2021 11:49 AM
> > > > To: Jerin Jacob <jerinj@marvell.com>
> > > > Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: support priority based flow control
> > > >
> > > > On Tue, Oct 5, 2021 at 6:32 PM <jerinj@marvell.com> wrote:
> > > > >
> > > > > From: Jerin Jacob <jerinj@marvell.com>
> > > > >
> > > > > rte_eth_dev_priority_flow_ctrl_set() based API is not generic as it
> > > > > can not support other than VLAN priority mapping to PFC traffic class.
> > > > >
> > > > > Introducing RTE_FLOW_ACTION_TYPE_PFC_SET_TC rte_flow action to
> > > > > set the traffic class as per 802.1Qbb specification. This will enable,
> > > > > Traffic class(8bit) to be selected based on any packet field like DSCP.
> > > > >
> > > > > Also, making it as rte_flow action will enable fine control on
> > > > > traffic class selection to a specific queue or VF etc.
> > > > >
> > > > > Signed-off-by: Jerin Jacob <jerinj@marvell.com>
> > > >
> > > > Ping. If there are no comments on RFC, Planning to send v1 for 22.02.
> > >
> > > All the set type of functions are going to be deprecated.
> > > you should use RTE_FLOW_ACTION_TYPE_MODIFY_FIELD.
> > >
> > > What is the item that you are matching on when using rte_flow? Is it part of the tci in the vlan item?
> >
> > TC can be VLAN TCI field or DSCP field in IP header or any other field
> > in packet.
> > We need to set the traffic class as per 802.1Qbb specification, May I
> > know how the "modify"
> > attribute helps here. It should be a "set" operation. Right?
> >
>
> Yes, in the rte_flow_action_modify_field there is what operation you want to do,
> in this case the action should be set.

But RTE_FLOW_ACTION_TYPE_MODIFY_FIELD used for modify the packet
content[1]. RIght?
In this case, it is more of sideband data not anything on packet
content. If so, explicit action
makes sense. Right?


[1]
 * RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
 *
 * Modify a destination header field according to the specified
 * operation. Another field of the packet can be used as a source as well
 * as tag, mark, metadata, immediate value or a pointer to it.

>
> I assume that you are trying to set the VLAN tag priority field right?

Both VLAN tag and/or DSCP field.


>
> >
> >
> > >
> > >
> > > >
> > > > > ---
> > > > >
> > > > > Planning to submit the testpmd and cnxk ethdev driver changes after receiving
> > > > > the feedback on this.
> > > > >
> > > > >
> > > > >  doc/guides/prog_guide/rte_flow.rst | 24 ++++++++++++++++++++++++
> > > > >  lib/ethdev/rte_flow.c              |  1 +
> > > > >  lib/ethdev/rte_flow.h              | 27 +++++++++++++++++++++++++++
> > > > >  3 files changed, 52 insertions(+)
> > > > >
> > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> > > > > index 2b42d5ec8c..e59f8a2902 100644
> > > > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > > > @@ -2999,6 +2999,30 @@ which is set in the packet meta-data (i.e. struct
> > ``rte_mbuf::sched::color``)
> > > > >     | ``meter_color`` | Packet color |
> > > > >     +-----------------+--------------+
> > > > >
> > > > > +Action: ``PFC_SET_TC``
> > > > > +^^^^^^^^^^^^^^^^^^^^^^
> > > > > +
> > > > > +Set traffic class as per PFC (802.1Qbb) specification.
> > > > > +
> > > > > +This action must be used with any of the following action.
> > > > > +
> > > > > +- ``RTE_FLOW_ACTION_TYPE_QUEUE``
> > > > > +- ``RTE_FLOW_ACTION_TYPE_RSS``
> > > > > +- ``RTE_FLOW_ACTION_TYPE_PF``
> > > > > +- ``RTE_FLOW_ACTION_TYPE_VF``
> > > > > +- ``RTE_FLOW_ACTION_TYPE_PHY_PORT``
> > > > > +- ``RTE_FLOW_ACTION_TYPE_PORT_ID``
> > > > > +
> > >
> > > Why? All the above actions are terminating actions so if I want ot match on the value
> > > it doesn't make sense to have it only on the last rule.
> >
> > In PFC, we are specifying, Given TC needs to steer to specific Queue,
> > RSS, PF etc.
> > Not sure how other actions are relevant for SET_TC action. Do you have any
> > specific action in mind where SET_TC valid in addition to above actions
> >
> First what happens in case of egress traffic? There is no dest action.

It will be invalid. I can change the documentation to specify egress
direction is not valid.
Thoughts?

> Second what happens if for example the priority is based on the outer tunnel
> which I want decap and at a latter stage I want to do connection tracking and only
> if everything is correct I want to send this packet to a queue?

Which is fine with the current scheme of things as per the documentation,
"This action must be used with any of the following action." it does
not preclude to
use of any other action. If it is not clear, we can reword like below,
---
This action must be used with any of the following action and not limited to
using any of other actions in conjunction with the following action.
---
Thoughts?

>
> >
> >
> > >
> > > > > +.. _table_rte_flow_action_pfc_set_tc:
> > > > > +
> > > > > +.. table:: PFC_SET_PRIORITY
> > > > > +
> > > > > +   +-----------------+-------------------------------------+
> > > > > +   | Field           | Value                               |
> > > > > +   +=================+=====================================+
> > > > > +   | ``tc``          | Traffic class as per PFC (802.1Qbb) |
> > > > > +   +-----------------+-------------------------------------+
> > > > > +
> > > > >  Negative types
> > > > >  ~~~~~~~~~~~~~~
> > > > >
> > > > > diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> > > > > index 8cb7a069c8..75c661159e 100644
> > > > > --- a/lib/ethdev/rte_flow.c
> > > > > +++ b/lib/ethdev/rte_flow.c
> > > > > @@ -189,6 +189,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
> > > > >          */
> > > > >         MK_FLOW_ACTION(INDIRECT, 0),
> > > > >         MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
> > > > > +       MK_FLOW_ACTION(PFC_SET_TC, sizeof(struct rte_flow_action_pfc_set_tc)),
> > > > >  };
> > > > >
> > > > >  int
> > > > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> > > > > index 7b1ed7f110..5298418e9e 100644
> > > > > --- a/lib/ethdev/rte_flow.h
> > > > > +++ b/lib/ethdev/rte_flow.h
> > > > > @@ -2409,6 +2409,13 @@ enum rte_flow_action_type {
> > > > >          * See struct rte_flow_action_meter_color.
> > > > >          */
> > > > >         RTE_FLOW_ACTION_TYPE_METER_COLOR,
> > > > > +
> > > > > +       /**
> > > > > +        * Set traffic class as per PFC (802.1Qbb) specification.
> > > > > +        *
> > > > > +        * See struct rte_flow_action_pfc_set_tc.
> > > > > +        */
> > > > > +       RTE_FLOW_ACTION_TYPE_PFC_SET_TC,
> > > > >  };
> > > > >
> > > > >  /**
> > > > > @@ -3168,6 +3175,26 @@ struct rte_flow_action_meter_color {
> > > > >         enum rte_color color; /**< Packet color. */
> > > > >  };
> > > > >
> > > > > +/**
> > > > > + * @warning
> > > > > + * @b EXPERIMENTAL: this structure may change without prior notice
> > > > > + *
> > > > > + * RTE_FLOW_ACTION_TYPE_PFC_SET_TC
> > > > > + *
> > > > > + * Set traffic class as per PFC (802.1Qbb) specification.
> > > > > + *
> > > > > + * This action must be used any of the following action.
> > > > > + * - RTE_FLOW_ACTION_TYPE_QUEUE,
> > > > > + * - RTE_FLOW_ACTION_TYPE_RSS,
> > > > > + * - RTE_FLOW_ACTION_TYPE_PF,
> > > > > + * - RTE_FLOW_ACTION_TYPE_VF,
> > > > > + * - RTE_FLOW_ACTION_TYPE_PHY_PORT,
> > > > > + * - RTE_FLOW_ACTION_TYPE_PORT_ID
> > > > > + */
> > >
> > > What does it mean?  I must use it only on rules that have one of the above actions?
> >
> > See above.
> >
> > >
> > > > > +struct rte_flow_action_pfc_set_tc {
> > > > > +       uint8_t tc; /**< Traffic class as per PFC (802.1Qbb) specification */
> > > > > +};
> > > > > +
> > > > >  /**
> > > > >   * Field IDs for MODIFY_FIELD action.
> > > > >   */
> > > > > --
> > > > > 2.33.0
> > > > >
> > >
> > > Best,
> > > Ori

  reply	other threads:[~2021-11-24 10:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 12:59 jerinj
2021-11-17  9:48 ` Jerin Jacob
2021-11-21  9:50   ` Ori Kam
2021-11-23 10:58     ` Jerin Jacob
2021-11-23 19:07       ` Ajit Khaparde
2021-11-24  9:31       ` Ori Kam
2021-11-24 10:48         ` Jerin Jacob [this message]
2021-11-24 16:00           ` Ori Kam
2021-11-25 11:12             ` Jerin Jacob
2021-11-25 14:02               ` Ori Kam
2021-11-26  6:46                 ` Jerin Jacob
2021-11-28 11:31                   ` Ori Kam
2021-11-28 11:37                     ` Jerin Jacob
2021-11-29 14:54                       ` Jerin Jacob
2021-12-04 17:30                         ` Jerin Jacob

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=CALBAE1OcZe071oYR4_MPBpada2TPn+tv5Ox3zHkAAVRaWP14Cg@mail.gmail.com \
    --to=jerinjacobk@gmail.com \
    --cc=aboyer@pensando.io \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=asomalap@amd.com \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=chas3@att.com \
    --cc=chenbo.xia@intel.com \
    --cc=ciara.loftus@intel.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=dev@dpdk.org \
    --cc=dsinghrawat@marvell.com \
    --cc=ed.czeck@atomicrules.com \
    --cc=evgenys@amazon.com \
    --cc=ferruh.yigit@intel.com \
    --cc=g.singh@nxp.com \
    --cc=grive@u256.net \
    --cc=haiyue.wang@intel.com \
    --cc=heinrich.kuhn@corigine.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hkalra@marvell.com \
    --cc=humin29@huawei.com \
    --cc=hyonkim@cisco.com \
    --cc=igorch@amazon.com \
    --cc=irusskikh@marvell.com \
    --cc=jasvinder.singh@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jgrajcia@cisco.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jingjing.wu@intel.com \
    --cc=john.miller@atomicrules.com \
    --cc=johndale@cisco.com \
    --cc=keith.wiles@intel.com \
    --cc=kirankumark@marvell.com \
    --cc=linville@tuxdriver.com \
    --cc=lironh@marvell.com \
    --cc=longli@microsoft.com \
    --cc=matan@nvidia.com \
    --cc=matt.peters@windriver.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mk@semihalf.com \
    --cc=mtetsuyah@gmail.com \
    --cc=mw@semihalf.com \
    --cc=ndabilpuram@marvell.com \
    --cc=orika@nvidia.com \
    --cc=oulijun@huawei.com \
    --cc=pnalla@marvell.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=radhac@marvell.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=rmody@marvell.com \
    --cc=rosen.xu@intel.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=shaibran@amazon.com \
    --cc=shepard.siegel@atomicrules.com \
    --cc=shshaikh@marvell.com \
    --cc=skori@marvell.com \
    --cc=skoteshwar@marvell.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=spinler@cesnet.cz \
    --cc=steven.webster@windriver.com \
    --cc=sthemmin@microsoft.com \
    --cc=thomas@monjalon.net \
    --cc=vburru@marvell.com \
    --cc=viacheslavo@nvidia.com \
    --cc=xiao.w.wang@intel.com \
    --cc=xuanziyang2@huawei.com \
    --cc=yisen.zhuang@huawei.com \
    --cc=yongwang@vmware.com \
    --cc=zhouguoyang@huawei.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).