DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Ivan Malov <Ivan.Malov@oktetlabs.ru>, Ori Kam <orika@nvidia.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Ray Kinsella <mdr@ashroe.eu>, Jerin Jacob <jerinj@marvell.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Andy Moreton <amoreton@xilinx.com>,
	Wisam Monther <wisamm@nvidia.com>,
	Xiaoyun Li <xiaoyun.li@intel.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD
Date: Tue, 5 Oct 2021 16:17:25 +0300
Message-ID: <cc981d4a-3ad7-86dd-11a5-f65c62158c53@oktetlabs.ru> (raw)
In-Reply-To: <c21f6453-1e76-38b8-3069-be12b1d1090f@oktetlabs.ru>

On 10/5/21 3:50 PM, Ivan Malov wrote:
> Hi Ori,
> 
> On 05/10/2021 15:03, Ori Kam wrote:
>> Hi Ivan,
>>
>> Just a nit below.
>>
>>> -----Original Message-----
>>> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> Sent: Tuesday, October 5, 2021 2:50 AM
>>> Subject: [PATCH v4 1/5] ethdev: negotiate delivery of packet metadata
>>> from
>>> HW to PMD
>>>
>>> Provide an API to let the application control the NIC's ability to
>>> deliver specific
>>> kinds of per-packet metadata to the PMD.
>>>
>>> Checks for the NIC's ability to set these kinds of metadata in the
>>> first place
>>> (support for the flow actions) belong in flow API responsibility
>>> domain (flow
>>> validate mechanism).
>>> This topic is out of scope of the new API in question.
>>>
>>> The PMD's ability to deliver received metadata to the user by virtue
>>> of mbuf
>>> fields should be covered by mbuf library.
>>> It is also out of scope of the new API in question.
>>>
>>
>> +1 very clear.
>>
>>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
>>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
>>> Acked-by: Jerin Jacob <jerinj@marvell.com>
>>> ---
>>
>> [Snip]
>>
>>> --- a/lib/ethdev/rte_ethdev.h
>>> +++ b/lib/ethdev/rte_ethdev.h
>>> @@ -4902,6 +4902,59 @@ __rte_experimental  int
>>> rte_eth_representor_info_get(uint16_t port_id,
>>>                    struct rte_eth_representor_info *info);
>>>
>>> +/** The NIC is able to deliver flag (if set) with packets to the PMD.
>>> +*/ #define RTE_ETH_RX_METADATA_USER_FLAG (UINT64_C(1) << 0)
>>> +
>>> +/** The NIC is able to deliver mark ID with packets to the PMD. */
>>> +#define RTE_ETH_RX_METADATA_USER_MARK (UINT64_C(1) << 1)
>>> +
>>> +/** The NIC is able to deliver tunnel ID with packets to the PMD. */
>>> +#define RTE_ETH_RX_METADATA_TUNNEL_ID (UINT64_C(1) << 2)
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>> + *
>>> + * Negotiate the NIC's ability to deliver specific kinds of metadata
>>> to the PMD.
>>> + *
>>> + * Invoke this API before the first rte_eth_dev_configure() invocation
>>> + * to let the PMD make preparations that are inconvenient to do later.
>>> + *
>>> + * The negotiation process is as follows:
>>> + *
>>> + * - the application requests features intending to use at least some
>>> +of them;
>>> + * - the PMD responds with the guaranteed subset of the requested
>>> +feature set;
>>> + * - the application can retry negotiation with another set of
>>> +features;
>>> + * - the application can pass zero to clear the negotiation result;
>>> + * - the last negotiated result takes effect upon the ethdev start.
>>
>> Not upon ethdev configure?
> 
> Well, technically, doing "configure()" just closes the negotiation
> window. I guess, "to take effect" is "to be activated", and activation
> of Rx features typically happens on Rx subsystem start.

Yes, i.e. ethdev port start from application point of view

> I know it might seem a bit inconsistent, but in any case the API
> contract says clearly that invocations of "metadata_negotiate()" should
> be done before "configure()".
> 
> Andrew?

Yes, the reason to define order is to simplify implementation.
When configure is invoked, PMD know that Rx metadata are
negotiated and it should treat all other bits of the
configuration with respect to Rx metadata configuration,
of course, if applicable.

So, I think the question is right and correct description
should say: ... upon the ethdev configure and start.

