DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alexander Kozyrev <akozyrev@nvidia.com>
To: Ori Kam <orika@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Slava Ovsiienko <viacheslavo@nvidia.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [dpdk-dev] [PATCH] ethdev: introduce generic copy rte flow action
Date: Tue, 12 Jan 2021 17:19:58 +0000
Message-ID: <BN7PR12MB270764D57C567E0FF41220A2AFAA0@BN7PR12MB2707.namprd12.prod.outlook.com> (raw)
In-Reply-To: <DM6PR12MB498714083C0992B2C101EBDED6AA0@DM6PR12MB4987.namprd12.prod.outlook.com>

> > From: Ori Kam onTuesday, January 12, 2021 4:53 PM
> > To: Alexander Kozyrev <akozyrev@nvidia.com>; dev@dpdk.org
> > Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Thomas
> Monjalon
> > <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > andrew.rybchenko@oktetlabs.ru
> > Subject: RE: [PATCH] ethdev: introduce generic copy rte flow action
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: Alexander Kozyrev <akozyrev@nvidia.com>
> > > Sent: Tuesday, January 12, 2021 4:16 PM
> > > To: Ori Kam <orika@nvidia.com>; dev@dpdk.org
> > > Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Thomas
> > Monjalon
> > > <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > > andrew.rybchenko@oktetlabs.ru
> > > Subject: RE: [PATCH] ethdev: introduce generic copy rte flow action
> > >
> > > > From: Ori Kam <orika@nvidia.com> on Sunday, January 10, 2021 3:01
> > > > Hi Alexander,
> > > >
> > > > I guess that the test-pmd part will be available later right?
> > > Yes, please take a look at v2 version for testpmd implementation.
> > >
> > > > > -----Original Message-----
> > > > > From: Alexander Kozyrev <akozyrev@nvidia.com>
> > > > > Sent: Friday, January 8, 2021 8:33 AM
> > > > > Subject: [PATCH] ethdev: introduce generic copy rte flow action
> > > > >
> > > > > Implement a generic copy flow API to allow copying of an arbitrary
> > > > > header field (as well as mark, metadata or tag) to another item.
> > > > >
> > > > > This generic copy mechanism removes the necessity to implement a
> > > > > separate RTE Flow action every time we need to modify a new packet
> > > > > field in the future. A user-provided value can be used from a
> > > > > specified tag/metadata or directly copied from other packet field.
> > > > >
> > > > > The number of bits to copy as well as the offset to start from can
> > > > > be specified to allow a partial copy or copy into an arbitrary
> > > > > place in a packet for greater flexibility.
> > > > >
> > > >
> > > > Since the question why you are using enum and not just offset from
> > > > the start of the packet, was discussed and raised by number of people it
> will
> > > be
> > > > best
> > > > if it will appear in the commit log, at least the advantages to this
> > > > implementation.
> > > Ok, will add to v3 commit message.
> > >
> > > > > RFC:
> > > > >
> > > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.
> > > > d
> > > > >
> > > >
> > >
> >
> pdk.org%2Fpatch%2F85384%2F&amp;data=04%7C01%7Corika%40nvidia.com%
> > > > >
> > > >
> > >
> >
> 7Cd04c2e49c3a840994da408d8b39f3304%7C43083d15727340c1b7db39efd9cc
> > > > >
> > > >
> > >
> >
> c17a%7C0%7C0%7C637456843629116269%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > >
> > > >
> > >
> >
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > > >
> > >
> > 1000&amp;sdata=85096rASBtzbjU42pV6sPkl3nVt5HlR6%2BL9nxI3qgFA%3D&a
> > > > > mp;reserved=0
> > > > >
> > > > > Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
> > > > > ---
> > > > >  doc/guides/prog_guide/rte_flow.rst | 35 ++++++++++++++++++
> > > > >  lib/librte_ethdev/rte_flow.c       |  1 +
> > > > >  lib/librte_ethdev/rte_flow.h       | 59
> > ++++++++++++++++++++++++++++++
> > > > >  3 files changed, 95 insertions(+)
> > > > >
> > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > > > > b/doc/guides/prog_guide/rte_flow.rst
> > > > > index 86b3444803..b737ff9dad 100644
> > > > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > > > @@ -2766,6 +2766,41 @@ The behaviour of the shared action defined
> by
> > > > > ``action`` argument of type
> > > > >     | no properties |
> > > > >     +---------------+
> > > > >
> > > > > +Action: ``COPY_ITEM``
> > > > > +^^^^^^^^^^^^^^^^^^^^^
> > > > > +
> > > > > +Copy ``width`` bits from ``src`` item to ``dst`` item.
> > > > > +
> > > > > +An arbitrary header field (as well as mark, metadata or tag values)
> > > > > +can be used as both source and destination items as set by ``item``.
> > > > > +
> > > >
> > > > For tag I think you should also use the index right?
> > > Right, index is here to access any element in the tag array in addition to
> > > outermost or any inner packet header fields. Will specify explicitly in the doc.
> > >
> > > > > +Inner packet header fields can be accessed using the ``index`` and
> > > > > +it is possible to start the copy from the ``offset`` bits in an item.
> > > >
> > > > Please specify  what means index 0 /1 ... 0 is outer most? Inner most?
> > > > You can look at the RSS level for reference.
> > > > I think it will be best to use the same values.
> > > 0 is outer most, of course,  I'Il add some clarification about that.
> > >
> > Not necessary, like I said please look at the RSS, 0 can mean the inner most.
> >
> > > > What happens if we want to copy between different sizes?
> > > > for example copy IPV6 src to number of tags? I assume we will be using
> > offset
> > > > and
> > > > split the copy command to number of actions right?
> > > That is the correct understanding. We can utilize 4 copy_item actions in this
> > > case to
> > > copy 32-bits of an IPv6 SRC at the time (specifying different offsets) to 4
> > > different Tag fields.
> > >
> > > > > +
> > > > > +.. _table_rte_flow_action_copy_item:
> > > > > +
> > > > > +.. table:: COPY_ITEM
> > > > > +
> > > > > +   +-----------------------------------------+
> > > > > +   | Field         | Value                   |
> > > > > +   +===============+=========================+
> > > > > +   | ``dst``       | destination item        |
> > > > > +   | ``src``       | source item             |
> > > > > +   | ``width``     | number of bits to copy  |
> > > > > +   +---------------+-------------------------+
> > > > > +
> > > > > +.. _table_rte_flow_action_copy_data:
> > > > > +
> > > > > +.. table:: destination/source item definition
> > > > > +
> > > > > +   +----------------------------------------------------------+
> > > > > +   | Field         | Value                                    |
> > > > > +
> > > +===============+==========================================+
> > > > > +   | ``item``      | ID of a packet field/mark/metadata/tag   |
> > > > > +   | ``index``     | index of outer/inner header or tag array |
> > > > > +   | ``offset``    | number of bits to skip during the copy   |
> > > > > +   +---------------+------------------------------------------+
> > > > > +
> > > > >  Negative types
> > > > >  ~~~~~~~~~~~~~~
> > > > >
> > > > > diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> > > > > index a06f64c271..fdbabefc47 100644
> > > > > --- a/lib/librte_ethdev/rte_flow.c
> > > > > +++ b/lib/librte_ethdev/rte_flow.c
> > > > > @@ -176,6 +176,7 @@ static const struct rte_flow_desc_data
> > > > > rte_flow_desc_action[] = {
> > > > >  	MK_FLOW_ACTION(SET_IPV6_DSCP, sizeof(struct
> > > > > rte_flow_action_set_dscp)),
> > > > >  	MK_FLOW_ACTION(AGE, sizeof(struct rte_flow_action_age)),
> > > > >  	MK_FLOW_ACTION(SAMPLE, sizeof(struct rte_flow_action_sample)),
> > > > > +	MK_FLOW_ACTION(COPY_ITEM, sizeof(struct
> > > > > rte_flow_action_copy_item)),
> > > > >  	/**
> > > > >  	 * Shared action represented as handle of type
> > > > >  	 * (struct rte_flow_shared action *) stored in conf field (see
> > > > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > > > > index 0977a78270..0540c861fb 100644
> > > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > > @@ -2198,6 +2198,16 @@ enum rte_flow_action_type {
> > > > >  	 * struct rte_flow_shared_action).
> > > > >  	 */
> > > > >  	RTE_FLOW_ACTION_TYPE_SHARED,
> > > > > +
> > > > > +	/**
> > > > > +	 * Copy a packet header field, tag, mark or metadata.
> > > > > +	 *
> > > > > +	 * Allow saving an arbitrary header field by copying its value
> > > > > +	 * to a tag/mark/metadata or copy it into another header field.
> > > > > +	 *
> > > > > +	 * See struct rte_flow_action_copy_item.
> > > > > +	 */
> > > > > +	RTE_FLOW_ACTION_TYPE_COPY_ITEM,
> > > > >  };
> > > > >
> > > > >  /**
> > > > > @@ -2791,6 +2801,55 @@ struct rte_flow_action_set_dscp {
> > > > >   */
> > > > >  struct rte_flow_shared_action;
> > > > >
> > > > > +enum rte_flow_item_id {
> > > > > +	RTE_FLOW_ITEM_NONE = 0,
> > > > > +	RTE_FLOW_ITEM_MAC_DST,
> > > > > +	RTE_FLOW_ITEM_MAC_SRC,
> > > > > +	RTE_FLOW_ITEM_VLAN_TYPE,
> > > > > +	RTE_FLOW_ITEM_VLAN_ID,
> > > > > +	RTE_FLOW_ITEM_MAC_TYPE,
> > > > > +	RTE_FLOW_ITEM_IPV4_DSCP,
> > > > > +	RTE_FLOW_ITEM_IPV4_TTL,
> > > > > +	RTE_FLOW_ITEM_IPV4_SRC,
> > > > > +	RTE_FLOW_ITEM_IPV4_DST,
> > > > > +	RTE_FLOW_ITEM_IPV6_HOPLIMIT,
> > > > > +	RTE_FLOW_ITEM_IPV6_SRC,
> > > > > +	RTE_FLOW_ITEM_IPV6_DST,
> > > > > +	RTE_FLOW_ITEM_TCP_PORT_SRC,
> > > > > +	RTE_FLOW_ITEM_TCP_PORT_DST,
> > > > > +	RTE_FLOW_ITEM_TCP_SEQ_NUM,
> > > > > +	RTE_FLOW_ITEM_TCP_ACK_NUM,
> > > > > +	RTE_FLOW_ITEM_TCP_FLAGS,
> > > > > +	RTE_FLOW_ITEM_UDP_PORT_SRC,
> > > > > +	RTE_FLOW_ITEM_UDP_PORT_DST,
> > > > > +	RTE_FLOW_ITEM_VXLAN_VNI,
> > > > > +	RTE_FLOW_ITEM_GENEVE_VNI,
> > > > > +	RTE_FLOW_ITEM_GTP_TEID,
> > > > > +	RTE_FLOW_ITEM_TAG,
> > > > > +	RTE_FLOW_ITEM_MARK,
> > > > > +	RTE_FLOW_ITEM_META,
> > > > > +};
> > > >
> > > > I don't think this name is good since it not rte_flow_item this is just internal
> > > > enumeration
> > > > for this action.
> > > Will rename to rte_flow_action_copy_item_id in v3? Is this ok?
> > >
> > Yes better,
> > Or rte_flow_copy_item_id?
> >
> On second thought I think a better name should be:
> rte_flow_field_id - I removed  the copy since we may use it in other actions
> for example set/add
Then I would prefer sticking to the original rte_flow_item_id naming.
It allows room for anyone to use it as a general enum and incrorporates tag/metadata
and other future extensions, not just packet fields.

