DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
To: Ori Kam <orika@nvidia.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Andy Moreton <amoreton@xilinx.com>, Ray Kinsella <mdr@ashroe.eu>,
	Jerin Jacob <jerinj@marvell.com>,
	Wisam Monther <wisamm@nvidia.com>,
	Xiaoyun Li <xiaoyun.li@intel.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta data
Date: Sun, 3 Oct 2021 20:30:03 +0300	[thread overview]
Message-ID: <06d5d165-a9e0-ecc6-74b5-20a77a88e301@oktetlabs.ru> (raw)
In-Reply-To: <DM8PR12MB5400C6E817E9F2390A27134FD6AD9@DM8PR12MB5400.namprd12.prod.outlook.com>

Hi Ori,

On 03/10/2021 14:01, Ori Kam wrote:
> Hi Ivan,
> 
>> -----Original Message-----
>> From: Ivan Malov <Ivan.Malov@oktetlabs.ru>
>> Sent: Sunday, October 3, 2021 12:30 PM
>> data
>>
>> Hi Ori,
>>
>> Thanks for reviewing this.
>>
> 
> No problem.
> 
>> On 03/10/2021 10:42, Ori Kam wrote:
>>> Hi Andrew and Ivan,
>>>
>>>
>>>> -----Original Message-----
>>>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Sent: Friday, October 1, 2021 9:50 AM
>>>> Subject: Re: [PATCH v3 1/5] ethdev: add API to negotiate delivery of
>>>> Rx meta data
>>>>
>>>> On 9/30/21 10:07 PM, Ivan Malov wrote:
>>>>> Hi Ori,
>>>>>
>>>>> On 30/09/2021 17:59, Ori Kam wrote:
>>>>>> Hi Ivan,
>>>>>> Sorry for jumping in late.
>>>>>
>>>>> No worries. That's OK.
>>>>>
>>>>>> I have a concern that this patch breaks other PMDs.
>>>>>
>>>>> It does no such thing.
>>>>>
>>>>>>>   From the rst file " One should negotiate flag delivery beforehand"
>>>>>> since you only added this function for your PMD all other PMD will fail.
>>>>>> I see that you added exception in the  examples, but it doesn't
>>>>>> make sense that applications will also need to add this exception
>>>>>> which is not documented.
>>>>>
>>>>> Say, you have an application, and you use it with some specific PMD.
>>>>> Say, that PMD doesn't run into the problem as ours does. In other
>>>>> words, the user can insert a flow with action MARK at any point and
>>>>> get mark delivery working starting from that moment without any
>>>>> problem. Say, this is exactly the way how it works for you at the
>> moment.
>>>>>
>>>>> Now. This new API kicks in. We update the application to invoke it
>>>>> as early as possible. But your PMD in question still doesn't support
>>>>> this API. The comment in the patch says that if the method returns
>>>>> ENOTSUP, the application should ignore that without batting an
>>>>> eyelid. It should just keep on working as it did before the introduction of
>> this API.
>>>>>
>>>
>>> I understand that it is nice to write in the patch comment that
>>> application should disregard this function in case of ENOTSUP but in a
>>> few month someone will read the official doc, where it is stated that
>>> this function call is a must and then what do you think the
>>> application will do?
>>> I think that the correct way is to add this function to all PMDs.
>>> Another option is to add to the doc that if the function is returning
>>> ENOTSUP the application should assume that all is supported.
>>>
>>> So from this point of view there is API break.
>>
>> So, you mean an API breakage in some formal sense? If the doc is fixed in
>> accordance with the second option you suggest, will it suffice to avoid this
>> formal API breakage?
>>
> 
> Yes, but I think it will be better to add the missing function.
> 
>>>
>>>>> More specific example:
>>>>> Say, the application doesn't mind using either "RSS + MARK" or
>>>>> tunnel offload. What it does right now is attempt to insert tunnel
>>>>> flows first and, if this fails, fall back to "RSS + MARK". With this
>>>>> API, the application will try to invoke this API with "USER_MARK |
>>>>> TUNNEL_ID" in adapter initialised state. If the PMD says that it can
>>>>> only enable the tunnel offload, then the application will get the
>>>>> knowledge that it doesn't make sense to even try inserting "RSS +
>>>>> MARK" flows. It just can skip useless actions. But if the PMD
>>>>> doesn't support the method, the application will see ENOTSUP and
>>>>> handle this
>>>>> gracefully: it will make no assumptions about what's guaranteed to
>>>>> be supported and what's not and will just keep on its old behavior:
>>>>> try to insert a flow, fail, fall back to another type of flow.
>>>>>
>>>
>>> I fully agree with your example, and think that this is the way to go,
>>> application should supply as much info as possible during startup.
>>
>> Right.
>>
>>> My question/comment is the negotiated result means that all of the
>>> actions are supported on the same rule?
>>> for example if application wants to add mark and tag on the same rule.
>>> (I know it doesn't make much sense) and the PMD can support both of
>>> them but not on the same rule, what should it return?
>>> Or for example if using the mark can only be supported if no decap
>>> action is set on this rule what should be the result?
>>>   From my undstanding this function is only to let the PMD know that on
>>> some rules the application will use those actions, the checking if the
>>> action combination is valid only happens on validate function right?
>>
>> This API does not bind itself to flow API. It's *not* about enabling support for
>> metadata *actions* (they are conducted entirely *inside* the NIC). It's
>> about enabling *delivery* of metadata from the NIC to host.
>>
> 
> Good point so why not use the same logic as the metadata and register it?
> Since in any case, this is something in the mbuf so maybe this should be the answer?

I didn't catch your thought. Could you please elaborate on it?

>   
>> Say, you insert a flow rule to mark some packets. The NIC, internally (in the
>> e-switch) adds the mark to matching packets. Yes, in the boundaries of the
>> NIC HW, the packets bear the mark on them. It has been set, yes. But when
>> time comes to *deliver* the packets to the host, the NIC (at least, in net/sfc
>> case) has two options: either provide only a small chunk of the metadata for
>> each packet *to the host*, which doesn't include mark ID, flag and RSS hash,
>> OR, alternatively, provide the full set of metadata. In the former option, the
>> mark is simply not delivered.
>> Once again: it *has been set*, but simply will not be *delivered to the host*.
>>
>> So, this API is about negotiating *delivery* of metadata. In pure technical
>> sense. And the set of flags that this API returns indicates which kinds of
>> metadata the NIC will be able to deliver simultaneously.
>>
>> For example, as I understand, in the case of tunnel offload, MLX5 claims Rx
>> mark entirely for tunnel ID metadata, so, if an application requests "MARK |
>> TUNNEL_ID" with this API, this PMD should probably want to respond with
>> just "TUNNEL_ID". The application will see the response and realise that,
>> even if it adds its *own* (user) action MARK to a flow and if the flow is not
>> rejected by the PMD, it won't be able to see the mark in the received mbufs
>> (or the mark will be incorrect).
>>
> So what should the application do if on some flows it wants MARK and on other FLAG?

You mentioned flows, so I'd like to stress this out one more time: what 
this API cares about is solely the possibility to deliver metadata 
between the NIC and the host. The host == the PMD (*not* application).

>  From DPDK viewpoint both of them can't be shared on the same rule
> (they are using the same space in mbuf) so the application will never
> ask for both of them in the same rule but he can on some rules ask for mark
> while on other request for FLAG, even in your code you added both of them.
> 
> So what should the PMD return if it can support both of them just not at the same
> rule?

Please see above. This is not about rules. This is not about the way how 
flag and mark are presented *by* the PMD *to* the application in mbufs. 
Simultaneous use of actions FLAG and MARK in flows must be ruled out by 
rte_flow_validate() / rte_flow_create(). The way how flag and mark are 
*represented* in mbufs belongs in mbuf library responsibility domain.

Consider the following operational sequence:

1) The NIC has a packet, which has metadata associated with it;
2) The NIC transfers this packet to the host;
3) The PMD sees the packet and its metadata;
4) The PMD represents whatever available metadata in mbuf format.

