[PATCH v2] drivers: invalidate dangling MAE flow action FW resource IDs
When reinserting a flow (on port restart, for instance)
FW resource IDs found in the action set specification
need to be invalidated so that the new (reallocated)
FW resource IDs can be accepted by libefx again.
Fixes: 1bbd1ec2348a ("net/sfc: support action VXLAN encap in MAE backend")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andy Moreton
Tested-by: Denis Pryazhennikov
---
v2: squashed 1/2 and 2/2 of the previous version as per Ferruh's request
drivers/common/sfc_efx/base/efx.h | 14 ++
drivers/common/sfc_efx/base/efx_impl.h | 4
drivers/common/sfc_efx/base/efx_mae.c | 15 +++
drivers/common/sfc_efx/version.map | 1 +
drivers/net/sfc/sfc_mae.c | 2 ++
5 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/common/sfc_efx/base/efx.h
b/drivers/common/sfc_efx/base/efx.h
index f4fa88f169..49e29dcc1c 100644
--- a/drivers/common/sfc_efx/base/efx.h
+++ b/drivers/common/sfc_efx/base/efx.h
@@ -4748,6 +4748,20 @@ efx_mae_action_set_fill_in_counter_id(
__inefx_mae_actions_t *spec,
__inconst efx_counter_t *counter_idp);
+/*
+ * Clears dangling FW object IDs (counter ID, for instance) in
+ * the action set specification. Useful for adapter restarts,
+ * when all MAE objects need to be reallocated by the driver.
+ *
+ * This method only clears the IDs in the specification.
+ * The driver is still responsible for keeping the IDs
+ * separately and freeing them when stopping the port.
+ */
+LIBEFX_API
+extern void
+efx_mae_action_set_clear_fw_rsrc_ids(
+ __inefx_mae_actions_t *spec);
+
/* Action set ID */
typedef struct efx_mae_aset_id_s {
uint32_t id;
diff --git a/drivers/common/sfc_efx/base/efx_impl.h
b/drivers/common/sfc_efx/base/efx_impl.h
index 9a5d465fa0..45e99d01c5 100644
--- a/drivers/common/sfc_efx/base/efx_impl.h
+++ b/drivers/common/sfc_efx/base/efx_impl.h
@@ -1800,6 +1800,10 @@ typedef struct efx_mae_action_vlan_push_s {
uint16_temavp_tci_be;
} efx_mae_action_vlan_push_t;
+/*
+ * Helper efx_mae_action_set_clear_fw_rsrc_ids() is responsible
+ * to initialise every field in this structure to INVALID value.
+ */
typedef struct efx_mae_actions_rsrc_s {
efx_mae_mac_id_temar_dst_mac_id;
efx_mae_mac_id_temar_src_mac_id;
diff --git a/drivers/common/sfc_efx/base/efx_mae.c
b/drivers/common/sfc_efx/base/efx_mae.c
index 7732d2..4c33471f28 100644
--- a/drivers/common/sfc_efx/base/efx_mae.c
+++ b/drivers/common/sfc_efx/base/efx_mae.c
@@ -1394,10 +1394,7 @@ efx_mae_action_set_spec_init(
goto fail1;
}
- spec->ema_rsrc.emar_dst_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_src_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
- spec->ema_rsrc.emar_counter_id.id = EFX_MAE_RSRC_ID_INVALID;
+ efx_mae_action_set_clear_fw_rsrc_ids(spec);
/*
* Helpers which populate v2 actions must reject them when v2 is not
@@ -3027,6 +3024,16 @@ efx_mae_action_set_fill_in_counter_id(
return (rc);
}
+ void
+efx_mae_action_set_clear_fw_rsrc_ids(
+ __inefx_mae_actions_t *spec)
+{
+ spec->ema_rsrc.emar_dst_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_src_mac_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_eh_id.id = EFX_MAE_RSRC_ID_INVALID;
+ spec->ema_rsrc.emar_counter_id.id = EFX_MAE_RSRC_ID_INVALID;
+}
+
__checkReturn efx_rc_t
efx_mae_counters_alloc(
__inefx_nic_t *enp,
diff --git a/drivers/common/sfc_efx/version.map
b/drivers/common/sfc_efx/version.map
index aabc354118..d9b04a611d 100644
--- a/drivers/common/sfc_efx/version.map
+++ b/drivers/common/sfc_efx/version.map
@@ -89,6 +89,7 @@ INTERNAL {
efx_mae_action_rule_insert;
efx_mae_action_rule_remove;
efx_mae_action_set_alloc;
+ efx_mae_action_set_clear_fw_rsrc_ids;
efx_mae_action_set_fill_in_counter_id;
efx_mae_action_set_fill_in_dst_mac_id;
efx_mae_action_set_fill_in_eh_id;
diff --git a/drivers/net/sfc/sfc_mae.c b/drivers/net/sfc/sfc_mae.c
index e5e9257998..60b9fdc290 100644
--- a/drivers/net/sfc/sfc_mae.c
+++ b/drivers/net/sfc/sfc_mae.c
@@ -1180,6 +1180,8 @@ sfc_mae_action_set_disable(struct sfc_adapter *sa,
}
if (fw_rsrc->refcnt == 1) {
+ efx_mae_action_set_clear_fw_rsrc_ids(action_set->spec);
+
rc = efx_mae_action_set_free(sa->nic, &fw_rsrc->aset_id);
if (rc == 0) {
sfc_dbg(sa, "disabled action_set=%p with AS_ID=0x%08x",
--
2.17.1
RE: [PATCH] maintainers: add maintainers to Nvidia net mlx5
Hi > -Original Message- > From: Suanming Mou > Sent: Friday, May 19, 2023 3:33 AM > > > -Original Message- > > From: Matan Azrad > > Sent: Wednesday, May 17, 2023 3:43 PM > > To: NBU-Contact-Thomas Monjalon (EXTERNAL) > > Cc: dev@dpdk.org > > Subject: [PATCH] maintainers: add maintainers to Nvidia net mlx5 > > > > Add Ori Kam and Suanming Mou to the mainterners list of the Nvidia > network > > mlx5 PMD. > > > > Signed-off-by: Matan Azrad > Acked-by: Suanming Mou > Acked-by: Ori Kam
RE: [PATCH v2 2/5] doc: fix blank line in asynchronous operations description
Hi Michael,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, May 18, 2023 8:40 PM
>
> The asynchronous operations description inside "Generic flow API
> (rte_flow)" documentation, adds some bullets to describe asynchronous
> operations behavior.
>
> Before the first bullet, miss a blank line causing it to look a regular
> text line.
>
> This patch adds the blank line.
>
> Fixes: 197e820c6685 ("ethdev: bring in async queue-based flow rules
> operations")
> Cc: akozy...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Michael Baum
> ---
> doc/guides/prog_guide/rte_flow.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index e7faa368a1..76e69190fc 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -3702,6 +3702,7 @@ Asynchronous operations
> ---
>
> Flow rules management can be done via special lockless flow management
> queues.
> +
> - Queue operations are asynchronous and not thread-safe.
>
> - Operations can thus be invoked by the app's datapath,
> --
> 2.25.1
Acked-by: Ori Kam
Best,
Ori
RE: [PATCH v2 1/5] doc: fix blank lines in modify field action description
Hi Michael,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, May 18, 2023 8:40 PM
>
> The modify field action description inside "Generic flow API (rte_flow)"
> documentation, lists all operations supported for a destination field.
> In addition, it lists the values supported for a encapsulation level
> field.
>
> Before the lists, in both cases, miss a blank line causing them to look
> regular text lines.
>
> This patch adds the blank lines.
>
> Fixes: 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
> Cc: akozy...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Michael Baum
> ---
> doc/guides/prog_guide/rte_flow.rst | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 32fc45516a..e7faa368a1 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2917,20 +2917,23 @@ The immediate value
> ``RTE_FLOW_FIELD_VALUE`` (or a pointer to it
> ``RTE_FLOW_FIELD_START`` is used to point to the beginning of a packet.
> See ``enum rte_flow_field_id`` for the list of supported fields.
>
> -``op`` selects the operation to perform on a destination field.
> +``op`` selects the operation to perform on a destination field:
> +
> - ``set`` copies the data from ``src`` field to ``dst`` field.
> - ``add`` adds together ``dst`` and ``src`` and stores the result into
> ``dst``.
> -- ``sub`` subtracts ``src`` from ``dst`` and stores the result into ``dst``
> +- ``sub`` subtracts ``src`` from ``dst`` and stores the result into ``dst``.
>
> ``width`` defines a number of bits to use from ``src`` field.
>
> ``level`` is used to access any packet field on any encapsulation level
> -as well as any tag element in the tag array.
> -- ``0`` means the default behaviour. Depending on the packet type, it can
> -mean outermost, innermost or anything in between.
> +as well as any tag element in the tag array:
> +
> +- ``0`` means the default behaviour. Depending on the packet type,
> + it can mean outermost, innermost or anything in between.
> - ``1`` requests access to the outermost packet encapsulation level.
> - ``2`` and subsequent values requests access to the specified packet
> -encapsulation level, from outermost to innermost (lower to higher values).
> + encapsulation level, from outermost to innermost (lower to higher
> values).
> +
> For the tag array (in case of multiple tags are supported and present)
> ``level`` translates directly into the array index.
>
> --
> 2.25.1
Acked-by: Ori Kam
Best,
Ori
RE: [PATCH v2 3/5] doc: fix wrong indentation in RSS action description
Hi Michael,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, May 18, 2023 8:40 PM
> To: dev@dpdk.org
>
> The RSS action description inside "Generic flow API (rte_flow)"
> documentation, lists the values supported for a encapsulation level
> field.
>
> For "2" value, it uses 3 spaces as an indentation instead of 2 after
> line breaking, causing the first line to be bold.
>
> This patch updates the number of spaces in the indentation.
>
> Fixes: 18aee2861a1f ("ethdev: add encap level to RSS flow API action")
> Cc: adrien.mazarg...@6wind.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Michael Baum
> ---
> doc/guides/prog_guide/rte_flow.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 76e69190fc..25b57bf86d 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1954,8 +1954,8 @@ Also, regarding packet encapsulation ``level``:
>level.
>
> - ``2`` and subsequent values request RSS to be performed on the specified
> - inner packet encapsulation level, from outermost to innermost (lower to
> - higher values).
> + inner packet encapsulation level, from outermost to innermost (lower to
> + higher values).
>
> Values other than ``0`` are not necessarily supported.
>
> --
> 2.25.1
Acked-by: Ori Kam
Best,
Ori
RE: [PATCH v2 4/5] ethdev: add GENEVE TLV option modification support
Hi Michael, > -Original Message- > From: Michael Baum > Sent: Thursday, May 18, 2023 8:40 PM > > Add modify field support for GENEVE option fields: > - "RTE_FLOW_FIELD_GENEVE_OPT_TYPE" > - "RTE_FLOW_FIELD_GENEVE_OPT_CLASS" > - "RTE_FLOW_FIELD_GENEVE_OPT_DATA" > > Each GENEVE TLV option is identified by both its "class" and "type", so > 2 new fields were added to "rte_flow_action_modify_data" structure to > help specify which option to modify. > > To get room for those 2 new fields, the "level" field move to use > "uint8_t" which is more than enough for encapsulation level. > This patch also reduces all modify field encapsulation level "fully > masked" initializations to use UINT8_MAX instead of UINT32_MAX. > This change avoids compilation warning caused by this API changing. > > Signed-off-by: Michael Baum > --- Acked-by: Ori Kam Best, Ori
RE: [PATCH v2 5/5] ethdev: add MPLS header modification support
Hi Michael,
> -Original Message-
> From: Michael Baum
> Sent: Thursday, May 18, 2023 8:40 PM
>
> Add support for MPLS modify header using "RTE_FLOW_FIELD_MPLS" id.
>
> Since MPLS heaser might appear more the one time in inner/outer/tunnel,
> a new field was added to "rte_flow_action_modify_data" structure in
> addition to "level" field.
> The "tag_index" field is the index of the header inside encapsulation
> level. It is used for modify multiple MPLS headers in same encapsulation
> level.
>
> This addition enables to modify multiple VLAN headers too, so the
> description of "RTE_FLOW_FIELD_VLAN_" was updated.
>
> Signed-off-by: Michael Baum
> ---
[Snip]
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index ec812de335..591e43b5ac 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2925,8 +2925,7 @@ See ``enum rte_flow_field_id`` for the list of
> supported fields.
>
> ``width`` defines a number of bits to use from ``src`` field.
>
> -``level`` is used to access any packet field on any encapsulation level
> -as well as any tag element in the tag array:
> +``level`` is used to access any packet field on any encapsulation level:
>
> - ``0`` means the default behaviour. Depending on the packet type,
>it can mean outermost, innermost or anything in between.
> @@ -2934,8 +2933,9 @@ as well as any tag element in the tag array:
> - ``2`` and subsequent values requests access to the specified packet
>encapsulation level, from outermost to innermost (lower to higher values).
>
> -For the tag array (in case of multiple tags are supported and present)
> -``level`` translates directly into the array index.
> +``tag_index`` is the index of the header inside encapsulation level.
> +It is used for modify either ``VLAN`` or ``MPLS`` or ``TAG`` headers which
> +multiple of them might be supported in same encapsulation level.
>
This is an API change and must be documented as such in the release notes.
I suggest to avoid breaking working apps that it will be documented that
for this release when using tag the PMD will look at level and tag_id
If both equal to 0 --> the requested tag is zero
If tag_id == 0 and level != 0 PMD will selected the tag based on level, but
will output a warning
If tag_id != 0 and level == 0 PMD will select the tag based on the tag_id
> ``type`` is used to specify (along with ``class_id``) the Geneve option which
> is being modified.
> @@ -3011,7 +3011,9 @@ and provide immediate value 0x85XX.
>
> +=+
> ==+
> | ``field`` | ID: packet field, mark, meta, tag, immediate, pointer
>|
>
> +-+--+
> - | ``level`` | encapsulation level of a packet field or tag array
> index |
> + | ``level`` | encapsulation level of a packet field
>|
> +
> +-+--+
> + | ``tag_index`` | tag index inside encapsulation level
>|
>
> +-+--+
> | ``type``| geneve option type
>|
>
> +-+--+
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index f30d4b033f..34e536d662 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -3740,8 +3740,8 @@ enum rte_flow_field_id {
> RTE_FLOW_FIELD_START = 0, /**< Start of a packet. */
> RTE_FLOW_FIELD_MAC_DST, /**< Destination MAC
> Address. */
> RTE_FLOW_FIELD_MAC_SRC, /**< Source MAC Address. */
> - RTE_FLOW_FIELD_VLAN_TYPE, /**< 802.1Q Tag Identifier. */
> - RTE_FLOW_FIELD_VLAN_ID, /**< 802.1Q VLAN Identifier.
> */
> + RTE_FLOW_FIELD_VLAN_TYPE, /**< VLAN Tag Identifier. */
> + RTE_FLOW_FIELD_VLAN_ID, /**< VLAN Identifier. */
> RTE_FLOW_FIELD_MAC_TYPE,/**< EtherType. */
> RTE_FLOW_FIELD_IPV4_DSCP, /**< IPv4 DSCP. */
> RTE_FLOW_FIELD_IPV4_TTL,/**< IPv4 Time To Live. */
> @@ -3775,7 +3775,8 @@ enum rte_flow_field_id {
> RTE_FLOW_FIELD_HASH_RESULT, /**< Hash result. */
> RTE_FLOW_FIELD_GENEVE_OPT_TYPE, /**< GENEVE option type */
> RTE_FLOW_FIELD_GENEVE_OPT_CLASS,/**< GENEVE option class */
> - RTE_FLOW_FIELD_GENEVE_OPT_DATA /**< GENEVE option data */
> + RTE_FLOW_FIELD_GENEVE_OPT_DATA, /**< GENEVE option
> data */
> + RTE_FLOW_FIELD_MPLS /**< MPLS header. */
> };
>
> /**
> @@ -3789,7 +3790,7 @@ struct rte_flow_action_modify_data {
> RTE_STD_C11
> union {
> struct {
> - /** Encapsulation level or tag index or flex item
> handle
RE: [PATCH v3] ethdev: add flow rule actions update API
Hi Alexander, > -Original Message- > From: Alexander Kozyrev > Sent: Friday, May 19, 2023 12:49 AM > > Introduce the new rte_flow_update() API allowing users > to update the action list in the already existing rule. > Flow rules can be updated now without the need to destroy > the rule first and create a new one instead. > A single API call ensures that no packets are lost by > guaranteeing atomicity and flow state correctness. > The rte_flow_async_update() is added as well. > The matcher is not updated, only the action list is. > > Signed-off-by: Alexander Kozyrev > --- Acked-by: Ori Kam Best, Ori
RE: [EXT] [PATCH] ethdev: fix asynchronous destroy and push tracepoints
Hi Ankur,
> -Original Message-
> From: Ankur Dwivedi
> Sent: Friday, May 19, 2023 8:21 AM
>
> >The rte_flow_async_destroy() and rte_flow_push() API is intended to be as
> >fast as possible and tracepoints for these functions must be marked as fast-
> >path tracepoints.
> >
> >Fixes: 6679cf21d608 ("ethdev: add trace points")
> >
> >Signed-off-by: Alexander Kozyrev
>
> Acked-by: Ankur Dwivedi
> >---
Acked-by: Ori Kam
Best,
Ori
RE: [PATCH v1 4/4] bus/pci: add VFIO sparse mmap support
Hi,
I will add errno print in patch v3.
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday, May 15, 2023 11:53 PM
> To: Li, Miao
> Cc: dev@dpdk.org; sk...@marvell.com; tho...@monjalon.net;
> david.march...@redhat.com; ferruh.yi...@amd.com; Xia, Chenbo
> ; Cao, Yahui ; Burakov, Anatoly
>
> Subject: Re: [PATCH v1 4/4] bus/pci: add VFIO sparse mmap support
>
> On Mon, 15 May 2023 06:47:00 +
> Miao Li wrote:
>
> > + map_addr = pci_map_resource(addr,
> vfio_dev_fd,
> > + bar->offset + sparse->offset, sparse-
> >size,
> > + RTE_MAP_FORCE_ADDRESS);
> > + if (map_addr == NULL) {
> > + munmap(bar_addr, bar->size);
> > + RTE_LOG(ERR, EAL, "Failed to map pci
> BAR%d\n",
> > + bar_index);
>
> If mmap() fails then printing errno would help diagnose why.
RE: [PATCH v1 4/4] bus/pci: add VFIO sparse mmap support
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday, May 15, 2023 11:53 PM
> To: Li, Miao
> Cc: dev@dpdk.org; sk...@marvell.com; tho...@monjalon.net;
> david.march...@redhat.com; ferruh.yi...@amd.com; Xia, Chenbo
> ; Cao, Yahui ; Burakov, Anatoly
>
> Subject: Re: [PATCH v1 4/4] bus/pci: add VFIO sparse mmap support
>
> On Mon, 15 May 2023 06:47:00 +
> Miao Li wrote:
>
> > + map_addr = pci_map_resource(addr, vfio_dev_fd,
> > + bar->offset + sparse->offset,
> > sparse->size,
> > + RTE_MAP_FORCE_ADDRESS);
> > + if (map_addr == NULL) {
> > + munmap(bar_addr, bar->size);
> > + RTE_LOG(ERR, EAL, "Failed to map pci
> BAR%d\n",
> > + bar_index);
>
> If mmap() fails then printing errno would help diagnose why.
Thanks for your review! It seems errno will be printed in function
pci_map_resource() when mmap() fails. So I guess we don't need it here?
Thanks,
Chenbo
RE: seeking community input on adapting DPDK to P4Runtime backend
> -Original Message- > From: Honnappa Nagarahalli > Sent: Thursday, May 18, 2023 10:46 PM > To: Zhang, Qi Z ; Ori Kam ; > dev@dpdk.org > Cc: techbo...@dpdk.org; Richardson, Bruce ; > Burakov, Anatoly ; Wiles, Keith > ; Liang, Cunming ; Wu, > Jingjing ; Zhang, Helin ; > Mcnamara, John ; Xu, Rosen > ; nd ; nd > Subject: RE: seeking community input on adapting DPDK to P4Runtime > backend > > > > > > > > > Hi Zhang, > > > > > > rte_flow is an excellent candidate for implementing P4. > > > We and some internal tests that shows great promise in this regard. > > > > > > I would be very happy to supply any needed information and have > > > discussion on how to continue with this project. > > > > Thank you Ori! Please check my following comments > > > > Regards > > Qi > > > > > > > > Please see inline detailed answers. > > > > > > Best, > > > Ori Kam > > > > > > > > > > > > > > > > -Original Message- > > > > From: Zhang, Qi Z > > > > Sent: Monday, May 8, 2023 9:40 AM > > > > Subject: seeking community input on adapting DPDK to P4Runtime > > > backend > > > > > > > > Hi: > > > > > > > > Our team is currently working on developing a DPDK PMD for a P4- > > > > programmed network controller, based on customer feedback to > > > > integrate DPDK into the P4Runtime backend .[https://p4.org/p4- > > > > spec/p4runtime/main/P4Runtime-Spec.html] > > > > > > > > (*) However, we are facing challenges in adapting DPDK's rte_flow > > > > API to the P4Runtime API, primarily due to the transition from a > > > > table-based API with fields of arbitrary bits width at arbitrary > > > > offset to a protocol-based API (more detail be described in > > > > post-script). > > > > > > > > We are seeking suggestions and best practices from the open-source > > > > community to help us with this integration. Specifically, we are > > > > interested in > > > > learning: > > > > > > > > (*) If anyone has previously attempted to map rte_flow to P4-based > > > devices. > > > > > > We did try successfully. > > > > > > > (*) Thoughts on how to map from table-based matching to > > > > protocol-based matching like in rte_flow. > > > > > > Rte_flow is table based (groups), now with the introduction of > > > template API rte_flow is even more table based (we added the concept > > > of tables) which are just what > > > p4 requires. > > > > Yes, the rte_flow template can be used to map a sequence of patterns > > to a P4 table and a sequence of actions to a P4 action. However, Using > > a fixed rte_flow template can be problematic when handling different > > P4 programs in the same driver. To provide more flexibility, the > > mapping of patterns and actions can be externalized into a > > configuration file or part of the firmware can be learned from driver, > > allowing for customization based on the specific requirements of each > > P4 pipeline. actually we have enabled this approach in order to > accommodate different P4 programs. > > > > However, an alternative approach to consider is whether it would be > > feasible to directly expose the P4 table and action names or IDs to > > the application, rather than relying on rte_flow templates. This > > approach offers several potential > > benefits: > > > > Integration with P4runtime Backend: By exposing the P4 table and > > action names or IDs directly, DPDK could be easily integrated as a > > P4runtime backend. This eliminates the need for translation from the > > P4runtime API to rte_flow templates in the application, simplifying the > integration process. > > > > Elimination of Manual Mapping: Exposing the P4 table and action names > > or IDs to the application would remove the requirement for the > > engineering team to manually map each pipeline to specific rte_flow > > templates. This is particularly beneficial in cases where hardware > > vendors provide customers with a toolchain to create their own P4 > > pipelines but do not necessarily own the P4 programs. By eliminating > > the dependency on rte_flow templates, this approach reduces complexity > in using DPDK as the driver. > > > > To be more specific, the proposed API for exposing P4 table and action > > names or IDs directly to the application could be as follows: > > > > /* Get the table info */ > > struct rte_p4_table_info tbl_info; > > rte_p4_table_info_get_by_name(port_id, "decap_vxlan_tcp_table", > > &tbl_info); > > > > /* Create the key */ > > struct rte_p4_table_key *key; > > rte_p4_table_key_create(port_id, tbl_info->id, &key); > > > > /* Set the key fields */ > > rte_p4_table_key_field_set_by_name(port_id, key, "wire_port", > > &wire_port, 2); rte_p4_table_key_field_set_by_name(port_id, key, > > "tun_ip_src", &tun_ip_src, 4); > > rte_p4_table_key_field_set_by_name(port_id, key, "tun_ip_dst", > > &tun_ip_dst, 4); rte_p4_table_key_field_set_by_name(port_id, > > key, "vni", &vni, 3); rte_p4_table_key_field_set_by_name(port_id, key, > > "ipv4_src", &ipv4_src, 4); rte_p4_table_key_field_set_by_name(port_id, > > key, "i
RE: seeking community input on adapting DPDK to P4Runtime backend
> -Original Message- > From: Ori Kam > Sent: Thursday, May 18, 2023 10:34 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: techbo...@dpdk.org; Richardson, Bruce ; > Burakov, Anatoly ; Wiles, Keith > ; Liang, Cunming ; Wu, > Jingjing ; Zhang, Helin ; > Mcnamara, John ; Xu, Rosen > > Subject: RE: seeking community input on adapting DPDK to P4Runtime > backend > > Hi Zhang, > > I think we both want the same thing and share the same basic concepts. > > PSB, some answers, > > Best, > Ori > > > > -Original Message- > > From: Zhang, Qi Z > > Sent: Thursday, May 18, 2023 1:33 PM > > > > > > > > > -Original Message- > > > From: Ori Kam > > > Sent: Wednesday, May 17, 2023 11:19 PM > > > To: Zhang, Qi Z ; dev@dpdk.org > > > Cc: techbo...@dpdk.org; Richardson, Bruce > > ; > > > Burakov, Anatoly ; Wiles, Keith > > > ; Liang, Cunming ; > > > Wu, Jingjing ; Zhang, Helin > > > ; Mcnamara, John ; > > > Xu, Rosen > > > Subject: RE: seeking community input on adapting DPDK to P4Runtime > > > backend > > > > > > Hi Zhang, > > > > > > rte_flow is an excellent candidate for implementing P4. > > > We and some internal tests that shows great promise in this regard. > > > > > > I would be very happy to supply any needed information and have > > > discussion on how to continue with this project. > > > > Thank you Ori! Please check my following comments > > > > Regards > > Qi > > > > > > > > Please see inline detailed answers. > > > > > > Best, > > > Ori Kam > > > > > > > > > > > > > > > > -Original Message- > > > > From: Zhang, Qi Z > > > > Sent: Monday, May 8, 2023 9:40 AM > > > > Subject: seeking community input on adapting DPDK to P4Runtime > > > backend > > > > > > > > Hi: > > > > > > > > Our team is currently working on developing a DPDK PMD for a P4- > > > > programmed network controller, based on customer feedback to > > integrate > > > > DPDK into the P4Runtime backend .[https://p4.org/p4- > > > > spec/p4runtime/main/P4Runtime-Spec.html] > > > > > > > > (*) However, we are facing challenges in adapting DPDK's rte_flow > > > > API to the P4Runtime API, primarily due to the transition from a > > > > table-based API with fields of arbitrary bits width at arbitrary > > > > offset to a protocol-based API (more detail be described in > > > > post-script). > > > > > > > > We are seeking suggestions and best practices from the open-source > > > > community to help us with this integration. Specifically, we are > > > > interested in > > > > learning: > > > > > > > > (*) If anyone has previously attempted to map rte_flow to P4-based > > > devices. > > > > > > We did try successfully. > > > > > > > (*) Thoughts on how to map from table-based matching to protocol- > > based > > > > matching like in rte_flow. > > > > > > Rte_flow is table based (groups), now with the introduction of > > > template > > API > > > rte_flow is even more table based (we added the concept of tables) > > > which are just what > > > p4 requires. > > > > Yes, the rte_flow template can be used to map a sequence of patterns > > to a > > P4 table and a sequence of actions to a P4 action. However, Using a > > fixed rte_flow template can be problematic when handling different P4 > > programs in the same driver. To provide more flexibility, the mapping > > of patterns and actions can be externalized into a configuration file > > or part of the firmware can be learned from driver, allowing for > > customization based on the specific requirements of each P4 pipeline. > > actually we have enabled this approach in order to accommodate different > P4 programs. > > > > However, an alternative approach to consider is whether it would be > > feasible to directly expose the P4 table and action names or IDs to > > the application, rather than relying on rte_flow templates. This > > approach offers several potential benefits: > > > > Integration with P4runtime Backend: By exposing the P4 table and > > action names or IDs directly, DPDK could be easily integrated as a > > P4runtime backend. This eliminates the need for translation from the > > P4runtime API to rte_flow templates in the application, simplifying the > integration process. > > > > Elimination of Manual Mapping: Exposing the P4 table and action names > > or IDs to the application would remove the requirement for the > > engineering team to manually map each pipeline to specific rte_flow > > templates. This is particularly beneficial in cases where hardware > > vendors provide customers with a toolchain to create their own P4 > > pipelines but do not necessarily own the P4 programs. By eliminating > > the dependency on rte_flow templates, this approach reduces complexity > in using DPDK as the driver. > > > > To be more specific, the proposed API for exposing P4 table and action > > names or IDs directly to the application could be as follows: > > > > /* Get the table info */ > > struct rte_p4_table_info tbl_info; > > rte_p4_table_info_get_by_name(port_id, "decap_vxlan_tcp_table
RE: [PATCH v2 3/3] examples/l3fwd-graph: add IPv6 lookup and rewrite support
Hi Amit, Please look into build failure. http://mails.dpdk.org/archives/test-report/2023-May/396241.html Thanks & Regards Sunil Kumar Kori > -Original Message- > From: Amit Prakash Shukla > Sent: Thursday, May 18, 2023 9:27 PM > To: Jerin Jacob Kollanukkaran ; Kiran Kumar > Kokkilagadda ; Nithin Kumar Dabilpuram > > Cc: dev@dpdk.org; Sunil Kumar Kori ; Amit Prakash > Shukla > Subject: [PATCH v2 3/3] examples/l3fwd-graph: add IPv6 lookup and rewrite > support > > From: Sunil Kumar Kori > > Similar to ipv4, to support IPv6 lookup and rewrite node routes and rewrite > data needs to be added. > > Patch adds routes for ipv6 to validate ip6_lookup node and rewrite data to > validate ip6_rewrite node. > > Signed-off-by: Sunil Kumar Kori > Signed-off-by: Amit Prakash Shukla > --- > v2: > - Performance related changes > > doc/guides/sample_app_ug/l3_forward_graph.rst | 40 ++ > examples/l3fwd-graph/main.c | 77 ++- > 2 files changed, 98 insertions(+), 19 deletions(-) > [snipped] > 2.25.1
[PATCH] test/mbuf: fix the forked process segment fault
Access of any memory in the hugepage shared file-backed area will trigger
an unexpected forked child process segment fault. The root cause is DPDK
doesn't support fork model [1] (calling rte_eal_init() before fork()).
Forked child process can't be treated as a secondary process.
Hence fix it by avoiding fork and doing verification in the main process.
[1] https://mails.dpdk.org/archives/dev/2018-July/108106.html
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Jia He
Signed-off-by: Ruifeng Wang
---
app/test/test_mbuf.c | 50 +---
1 file changed, 14 insertions(+), 36 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 8d8d3b9386..efac01806b 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -1167,38 +1167,16 @@ test_failing_mbuf_sanity_check(struct rte_mempool
*pktmbuf_pool)
return TEST_SKIPPED;
}
#else
-
-#include
-#include
-#include
-#include
-
-/* use fork() to test mbuf errors panic */
-static int
-verify_mbuf_check_panics(struct rte_mbuf *buf)
+/* Verify if mbuf can pass the check */
+static bool
+mbuf_check_pass(struct rte_mbuf *buf)
{
- int pid;
- int status;
+ const char *reason;
- pid = fork();
+ if (rte_mbuf_check(buf, 1, &reason) == 0)
+ return true;
- if (pid == 0) {
- struct rlimit rl;
-
- /* No need to generate a coredump when panicking. */
- rl.rlim_cur = rl.rlim_max = 0;
- setrlimit(RLIMIT_CORE, &rl);
- rte_mbuf_sanity_check(buf, 1); /* should panic */
- exit(0); /* return normally if it doesn't panic */
- } else if (pid < 0) {
- printf("Fork Failed\n");
- return -1;
- }
- wait(&status);
- if(status == 0)
- return -1;
-
- return 0;
+ return false;
}
static int
@@ -1215,19 +1193,19 @@ test_failing_mbuf_sanity_check(struct rte_mempool
*pktmbuf_pool)
return -1;
printf("Checking good mbuf initially\n");
- if (verify_mbuf_check_panics(buf) != -1)
+ if (!mbuf_check_pass(buf))
return -1;
printf("Now checking for error conditions\n");
- if (verify_mbuf_check_panics(NULL)) {
+ if (mbuf_check_pass(NULL)) {
printf("Error with NULL mbuf test\n");
return -1;
}
badbuf = *buf;
badbuf.pool = NULL;
- if (verify_mbuf_check_panics(&badbuf)) {
+ if (mbuf_check_pass(&badbuf)) {
printf("Error with bad-pool mbuf test\n");
return -1;
}
@@ -1235,7 +1213,7 @@ test_failing_mbuf_sanity_check(struct rte_mempool
*pktmbuf_pool)
if (RTE_IOVA_IN_MBUF) {
badbuf = *buf;
rte_mbuf_iova_set(&badbuf, 0);
- if (verify_mbuf_check_panics(&badbuf)) {
+ if (mbuf_check_pass(&badbuf)) {
printf("Error with bad-physaddr mbuf test\n");
return -1;
}
@@ -1243,21 +1221,21 @@ test_failing_mbuf_sanity_check(struct rte_mempool
*pktmbuf_pool)
badbuf = *buf;
badbuf.buf_addr = NULL;
- if (verify_mbuf_check_panics(&badbuf)) {
+ if (mbuf_check_pass(&badbuf)) {
printf("Error with bad-addr mbuf test\n");
return -1;
}
badbuf = *buf;
badbuf.refcnt = 0;
- if (verify_mbuf_check_panics(&badbuf)) {
+ if (mbuf_check_pass(&badbuf)) {
printf("Error with bad-refcnt(0) mbuf test\n");
return -1;
}
badbuf = *buf;
badbuf.refcnt = UINT16_MAX;
- if (verify_mbuf_check_panics(&badbuf)) {
+ if (mbuf_check_pass(&badbuf)) {
printf("Error with bad-refcnt(MAX) mbuf test\n");
return -1;
}
--
2.25.1
[Bug 1235] [dpdk-23.07]basic_4k_pages_cbdma: start dpdk-testpmd with dmas and `--no-huge ` parameters failed
https://bugs.dpdk.org/show_bug.cgi?id=1235 Bug ID: 1235 Summary: [dpdk-23.07]basic_4k_pages_cbdma: start dpdk-testpmd with dmas and `--no-huge ` parameters failed Product: DPDK Version: 23.07 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: weix.l...@intel.com Target Milestone: --- [Environment] DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads 23.07.0-rc0 Other software versions: N/A OS: Ubuntu 22.04.2 LTS/Linux 5.15.45-051545-generic Compiler: gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) Hardware platform: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz NIC hardware: N/A NIC firmware: N/A [Test Setup] Steps to reproduce List the steps to reproduce the issue. 1.Apply the DMA related local patch, and then build DPDK. the local patch in the attachment. 2.Bind 1 DMA channel to vfio-pci driver: dpdk-devbind.py --force --bind=vfio-pci :00:01.0 3.Start dpdk-testpmd as the following command: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-9 -n 8 -a :00:01.0 --file-prefix=vhost \ --no-huge -m 1024 \ --vdev 'net_vhost0,iface=./vhost-net0,client=1,queues=1,dmas=[txq0@:00:01.0]' \ -- -i --nb-cores=1 --txd=1024 --rxd=1024 --rxq=1 --txq=1 4.Check start dpdk-testpmd successed or failed. Show the output from the previous commands. root@dut245:~/dpdk# x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-9 -n 8 -a :00:01.0 --file-prefix=vhost --no-huge -m 1024 --vdev 'net_vhost0,iface=./vhost-net0,client=1,queues=1,dmas=[txq0@:00:01.0]' -- -i --nb-cores=1 --txd=1024 --rxd=1024 --rxq=1 --txq=1 EAL: Detected CPU lcores: 128 EAL: Detected NUMA nodes: 2 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/vhost/mp_socket EAL: Selected IOVA mode 'VA' EAL: VFIO support initialized EAL: Using IOMMU type 1 (Type 1) EAL: Cannot set up DMA remapping, error 28 (No space left on device) EAL: :00:01.0 DMA remapping failed, error 28 (No space left on device) EAL: Requested device :00:01.0 cannot be used EAL: Bus (pci) probe failed. Fail to find DMA device :00:01.0. Failed to parse dmas vdev_probe(): failed to initialize net_vhost0 device EAL: Bus (vdev) probe failed. testpmd: No probed ethernet devices Interactive-mode selected Fail: input rxq (1) can't be greater than max_rx_queues (0) of port 0 EAL: Error - exiting with code: 1 Cause: rxq 1 invalid - must be >= 0 && <= 0 [Expected Result] Explain what is the expected result in text or as an example output: Start dpdk-testpmd successed and no error info. [Regression] Is this issue a regression: (Y) Version the regression was introduced: Specify git id if known. commit a399d7b5a994e335c446d4b15d7622d71dd8848c (HEAD -> main, origin/main, origin/HEAD) Author: Nipun Gupta Date: Wed Jan 4 10:49:36 2023 +0530 vfio: do not coalesce DMA mappings At the cleanup time when dma unmap is done, the Linux kernel VFIO driver does not allow unmap of individual segments which were coalesced together while creating the DMA map for type1 IOMMU mappings. So, this change updates the mapping of the memory segments (hugepages) on a per-page basis. Signed-off-by: Nipun Gupta Signed-off-by: Nikhil Agarwal Reviewed-by: Anatoly Burakov -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v2] drivers: invalidate dangling MAE flow action FW resource IDs
On 5/21/23 11:36, Ivan Malov wrote:
When reinserting a flow (on port restart, for instance)
FW resource IDs found in the action set specification
need to be invalidated so that the new (reallocated)
FW resource IDs can be accepted by libefx again.
Fixes: 1bbd1ec2348a ("net/sfc: support action VXLAN encap in MAE backend")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andy Moreton
Tested-by: Denis Pryazhennikov
Acked-by: Andrew Rybchenko
Re: [PATCH 01/20] mbuf: replace term sanity check
On 5/17/23 19:15, Stephen Hemminger wrote: The term sanity check is on the Tier 2 list of words that should be replaced. Signed-off-by: Stephen Hemminger Acked-by: Andrew Rybchenko
Re: [PATCH 11/20] net/sfc: remove term "sanity check"
On 5/17/23 19:15, Stephen Hemminger wrote: Remove term sanity check in comment. Signed-off-by: Stephen Hemminger Acked-by: Andrew Rybchenko
Re: [PATCH v3 01/19] mbuf: replace term sanity check
On 5/19/23 20:45, Stephen Hemminger wrote: Replace rte_mbuf_sanity_check() with rte_mbuf_verify() to match the similar macro RTE_VERIFY() in rte_debug.h The term sanity check is on the Tier 2 list of words that should be replaced. Signed-off-by: Stephen Hemminger Acked-by: Andrew Rybchenko
Re: [PATCH v3 10/19] net/sfc: remove term "sanity check"
On 5/19/23 20:46, Stephen Hemminger wrote: Remove term sanity check in comment. Signed-off-by: Stephen Hemminger Acked-by: Andrew Rybchenko