> > > > > +
> > > > > +struct rte_flow_action_copy_data {
> > > > > +	enum rte_flow_item_id item;
> > > > > +	uint32_t index;
> > > > > +	uint32_t offset;
> > > >
> > > > Why use 32 bits? Since this copy only one register with max len of 32 bit.
> > > > The max offset can 31? Same for the index.
> > > This extends the flexibility of the copy API. This way you can modify any
> place
> > > in a packet as you desire by specifying RTE_FLOW_ITEM_NONE to start with
> > > the
> > > beginning of a packet and choosing a particular offset value to point in a
> > > desired place.
> > > And since packet length can be pretty big we need to accommodate this.
> > > Do you think this flexibility is not necessary and we should bound the offset
> to
> > > the
> > > length of a selected packet field only? Index is 32 bit for the same field in
> RSS.
> > >
> > Nice idea but then I would add ITEM_OFFSET or something
> > around this name, I don't think NONE is a valid value.
> >
> > > > > +};
> > > > > +
> > > > > +/**
> > > > > + * RTE_FLOW_ACTION_TYPE_COPY_ITEM
> > > > > + *
> > > > > + * Copies a specified number of bits from a source header field
> > > > > + * to a destination header field. Tag, mark or metadata can also
> > > > > + * be used as a source/destination to allow saving/overwriting
> > > > > + * an arbituary header field with a user-specified value.
> > > > > + */
> > > > > +struct rte_flow_action_copy_item {
> > > > > +	struct rte_flow_action_copy_data dst;
> > > > > +	struct rte_flow_action_copy_data src;
> > > > > +	uint32_t width;
> > > >
> > > > Why use 32 bit register?
> > > Again, to make API as generic as possible in case there will be a PMD driver
> > > that can copy a huge chunk of a packet into the another place of this packet.
> > > What is your opinion on that?
> > >
> > Nice thinking,
> >
> > > >
> > > > > +};
> > > > > +
> > > > >  /* Mbuf dynamic field offset for metadata. */
> > > > >  extern int32_t rte_flow_dynf_metadata_offs;
> > > > >
> > > > > --
> > > > > 2.24.1
> > > >
> > > > Best,
> > > > Ori


  reply	other threads:[~2021-01-12 17:20 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  6:32 Alexander Kozyrev
2021-01-10  8:00 ` Ori Kam
2021-01-10  9:36   ` Asaf Penso
2021-01-12 14:15   ` Alexander Kozyrev
2021-01-12 14:52     ` Ori Kam
2021-01-12 15:13       ` Ori Kam
2021-01-12 17:19         ` Alexander Kozyrev [this message]
2021-01-12  5:01 ` [dpdk-dev] [PATCH v2 0/2] generic copy rte flow action support Alexander Kozyrev
2021-01-12  5:01   ` [dpdk-dev] [PATCH v2 1/2] ethdev: introduce generic copy rte flow action Alexander Kozyrev
2021-01-12  5:01   ` [dpdk-dev] [PATCH v2 2/2] app/testpmd: add support for " Alexander Kozyrev
2021-01-12 14:58     ` Ori Kam
2021-01-13  3:38   ` [dpdk-dev] [PATCH v3 0/2] generic copy rte flow action support Alexander Kozyrev
2021-01-13  3:38     ` [dpdk-dev] [PATCH v3 1/2] ethdev: introduce generic copy rte flow action Alexander Kozyrev
2021-01-13 11:12       ` Ori Kam
2021-01-13  3:38     ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: add support for " Alexander Kozyrev
2021-01-13 17:07     ` [dpdk-dev] [PATCH v4 0/2] generic copy rte flow action support Alexander Kozyrev
2021-01-13 17:07       ` [dpdk-dev] [PATCH v4 1/2] ethdev: introduce generic copy rte flow action Alexander Kozyrev
2021-01-14 12:22         ` Ori Kam
2021-01-13 17:07       ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: add support for " Alexander Kozyrev
2021-01-14 15:18         ` Ori Kam
2021-01-15 15:37           ` Alexander Kozyrev
2021-01-15 15:42       ` [dpdk-dev] [PATCH v5 0/2] generic modify rte flow action support Alexander Kozyrev
2021-01-15 15:42         ` [dpdk-dev] [PATCH v5 1/2] ethdev: introduce generic modify rte flow action Alexander Kozyrev
2021-01-15 18:03           ` Ori Kam
2021-01-17  9:23             ` Slava Ovsiienko
2021-01-15 15:42         ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: add support for modify field " Alexander Kozyrev
2021-01-15 18:04           ` Ori Kam
2021-01-16  4:44         ` [dpdk-dev] [PATCH v6 0/2] generic modify rte flow action support Alexander Kozyrev
2021-01-16  4:44           ` [dpdk-dev] [PATCH v6 1/2] ethdev: introduce generic modify rte flow action Alexander Kozyrev
2021-01-16  4:44           ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: add support for modify field " Alexander Kozyrev
2021-01-16  4:50           ` [dpdk-dev] [PATCH v7 0/2] generic modify rte flow action support Alexander Kozyrev
2021-01-16  4:50             ` [dpdk-dev] [PATCH v7 1/2] ethdev: introduce generic modify rte flow action Alexander Kozyrev
2021-01-17 23:15               ` Thomas Monjalon
2021-01-18 16:03                 ` Alexander Kozyrev
2021-01-16  4:50             ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: add support for modify field " Alexander Kozyrev
2021-01-18 16:18             ` [dpdk-dev] [PATCH v8 0/2] generic modify rte flow action support Alexander Kozyrev
2021-01-18 16:18               ` [dpdk-dev] [PATCH v8 1/2] ethdev: introduce generic modify rte flow action Alexander Kozyrev
2021-01-18 17:51                 ` Thomas Monjalon
2021-01-18 16:18               ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: add support for modify field " Alexander Kozyrev
2021-01-18 20:05               ` [dpdk-dev] [PATCH v8 0/2] generic modify rte flow action support Ajit Khaparde
2021-01-18 21:40               ` [dpdk-dev] [PATCH v9 " Alexander Kozyrev
2021-01-18 21:40                 ` [dpdk-dev] [PATCH v9 1/2] ethdev: introduce generic modify rte flow action Alexander Kozyrev
2021-01-18 21:40                 ` [dpdk-dev] [PATCH v9 2/2] app/testpmd: add support for modify field " Alexander Kozyrev
2021-01-19  1:21                 ` [dpdk-dev] [PATCH v9 0/2] generic modify rte flow action support Ferruh Yigit
2021-01-14 13:59 ` [dpdk-dev] [PATCH] ethdev: introduce generic copy rte flow action Jerin Jacob
2021-01-14 15:02   ` Ori Kam
2021-01-15 14:00     ` Jerin Jacob
2021-01-15 15:33       ` Alexander Kozyrev

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=BN7PR12MB270764D57C567E0FF41220A2AFAA0@BN7PR12MB2707.namprd12.prod.outlook.com \
    --to=akozyrev@nvidia.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git