Features negotiated by virtue of this API (for instance, FLAG and MARK) 
enable delivery of these kinds of metadata between points (2) and (3).

And the problem of flag / mark co-existence in mbufs sits at point (4).

-> Completely different problems, in fact.

> 
> One option is to document that the supported values are not per rule but for the entire
> port. For example in the example you gave MLX5 will support mark + flag but will not
> support mark + tunnel.

Yes, for the port. Flow rules are a don't care to this API.

> 
> Also considering your example, the negotiation may result in subpar result.
> taking your example the PMD returned  TUNNEL_ID maybe application would prefer
> to have the mark and not the TUNNEL_ID. I understand that application can check
> and try again with just the MARK.

Exactly. The Application can repeat negotiation with just MARK. Is there 
any problem with that?

> You are inserting logic to the PMD, maybe the function should just fail maybe
> returning the conflicting items?

Why return conflicting items? The optimal subset (from the PMD's 
perspective) should be returned. It's a silver lining. In the end, the 
application can learn which features can be enabled and in what 
combinations. And it can rely on the outcome of the negotiation process.

> 
> 
>   
>> But some other PMDs (net/sfc, for instance) claim only a small fraction of bits
>> in Rx mark to deliver tunnel ID information. Remaining bits are still available
>> for delivery of *user* mark ID. Please see an example at
>> https://patches.dpdk.org/project/dpdk/patch/20210929205730.775-2-
>> ivan.malov@oktetlabs.ru/
>> . In this case, the PMD may want to return both flags in the response:
>> "MARK | TUNNEL_ID". This way, the application knows that both features
>> are enabled and available for use.
>>
>> Now. I anticipate more questions asking why wouldn't we prefer flow API
>> terminology or why wouldn't we add an API for negotiating support for
>> metadata *actions* and not just metadata *delivery*. There's an answer.
>> Always has been.
>>
>> The thing is, the use of *actions* is very complicated. For example, the PMD
>> may support action MARK for "transfer" flows but not for non-"transfer"
>> ones. Also, simultaneous use of multiple different metadata actions may not
>> be possible. And, last but not least, if we force the application to check
>> support for *actions* on action-after-action basis, the order of checks will be
>> very confusing to applications.
>>
>> Previously, in this thread, Thomas suggested to go for exactly this type of
>> API, to check support for actions one-by-one, without any context
>> ("transfer" / non-"transfer"). I'm afraid, this won't be OK.
>>
> +1 to keeping it as a separated API. (I agree actions limitation are very complex metrix)
> 
>>>
>>> In any case I think this is good idea and I will see how we can add a
>>> more generic approach of this API to the new API that I'm going to present.
>>>
>>>
>>>>> So no breakages with this API.
>>>>>
>>>>>>
>>>>>> Please see more comments inline.
>>>>>>
>>>>>> Thanks,
>>>>>> Ori
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>>>>>>> Sent: Thursday, September 23, 2021 2:20 PM
>>>>>>> Subject: [PATCH v3 1/5] ethdev: add API to negotiate delivery of
>>>>>>> Rx meta data
>>>>>>>
>>>>>>> Delivery of mark, flag and the likes might affect small packet
>>>>>>> performance.
>>>>>>> If these features are disabled by default, enabling them in
>>>>>>> started state without causing traffic disruption may not always be
>> possible.
>>>>>>>
>>>>>>> Let applications negotiate delivery of Rx meta data beforehand.
>>>>>>>
>>>>>>> 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>
>>>>>>> ---
>>>>>>>     app/test-flow-perf/main.c              | 21 ++++++++++++
>>>>>>>     app/test-pmd/testpmd.c                 | 26 +++++++++++++++
>>>>>>>     doc/guides/rel_notes/release_21_11.rst |  9 ++++++
>>>>>>>     lib/ethdev/ethdev_driver.h             | 19 +++++++++++
>>>>>>>     lib/ethdev/rte_ethdev.c                | 25 ++++++++++++++
>>>>>>>     lib/ethdev/rte_ethdev.h                | 45
>>>>>>> ++++++++++++++++++++++++++
>>>>>>>     lib/ethdev/rte_flow.h                  | 12 +++++++
>>>>>>>     lib/ethdev/version.map                 |  3 ++
>>>>>>>     8 files changed, 160 insertions(+)
>>>>>>>
>>>>>>> diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
>>>>>>> index 9be8edc31d..48eafffb1d 100644
>>>>>>> --- a/app/test-flow-perf/main.c
>>>>>>> +++ b/app/test-flow-perf/main.c
>>>>>>> @@ -1760,6 +1760,27 @@ init_port(void)
>>>>>>>             rte_exit(EXIT_FAILURE, "Error: can't init mbuf
>>>>>>> pool\n");
>>>>>>>
>>>>>>>         for (port_id = 0; port_id < nr_ports; port_id++) {
>>>>>>> +        uint64_t rx_meta_features = 0;
>>>>>>> +
>>>>>>> +        rx_meta_features |= RTE_ETH_RX_META_USER_FLAG;
>>>>>>> +        rx_meta_features |= RTE_ETH_RX_META_USER_MARK;
>>>>>>> +
>>>>>>> +        ret = rte_eth_rx_meta_negotiate(port_id,
>>>>>>> &rx_meta_features);
>>>>>>> +        if (ret == 0) {
>>>>>>> +            if (!(rx_meta_features &
>>>>>>> RTE_ETH_RX_META_USER_FLAG)) {
>>>>>>> +                printf(":: flow action FLAG will not affect Rx
>>>>>>> mbufs on port=%u\n",
>>>>>>> +                       port_id);
>>>>>>> +            }
>>>>>>> +
>>>>>>> +            if (!(rx_meta_features &
>>>>>>> RTE_ETH_RX_META_USER_MARK)) {
>>>>>>> +                printf(":: flow action MARK will not affect Rx
>>>>>>> mbufs on port=%u\n",
>>>>>>> +                       port_id);
>>>>>>> +            }
>>>>>>> +        } else if (ret != -ENOTSUP) {
>>>>>>> +            rte_exit(EXIT_FAILURE, "Error when negotiating Rx
>>>>>>> meta features on port=%u: %s\n",
>>>>>>> +                 port_id, rte_strerror(-ret));
>>>>>>> +        }
>>>>>>> +
>>>>>>>             ret = rte_eth_dev_info_get(port_id, &dev_info);
>>>>>>>             if (ret != 0)
>>>>>>>                 rte_exit(EXIT_FAILURE, diff --git
>>>>>>> a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>>>>>> 97ae52e17e..7a8da3d7ab 100644
>>>>>>> --- a/app/test-pmd/testpmd.c
>>>>>>> +++ b/app/test-pmd/testpmd.c
>>>>>>> @@ -1485,10 +1485,36 @@ static void
>>>>>>>     init_config_port_offloads(portid_t pid, uint32_t socket_id)  {
>>>>>>>         struct rte_port *port = &ports[pid];
>>>>>>> +    uint64_t rx_meta_features = 0;
>>>>>>>         uint16_t data_size;
>>>>>>>         int ret;
>>>>>>>         int i;
>>>>>>>
>>>>>>> +    rx_meta_features |= RTE_ETH_RX_META_USER_FLAG;
>>>>>>> +    rx_meta_features |= RTE_ETH_RX_META_USER_MARK;
>>>>>>> +    rx_meta_features |= RTE_ETH_RX_META_TUNNEL_ID;
>>>>>>> +
>>>>>>> +    ret = rte_eth_rx_meta_negotiate(pid, &rx_meta_features);
>>>>>>> +    if (ret == 0) {
>>>>>>> +        if (!(rx_meta_features & RTE_ETH_RX_META_USER_FLAG)) {
>>>>>>> +            TESTPMD_LOG(INFO, "Flow action FLAG will not
>>>>>>> affect Rx mbufs on port %u\n",
>>>>>>> +                    pid);
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        if (!(rx_meta_features & RTE_ETH_RX_META_USER_MARK))
>>>>>>> {
>>>>>>> +            TESTPMD_LOG(INFO, "Flow action MARK will not
>>>>>>> affect Rx mbufs on port %u\n",
>>>>>>> +                    pid);
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        if (!(rx_meta_features & RTE_ETH_RX_META_TUNNEL_ID)) {
>>>>>>> +            TESTPMD_LOG(INFO, "Flow tunnel offload support
>>>>>>> might be limited or unavailable on port %u\n",
>>>>>>> +                    pid);
>>>>>>> +        }
>>>>>>> +    } else if (ret != -ENOTSUP) {
>>>>>>> +        rte_exit(EXIT_FAILURE, "Error when negotiating Rx meta
>>>>>>> features on port %u: %s\n",
>>>>>>> +             pid, rte_strerror(-ret));
>>>>>>> +    }
>>>>>>> +
>>>>>>>         port->dev_conf.txmode = tx_mode;
>>>>>>>         port->dev_conf.rxmode = rx_mode;
>>>>>>>
>>>>>>> diff --git a/doc/guides/rel_notes/release_21_11.rst
>>>>>>> b/doc/guides/rel_notes/release_21_11.rst
>>>>>>> index 19356ac53c..6674d4474c 100644
>>>>>>> --- a/doc/guides/rel_notes/release_21_11.rst
>>>>>>> +++ b/doc/guides/rel_notes/release_21_11.rst
>>>>>>> @@ -106,6 +106,15 @@ New Features
>>>>>>>       Added command-line options to specify total number of
>>>>>>> processes and
>>>>>>>       current process ID. Each process owns subset of Rx and Tx queues.
>>>>>>>
>>>>>>> +* **Added an API to negotiate delivery of specific parts of Rx
>>>>>>> +meta
>>>>>>> +data**
>>>>>>> +
>>>>>>> +  A new API, ``rte_eth_rx_meta_negotiate()``, was added.
>>>>>>> +  The following parts of Rx meta data were defined:
>>>>>>> +
>>>>>>> +  * ``RTE_ETH_RX_META_USER_FLAG``
>>>>>>> +  * ``RTE_ETH_RX_META_USER_MARK``
>>>>>>> +  * ``RTE_ETH_RX_META_TUNNEL_ID``
>>>>>>> +
>>>>>>>
>>>>>>>     Removed Items
>>>>>>>     -------------
>>>>>>> diff --git a/lib/ethdev/ethdev_driver.h
>>>>>>> b/lib/ethdev/ethdev_driver.h index 40e474aa7e..96e0c60cae 100644
>>>>>>> --- a/lib/ethdev/ethdev_driver.h
>>>>>>> +++ b/lib/ethdev/ethdev_driver.h
>>>>>>> @@ -789,6 +789,22 @@ typedef int (*eth_get_monitor_addr_t)(void
>>>>>>> *rxq, typedef int (*eth_representor_info_get_t)(struct rte_eth_dev
>>>>>>> *dev,
>>>>>>>         struct rte_eth_representor_info *info);
>>>>>>>
>>>>>>> +/**
>>>>>>> + * @internal
>>>>>>> + * Negotiate delivery of specific parts of Rx meta data.
>>>>>>> + *
>>>>>>> + * @param dev
>>>>>>> + *   Port (ethdev) handle
>>>>>>> + *
>>>>>>> + * @param[inout] features
>>>>>>> + *   Feature selection buffer
>>>>>>> + *
>>>>>>> + * @return
>>>>>>> + *   Negative errno value on error, zero otherwise  */ typedef
>>>>>>> +int (*eth_rx_meta_negotiate_t)(struct rte_eth_dev *dev,
>>>>>>> +                       uint64_t *features);
>>>>>>> +
>>>>>>>     /**
>>>>>>>      * @internal A structure containing the functions exported by
>>>>>>> an Ethernet driver.
>>>>>>>      */
>>>>>>> @@ -949,6 +965,9 @@ struct eth_dev_ops {
>>>>>>>
>>>>>>>         eth_representor_info_get_t representor_info_get;
>>>>>>>         /**< Get representor info. */
>>>>>>> +
>>>>>>> +    eth_rx_meta_negotiate_t rx_meta_negotiate;
>>>>>>> +    /**< Negotiate delivery of specific parts of Rx meta data. */
>>>>>>>     };
>>>>>>>
>>>>>>>     /**
>>>>>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>>>>>> index daf5ca9242..49cb84d64c 100644
>>>>>>> --- a/lib/ethdev/rte_ethdev.c
>>>>>>> +++ b/lib/ethdev/rte_ethdev.c
>>>>>>> @@ -6310,6 +6310,31 @@ rte_eth_representor_info_get(uint16_t
>>>>>>> port_id,
>>>>>>>         return eth_err(port_id, (*dev->dev_ops-
>>>>>>>> representor_info_get)(dev, info));  }
>>>>>>>
>>>>>>> +int
>>>>>>> +rte_eth_rx_meta_negotiate(uint16_t port_id, uint64_t *features) {
>>>>>>> +    struct rte_eth_dev *dev;
>>>>>>> +
>>>>>>> +    RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>>>>>> +    dev = &rte_eth_devices[port_id];
>>>>>>> +
>>>>>>> +    if (dev->data->dev_configured != 0) {
>>>>>>> +        RTE_ETHDEV_LOG(ERR,
>>>>>>> +            "The port (id=%"PRIu16") is already configured\n",
>>>>>>> +            port_id);
>>>>>>> +        return -EBUSY;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    if (features == NULL) {
>>>>>>> +        RTE_ETHDEV_LOG(ERR, "Invalid features (NULL)\n");
>>>>>>> +        return -EINVAL;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops-
>>> rx_meta_negotiate,
>>>>>>> -ENOTSUP);
>>>>>>> +    return eth_err(port_id,
>>>>>>> +               (*dev->dev_ops->rx_meta_negotiate)(dev,
>>>>>>> +features)); }
>>>>>>> +
>>>>>>>     RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
>>>>>>>
>>>>>>>     RTE_INIT(ethdev_init_telemetry) diff --git
>>>>>>> a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
>>>>>>> 1da37896d8..8467a7a362 100644
>>>>>>> --- a/lib/ethdev/rte_ethdev.h
>>>>>>> +++ b/lib/ethdev/rte_ethdev.h
>>>>>>> @@ -4888,6 +4888,51 @@ __rte_experimental  int
>>>>>>> rte_eth_representor_info_get(uint16_t port_id,
>>>>>>>                      struct rte_eth_representor_info *info);
>>>>>>>
>>>>>>> +/** The ethdev sees flagged packets if there are flows with
>>>>>>> +action FLAG. */ #define RTE_ETH_RX_META_USER_FLAG
>> (UINT64_C(1) <<
>>>>>>> +0)
>>>>>>> +
>>>>>>> +/** The ethdev sees mark IDs in packets if there are flows with
>>>>>>> +action MARK. */ #define RTE_ETH_RX_META_USER_MARK
>>>> (UINT64_C(1) <<
>>>>>>> +1)
>>>>>>> +
>>>>>>> +/** The ethdev detects missed packets if there are "tunnel_set"
>>>>>>> +flows in use. */ #define RTE_ETH_RX_META_TUNNEL_ID
>> (UINT64_C(1)
>>>> <<
>>>>>>> +2)
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * @warning
>>>>>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>>>>>> + *
>>>>>>> + * Negotiate delivery of specific parts of Rx meta data.
>>>>>>> + *
>>>>>>> + * 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.
>>>>>>> + *
>>>>>>> + * If this API is unsupported, the application should gracefully
>>>>>>> ignore that.
>>>>>>> + *
>>>>>>> + * @param port_id
>>>>>>> + *   Port (ethdev) identifier
>>>>>>> + *
>>>>>>> + * @param[inout] features
>>>>>>> + *   Feature selection buffer
>>>>>>> + *
>>>>>>> + * @return
>>>>>>> + *   - (-EBUSY) if the port can't handle this in its current
>>>>>>> +state;
>>>>>>> + *   - (-ENOTSUP) if the method itself is not supported by the
>>>>>>> +PMD;
>>>>>>> + *   - (-ENODEV) if *port_id* is invalid;
>>>>>>> + *   - (-EINVAL) if *features* is NULL;
>>>>>>> + *   - (-EIO) if the device is removed;
>>>>>>> + *   - (0) on success
>>>>>>> + */
>>>>>>> +__rte_experimental
>>>>>>> +int rte_eth_rx_meta_negotiate(uint16_t port_id, uint64_t
>>>>>>> +*features);
>>>>>>
>>>>>> I don't think meta is the best name since we also have meta item
>>>>>> and the word meta can be used in other cases.
>>>>>
>>>>> I'm no expert in naming. What could be a better term for this?
>>>>> Personally, I'd rather not perceive "meta" the way you describe.
>>>>> It's not just "meta". It's "rx_meta", and the flags supplied with
>>>>> this API provide enough context to explain what it's all about.
>>>>
>>>> Thinking overnight about it I'd suggest full "metadata".
>>>> Yes, it will name a bit longer, but less confusing versus term META
>>>> already used in flow API.
>>>>
>>> Following my above comments, I think it should be part of the new API
>>> but in any case what about rx_flow_action_negotiate?
>>
>> See my thoughts above. It makes no sense to negotiate *support for
>> actions*. Existing "rte_flow_validate()" already does that job. The new
>> "negotiate Rx metadata* API is all about *delivery* of metadata which is
>> supposed to be *already* set for the packets *inside* the NIC. So, we
>> negotiate *delivery from the NIC to the host*. Nothing more.
>>
> Agree with your comment but then maybe we should go to the register
> approach just like metadata?

Don't you mean "registering mbuf dynamic field / flag" by any chance? 
Even if it's technically possible, this may complicate the API contract 
because the key idea here is to demand that the application negotiate 
metadata delivery at the earliest step possible (before configuring the 
port), whilst a dynamic field / flag can be (theoretically) registered 
at any time. But, of course, feel free to elaborate on your idea.

We should make sure that we all reach an agreement.

> 
> Best,
> Ori
>>>
>>>> Andrew.
>>> Best,
>>> Ori
>>>
>>
>> --
>> Ivan M

-- 
Ivan M

  reply	other threads:[~2021-10-03 17:30 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 [this message]
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
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=06d5d165-a9e0-ecc6-74b5-20a77a88e301@oktetlabs.ru \
    --to=ivan.malov@oktetlabs.ru \
    --cc=amoreton@xilinx.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --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
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).