[v5,2/5] ethdev: add new attributes to hairpin config
Checks
Commit Message
To support two ports hairpin mode and keep the backward compatibility
for the application, two new attribute members of the hairpin queue
configuration structure will be added.
`tx_explicit` means if the application itself will insert the TX part
flow rules. If not set, PMD will insert the rules implicitly.
`manual_bind` means if the hairpin TX queue and peer RX queue will be
bound automatically during the device start stage.
Different TX and RX queue pairs could have different values, but it
is highly recommended that all paired queues between one egress and
its peer ingress ports have the same values, in order not to bring
any chaos to the system. The actual support of these attribute
parameters will be checked and decided by the PMD drivers.
In the single port hairpin, if both are zero without any setting, the
behavior will remain the same as before. It means that no bind API
needs to be called and no TX flow rules need to be inserted manually
by the application.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
v4: squash document update and more info for the two new attributes
v2: optimize the structure and remove unused macros
---
doc/guides/prog_guide/rte_flow.rst | 3 +++
doc/guides/rel_notes/release_20_11.rst | 6 ++++++
lib/librte_ethdev/rte_ethdev.c | 8 ++++----
lib/librte_ethdev/rte_ethdev.h | 27 ++++++++++++++++++++++++++-
4 files changed, 39 insertions(+), 5 deletions(-)
Comments
15/10/2020 07:35, Bing Zhao:
> To support two ports hairpin mode and keep the backward compatibility
> for the application, two new attribute members of the hairpin queue
> configuration structure will be added.
>
> `tx_explicit` means if the application itself will insert the TX part
> flow rules. If not set, PMD will insert the rules implicitly.
> `manual_bind` means if the hairpin TX queue and peer RX queue will be
> bound automatically during the device start stage.
>
> Different TX and RX queue pairs could have different values, but it
> is highly recommended that all paired queues between one egress and
> its peer ingress ports have the same values, in order not to bring
> any chaos to the system. The actual support of these attribute
> parameters will be checked and decided by the PMD drivers.
>
> In the single port hairpin, if both are zero without any setting, the
> behavior will remain the same as before. It means that no bind API
> needs to be called and no TX flow rules need to be inserted manually
> by the application.
>
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> ---
> v4: squash document update and more info for the two new attributes
> v2: optimize the structure and remove unused macros
> ---
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Minor comments below.
> struct rte_eth_hairpin_conf {
> - uint16_t peer_count; /**< The number of peers. */
> + uint32_t peer_count:16; /**< The number of peers. */
> +
> + /**
> + * Explicit TX flow rule mode. One hairpin pair of queues should have
> + * the same attribute. The actual support depends on the PMD.
The second sentence should be on a separate line.
About the third sentence, implementation is always PMD-specific.
PMD will reject the not supported conf, as usual.
I think this comment is not needed in the API description.
> + *
> + * - When set, the user should be responsible for inserting the hairpin
> + * TX part flows and removing them.
> + * - When clear, the PMD will try to handle the TX part of the flows,
> + * e.g., by splitting one flow into two parts.
> + */
> + uint32_t tx_explicit:1;
> +
> + /**
> + * Manually bind hairpin queues. One hairpin pair of queues should have
> + * the same attribute. The actual support depends on the PMD.
Same here
> + *
> + * - When set, to enable hairpin, the user should call the hairpin bind
> + * API after all the queues are set up properly and the ports are
> + * started. Also, the hairpin unbind API should be called accordingly
> + * before stopping a port that with hairpin configured.
> + * - When clear, the PMD will try to enable the hairpin with the queues
> + * configured automatically during port start.
> + */
> + uint32_t manual_bind:1;
> + uint32_t reserved:14; /**< Reserved bits. */
> struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
> };
Hi Thomas,
All comments are addressed and thanks a lot for the reviewing.
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, October 15, 2020 6:46 PM
> To: Bing Zhao <bingz@nvidia.com>
> Cc: Ori Kam <orika@nvidia.com>; ferruh.yigit@intel.com;
> arybchenko@solarflare.com; mdr@ashroe.eu; nhorman@tuxdriver.com;
> bernard.iremonger@intel.com; beilei.xing@intel.com;
> wenzhuo.lu@intel.com; dev@dpdk.org
> Subject: Re: [PATCH v5 2/5] ethdev: add new attributes to hairpin
> config
>
> External email: Use caution opening links or attachments
>
>
> 15/10/2020 07:35, Bing Zhao:
> > To support two ports hairpin mode and keep the backward
> compatibility
> > for the application, two new attribute members of the hairpin
> queue
> > configuration structure will be added.
> >
> > `tx_explicit` means if the application itself will insert the TX
> part
> > flow rules. If not set, PMD will insert the rules implicitly.
> > `manual_bind` means if the hairpin TX queue and peer RX queue will
> be
> > bound automatically during the device start stage.
> >
> > Different TX and RX queue pairs could have different values, but
> it is
> > highly recommended that all paired queues between one egress and
> its
> > peer ingress ports have the same values, in order not to bring any
> > chaos to the system. The actual support of these attribute
> parameters
> > will be checked and decided by the PMD drivers.
> >
> > In the single port hairpin, if both are zero without any setting,
> the
> > behavior will remain the same as before. It means that no bind API
> > needs to be called and no TX flow rules need to be inserted
> manually
> > by the application.
> >
> > Signed-off-by: Bing Zhao <bingz@nvidia.com>
> > Acked-by: Ori Kam <orika@nvidia.com>
> > ---
> > v4: squash document update and more info for the two new
> attributes
> > v2: optimize the structure and remove unused macros
> > ---
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
>
> Minor comments below.
>
> > struct rte_eth_hairpin_conf {
> > - uint16_t peer_count; /**< The number of peers. */
> > + uint32_t peer_count:16; /**< The number of peers. */
> > +
> > + /**
> > + * Explicit TX flow rule mode. One hairpin pair of queues
> should have
> > + * the same attribute. The actual support depends on the PMD.
>
> The second sentence should be on a separate line.
>
> About the third sentence, implementation is always PMD-specific.
> PMD will reject the not supported conf, as usual.
> I think this comment is not needed in the API description.
>
> > + *
> > + * - When set, the user should be responsible for inserting
> the hairpin
> > + * TX part flows and removing them.
> > + * - When clear, the PMD will try to handle the TX part of
> the flows,
> > + * e.g., by splitting one flow into two parts.
> > + */
> > + uint32_t tx_explicit:1;
> > +
> > + /**
> > + * Manually bind hairpin queues. One hairpin pair of queues
> should have
> > + * the same attribute. The actual support depends on the PMD.
>
> Same here
>
> > + *
> > + * - When set, to enable hairpin, the user should call the
> hairpin bind
> > + * API after all the queues are set up properly and the
> ports are
> > + * started. Also, the hairpin unbind API should be called
> accordingly
> > + * before stopping a port that with hairpin configured.
> > + * - When clear, the PMD will try to enable the hairpin with
> the queues
> > + * configured automatically during port start.
> > + */
> > + uint32_t manual_bind:1;
> > + uint32_t reserved:14; /**< Reserved bits. */
> > struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
> > };
>
>
@@ -2592,6 +2592,9 @@ set, unpredictable value will be seen depending on driver implementation. For
loopback/hairpin packet, metadata set on Rx/Tx may or may not be propagated to
the other path depending on HW capability.
+In hairpin case with TX explicit flow mode, metadata could (not mandatory) be
+used to connect the RX and TX flows if it can be propagated from RX to TX path.
+
.. _table_rte_flow_action_set_meta:
.. table:: SET_META
@@ -70,6 +70,7 @@ New Features
* **Updated the ethdev library to support hairpin between two ports.**
New APIs are introduced to support binding / unbinding 2 ports hairpin.
+ Hairpin TX part flow rules can be inserted explicitly.
* **Updated Broadcom bnxt driver.**
@@ -355,6 +356,11 @@ ABI Changes
* ``ethdev`` internal functions are marked with ``__rte_internal`` tag.
+ * ``struct rte_eth_hairpin_conf`` has two new members:
+
+ * ``uint32_t tx_explicit:1;``
+ * ``uint32_t manual_bind:1;``
+
Known Issues
------------
@@ -2004,13 +2004,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_rx_2_tx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Rx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_rx_2_tx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Rx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Rx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
@@ -2175,13 +2175,13 @@ struct rte_eth_dev *
}
if (conf->peer_count > cap.max_tx_2_rx) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: <= %hu",
+ "Invalid value for number of peers for Tx queue(=%u), should be: <= %hu",
conf->peer_count, cap.max_tx_2_rx);
return -EINVAL;
}
if (conf->peer_count == 0) {
RTE_ETHDEV_LOG(ERR,
- "Invalid value for number of peers for Tx queue(=%hu), should be: > 0",
+ "Invalid value for number of peers for Tx queue(=%u), should be: > 0",
conf->peer_count);
return -EINVAL;
}
@@ -1045,7 +1045,32 @@ struct rte_eth_hairpin_peer {
* A structure used to configure hairpin binding.
*/
struct rte_eth_hairpin_conf {
- uint16_t peer_count; /**< The number of peers. */
+ uint32_t peer_count:16; /**< The number of peers. */
+
+ /**
+ * Explicit TX flow rule mode. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, the user should be responsible for inserting the hairpin
+ * TX part flows and removing them.
+ * - When clear, the PMD will try to handle the TX part of the flows,
+ * e.g., by splitting one flow into two parts.
+ */
+ uint32_t tx_explicit:1;
+
+ /**
+ * Manually bind hairpin queues. One hairpin pair of queues should have
+ * the same attribute. The actual support depends on the PMD.
+ *
+ * - When set, to enable hairpin, the user should call the hairpin bind
+ * API after all the queues are set up properly and the ports are
+ * started. Also, the hairpin unbind API should be called accordingly
+ * before stopping a port that with hairpin configured.
+ * - When clear, the PMD will try to enable the hairpin with the queues
+ * configured automatically during port start.
+ */
+ uint32_t manual_bind:1;
+ uint32_t reserved:14; /**< Reserved bits. */
struct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];
};