Andrew.

  reply	other threads:[~2021-10-05 13:17 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 14:23 [dpdk-dev] [PATCH 0/5] A means to negotiate support for Rx meta information Ivan Malov
2021-09-02 14:23 ` [dpdk-dev] [PATCH 1/5] ethdev: add API " Ivan Malov
2021-09-02 14:47   ` Jerin Jacob
2021-09-02 16:14   ` Kinsella, Ray
2021-09-03  9:34   ` Jerin Jacob
2021-09-02 14:23 ` [dpdk-dev] [PATCH 2/5] net/sfc: provide API to negotiate supported Rx meta features Ivan Malov
2021-09-02 14:23 ` [dpdk-dev] [PATCH 3/5] net/sfc: allow to use EF100 native datapath Rx mark in flows Ivan Malov
2021-09-02 14:23 ` [dpdk-dev] [PATCH 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-09-02 14:23 ` [dpdk-dev] [PATCH 5/5] net/sfc: allow to discern user flag on EF100 native datapath Ivan Malov
2021-09-03  0:15 ` [dpdk-dev] [PATCH v2 0/5] A means to negotiate support for Rx meta information Ivan Malov
2021-09-03  0:15   ` [dpdk-dev] [PATCH v2 1/5] ethdev: add API " Ivan Malov
2021-09-03  0:15   ` [dpdk-dev] [PATCH v2 2/5] net/sfc: provide API to negotiate supported Rx meta features Ivan Malov
2021-09-03  0:15   ` [dpdk-dev] [PATCH v2 3/5] net/sfc: allow to use EF100 native datapath Rx mark in flows Ivan Malov
2021-09-03  0:15   ` [dpdk-dev] [PATCH v2 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-09-03  0:15   ` [dpdk-dev] [PATCH v2 5/5] net/sfc: allow to discern user flag on EF100 native datapath Ivan Malov
2021-09-23 11:20 ` [dpdk-dev] [PATCH v3 0/5] A means to negotiate delivery of Rx meta data Ivan Malov
2021-09-23 11:20   ` [dpdk-dev] [PATCH v3 1/5] ethdev: add API " Ivan Malov
2021-09-30 14:59     ` Ori Kam
2021-09-30 15:07       ` Andrew Rybchenko
2021-09-30 19:07       ` Ivan Malov
2021-10-01  6:50         ` Andrew Rybchenko
2021-10-03  7:42           ` Ori Kam
2021-10-03  9:30             ` Ivan Malov
2021-10-03 11:01               ` Ori Kam
2021-10-03 17:30                 ` Ivan Malov
2021-10-03 21:04                   ` Ori Kam
2021-10-03 23:50                     ` Ivan Malov
2021-10-04  6:56                       ` Ori Kam
2021-10-04 11:39                         ` Ivan Malov
2021-10-04 13:53                           ` Andrew Rybchenko
2021-10-05  6:30                             ` Ori Kam
2021-10-05  7:27                               ` Andrew Rybchenko
2021-10-05  8:17                                 ` Ori Kam
2021-10-05  8:38                                   ` Andrew Rybchenko
2021-10-05  9:41                                     ` Ori Kam
2021-10-05 10:01                                       ` Andrew Rybchenko
2021-10-05 10:10                                         ` Ori Kam
2021-10-05 11:11                                           ` Andrew Rybchenko
2021-10-06  8:30                                             ` Thomas Monjalon
2021-10-06  8:38                                               ` Andrew Rybchenko
2021-10-06  9:14                                                 ` Ori Kam
2021-09-30 21:48     ` Ajit Khaparde
2021-09-30 22:00       ` Ivan Malov
2021-09-30 22:12         ` Ajit Khaparde
2021-09-30 22:22           ` Ivan Malov
2021-10-03  7:05             ` Ori Kam
2021-09-23 11:20   ` [dpdk-dev] [PATCH v3 2/5] net/sfc: support " Ivan Malov
2021-09-23 11:20   ` [dpdk-dev] [PATCH v3 3/5] net/sfc: support flow mark delivery on EF100 native datapath Ivan Malov
2021-09-23 11:20   ` [dpdk-dev] [PATCH v3 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-09-23 11:20   ` [dpdk-dev] [PATCH v3 5/5] net/sfc: report user flag on EF100 native datapath Ivan Malov
2021-09-30 16:18   ` [dpdk-dev] [PATCH v3 0/5] A means to negotiate delivery of Rx meta data Thomas Monjalon
2021-09-30 19:30     ` Ivan Malov
2021-10-01  6:47       ` Andrew Rybchenko
2021-10-01  8:11         ` Thomas Monjalon
2021-10-01  8:54           ` Andrew Rybchenko
2021-10-01  9:32             ` Thomas Monjalon
2021-10-01  9:41               ` Andrew Rybchenko
2021-10-01  8:55           ` Ivan Malov
2021-10-01  9:48             ` Thomas Monjalon
2021-10-01 10:15               ` Andrew Rybchenko
2021-10-01 12:10                 ` Thomas Monjalon
2021-10-04  9:17                   ` Andrew Rybchenko
2021-10-04 23:50   ` [dpdk-dev] [PATCH v4 0/5] Negotiate the NIC's ability to deliver Rx metadata to the PMD Ivan Malov
2021-10-04 23:50     ` [dpdk-dev] [PATCH v4 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD Ivan Malov
2021-10-05 12:03       ` Ori Kam
2021-10-05 12:50         ` Ivan Malov
2021-10-05 13:17           ` Andrew Rybchenko [this message]
2021-10-04 23:50     ` [dpdk-dev] [PATCH v4 2/5] net/sfc: support API to negotiate delivery of Rx metadata Ivan Malov
2021-10-04 23:50     ` [dpdk-dev] [PATCH v4 3/5] net/sfc: support flow mark delivery on EF100 native datapath Ivan Malov
2021-10-04 23:50     ` [dpdk-dev] [PATCH v4 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-10-04 23:50     ` [dpdk-dev] [PATCH v4 5/5] net/sfc: report user flag on EF100 native datapath Ivan Malov
2021-10-05 15:56   ` [dpdk-dev] [PATCH v5 0/5] ethdev: negotiate the NIC's ability to deliver Rx metadata to the PMD Ivan Malov
2021-10-05 15:56     ` [dpdk-dev] [PATCH v5 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD Ivan Malov
2021-10-05 21:40       ` Ajit Khaparde
2021-10-06  6:04         ` Somnath Kotur
2021-10-06  6:10           ` Ori Kam
2021-10-06  7:22             ` Wisam Monther
2021-10-05 15:56     ` [dpdk-dev] [PATCH v5 2/5] net/sfc: support API to negotiate delivery of Rx metadata Ivan Malov
2021-10-05 15:56     ` [dpdk-dev] [PATCH v5 3/5] net/sfc: support flow mark delivery on EF100 native datapath Ivan Malov
2021-10-05 15:56     ` [dpdk-dev] [PATCH v5 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-10-05 15:56     ` [dpdk-dev] [PATCH v5 5/5] net/sfc: report user flag on EF100 native datapath Ivan Malov
2021-10-12 18:08       ` Ferruh Yigit
2021-10-12 19:39         ` Ivan Malov
2021-10-12 19:48         ` Ivan Malov
2021-10-12 19:38   ` [dpdk-dev] [PATCH v6 0/5] ethdev: negotiate the NIC's ability to deliver Rx metadata to the PMD Ivan Malov
2021-10-12 19:38     ` [dpdk-dev] [PATCH v6 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD Ivan Malov
2021-10-12 19:38     ` [dpdk-dev] [PATCH v6 2/5] net/sfc: support API to negotiate delivery of Rx metadata Ivan Malov
2021-10-12 19:38     ` [dpdk-dev] [PATCH v6 3/5] net/sfc: support flow mark delivery on EF100 native datapath Ivan Malov
2021-10-12 19:38     ` [dpdk-dev] [PATCH v6 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-10-12 19:38     ` [dpdk-dev] [PATCH v6 5/5] net/sfc: report user flag on EF100 native datapath Ivan Malov
2021-10-12 19:46   ` [dpdk-dev] [PATCH v7 0/5] ethdev: negotiate the NIC's ability to deliver Rx metadata to the PMD Ivan Malov
2021-10-12 19:46     ` [dpdk-dev] [PATCH v7 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD Ivan Malov
2021-10-12 19:46     ` [dpdk-dev] [PATCH v7 2/5] net/sfc: support API to negotiate delivery of Rx metadata Ivan Malov
2021-10-12 19:46     ` [dpdk-dev] [PATCH v7 3/5] net/sfc: support flow mark delivery on EF100 native datapath Ivan Malov
2021-10-12 19:46     ` [dpdk-dev] [PATCH v7 4/5] common/sfc_efx/base: add RxQ flag to use Rx prefix user flag Ivan Malov
2021-10-12 19:46     ` [dpdk-dev] [PATCH v7 5/5] net/sfc: report user flag on EF100 native datapath Ivan Malov
2021-10-12 23:25     ` [dpdk-dev] [PATCH v7 0/5] ethdev: negotiate the NIC's ability to deliver Rx metadata to the PMD Ferruh Yigit

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=cc981d4a-3ad7-86dd-11a5-f65c62158c53@oktetlabs.ru \
    --to=andrew.rybchenko@oktetlabs.ru \
    --cc=Ivan.Malov@oktetlabs.ru \
    --cc=ajit.khaparde@broadcom.com \
    --cc=amoreton@xilinx.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=mdr@ashroe.eu \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=wisamm@nvidia.com \
    --cc=xiaoyun.li@intel.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 https://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/ https://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