Hi Ori,
On 05/10/2021 15:03, Ori Kam wrote:
Hi Ivan,
Just a nit below.
-----Original Message-----
From: Ivan Malov <ivan.ma...@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.ma...@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
Reviewed-by: Andy Moreton <amore...@xilinx.com>
Acked-by: Ray Kinsella <m...@ashroe.eu>
Acked-by: Jerin Jacob <jer...@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.
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?
+ *
+ * @note
+ * The PMD is supposed to first consider enabling the requested feature set
+ * in its entirety. Only if it fails to do so, does it have the right to
+ * respond with a smaller set of the originally requested features.
+ *
+ * @note
+ * Return code (-ENOTSUP) does not necessarily mean that the requested
+ * features are unsupported. In this case, the application should just
+ * assume that these features can be used without prior negotiations.
+ *
+ * @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_metadata_negotiate(uint16_t port_id, uint64_t
+*features);
+
#include <rte_ethdev_core.h>
/**
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
7b1ed7f110..75656ff9f8 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -1904,6 +1904,10 @@ enum rte_flow_action_type {
* PKT_RX_FDIR_ID mbuf flags.
*
* See struct rte_flow_action_mark.
+ *
+ * One should negotiate mark delivery from the NIC to the PMD.
+ * @see rte_eth_rx_metadata_negotiate()
+ * @see RTE_ETH_RX_METADATA_USER_MARK
*/
RTE_FLOW_ACTION_TYPE_MARK,
@@ -1912,6 +1916,10 @@ enum rte_flow_action_type {
* sets the PKT_RX_FDIR mbuf flag.
*
* No associated configuration structure.
+ *
+ * One should negotiate flag delivery from the NIC to the PMD.
+ * @see rte_eth_rx_metadata_negotiate()
+ * @see RTE_ETH_RX_METADATA_USER_FLAG
*/
RTE_FLOW_ACTION_TYPE_FLAG,
@@ -4223,6 +4231,10 @@ rte_flow_tunnel_match(uint16_t port_id,
/**
* Populate the current packet processing state, if exists, for the given
mbuf.
*
+ * One should negotiate tunnel metadata delivery from the NIC to the HW.
+ * @see rte_eth_rx_metadata_negotiate()
+ * @see RTE_ETH_RX_METADATA_TUNNEL_ID
+ *
* @param port_id
* Port identifier of Ethernet device.
* @param[in] m
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
904bce6ea1..2e638c680e 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -247,6 +247,9 @@ EXPERIMENTAL {
rte_mtr_meter_policy_delete;
rte_mtr_meter_policy_update;
rte_mtr_meter_policy_validate;
+
+ # added in 21.11
+ rte_eth_rx_metadata_negotiate;
};
INTERNAL {
--
2.20.1
Best,
Ori
--
Ivan M
