Re: [PATCH] dma/dpaa2: set the vfa bit for rbp with vf
> Hi, > This patch fixed the issue of qdma route by port for PCIe VF. > "vfa" bit determines if "vfid" is valid or not. > Route by port is a kind of qdam transfer used for PCIe EP to access host by > PCIe address and PCIe function. Another kind of transfer to access host is by > PCIe address + PCIe outbound address. Thanks for the confirmation! Maybe you can now accept/merge the patch? Thanks
RE: [PATCH] dma/dpaa2: set the vfa bit for rbp with vf
> -Original Message- > From: Alvaro Karsz > Sent: Sunday, April 16, 2023 2:47 PM > To: Jun Yang ; Gagandeep Singh ; > Hemant Agrawal > Cc: dev@dpdk.org; David Marchand > Subject: Re: [PATCH] dma/dpaa2: set the vfa bit for rbp with vf > Importance: High > > > Hi, > > This patch fixed the issue of qdma route by port for PCIe VF. > > "vfa" bit determines if "vfid" is valid or not. > > Route by port is a kind of qdam transfer used for PCIe EP to access host by > PCIe address and PCIe function. Another kind of transfer to access host is by > PCIe address + PCIe outbound address. > > Thanks for the confirmation! > Maybe you can now accept/merge the patch? > > Thanks Acked-by: Hemant Agrawal
RE: [PATCH v2 1/6] bus/cdx: introduce cdx bus
> -Original Message-
> From: Yigit, Ferruh
> Sent: Friday, April 14, 2023 10:15 PM
> To: Gupta, Nipun ; dev@dpdk.org;
> tho...@monjalon.net; david.march...@redhat.com
> Cc: Anand, Harpreet ; Agarwal, Nikhil
>
> Subject: Re: [PATCH v2 1/6] bus/cdx: introduce cdx bus
>
> On 4/13/2023 2:26 PM, Nipun Gupta wrote:
> > CDX bus supports multiple type of devices, which can be
> > exposed to user-space via vfio-cdx.
> >
> > vfio-cdx provides the MMIO IO_MEMORY regions as well as the
> > DMA interface for the device (IOMMU).
> >
> > This support aims to enable the DPDK to support the cdx
> > devices in user-space using VFIO interface.
> >
> > Signed-off-by: Nipun Gupta
>
> <...>
>
> > +/* map a particular resource from a file */
> > +void *
> > +cdx_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
> > + int additional_flags)
> > +{
> > + void *mapaddr;
> > +
> > + /* Map the cdx MMIO memory resource of device */
> > + mapaddr = rte_mem_map(requested_addr, size,
> > + RTE_PROT_READ | RTE_PROT_WRITE,
> > + RTE_MAP_SHARED | additional_flags, fd, offset);
> > + if (mapaddr == NULL) {
> > + CDX_BUS_ERR("%s(): cannot map resource(%d, %p, 0x%zx,
> 0x%llx): %s (%p)",
> > + __func__, fd, requested_addr, size,
> > + (unsigned long long)offset,
>
> `checkpatches.sh` complains about '%l' usage, and 'offset' seems defined
> as 'off_t' type.
>
> As far as I can see 'off_t' is not part of C standard (but posix
> standard), and it is signed, also not clear if 32 bits or 64 bits.
>
> Since caller of this function already passes parameter with 'uint64_t'
> type, why not change the 'offset' type of this function to 'uint64_t'
> for simplification, and use 'PRIu64' format specifier?
Makes sense. Will update this in next respin.
RE: [PATCH v2 3/6] bus/cdx: add support for MSI
> -Original Message- > From: Yigit, Ferruh > Sent: Friday, April 14, 2023 10:15 PM > To: Gupta, Nipun ; dev@dpdk.org; > tho...@monjalon.net; david.march...@redhat.com > Cc: Anand, Harpreet ; Agarwal, Nikhil > > Subject: Re: [PATCH v2 3/6] bus/cdx: add support for MSI > > On 4/13/2023 2:27 PM, Nipun Gupta wrote: > > MSI's are exposed to the devices using VFIO (vfio-cdx). This > > patch uses the same to add support for MSI for the devices on > > the cdx bus. > > > > Signed-off-by: Nipun Gupta > > This commit also adds two new internal eal APIs and extends "struct > rte_intr_handle", can you please document this in the commit log? Sure. Will update.
RE: [PATCH v2 5/6] bus: enable cdx bus
> -Original Message- > From: Yigit, Ferruh > Sent: Friday, April 14, 2023 10:16 PM > To: Gupta, Nipun ; dev@dpdk.org; > tho...@monjalon.net; david.march...@redhat.com > Cc: Anand, Harpreet ; Agarwal, Nikhil > > Subject: Re: [PATCH v2 5/6] bus: enable cdx bus > > On 4/13/2023 2:27 PM, Nipun Gupta wrote: > > enable the compilation of cdx bus > > > > Signed-off-by: Nipun Gupta > > --- > > drivers/bus/meson.build | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build > > index 6d2520c543..a78b4283bf 100644 > > --- a/drivers/bus/meson.build > > +++ b/drivers/bus/meson.build > > @@ -3,6 +3,7 @@ > > > > drivers = [ > > 'auxiliary', > > +'cdx', > > 'dpaa', > > 'fslmc', > > 'ifpga', > > Why not squash this to the first patch? > > I think better to enable bus with the first patch and gradually expand > the feature, this way each patch is checked that it builds fine. > > There are cases some interim patches can't be built successfully, which > may required enabling after a few patches, but I think this is not the case. Sure, I will merge into the first patch. Compilation should be working there too. Thanks, Nipun
Re: [PATCH v3 06/11] eal: typedef cpu flag enum as int for msvc
10/04/2023 21:53, Tyler Retzlaff пишет:
On Mon, Apr 10, 2023 at 08:59:33PM +0100, Konstantin Ananyev wrote:
06/04/2023 01:45, Tyler Retzlaff пишет:
Forward declaration of a typedef is a non-standard extension and is not
supported by msvc. Use an int instead.
Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.
Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.
Signed-off-by: Tyler Retzlaff
---
lib/eal/include/generic/rte_cpuflags.h | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/eal/include/generic/rte_cpuflags.h
b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
/**
* Enumeration of all CPU features supported
*/
+#ifndef RTE_TOOLCHAIN_MSVC
__extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
Just curious what exactly MSVC doesn't support here?
Is that construction like:
enum rte_cpu_flag_t {};
enum rte_cpu_flag_t;
...
Or something else?
Forward declaration of an enum is non standard. It's probably only
allowed by gcc as an extension because gcc will make some kind of
implementation specific promise for it always to be `int` size by
default (assuming no other -foptions).
I understood that part, what is not clear to me from where we are
getting forward declarations?
As I remember the usual organization of arch specific rte_cpuflags.h:
/* type definition */
enum rte_cpu_flag_t {...};
/some other stuff */
#include "generic/rte_cpuflags.h"
Which contains 'enum rte_cpu_flag_t' type declaration.
But it doesn't look like a forward declaration to me.
Is there a place where we do include "generic/rte_cpuflags.h" directly
(not from arch specific header)?
If so. might be we should change it to include arch specific header instead?
If the enum was defined before reference it would probably be accepted
by msvc since it could 'see' the definition and know the integer width
in use.
/**
* Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
* flag name
* NULL if flag ID is invalid
*/
-__extension__
const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
/**
* Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
* 0 if flag is not available
* -ENOENT if flag is invalid
*/
-__extension__
int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
/**
* This function checks that the currently used CPU supports the CPU features
[PATCH v3] net/i40e: support enable/disable source pruning
VRRP advertisement packets are dropped on i40e PF device because
when a MAC address is added to a device, packets originating from
that MAC address are dropped.
This patch adds a PMD specific API to enable/disable source
pruning to fix above issue.
Bugzilla ID: 648
Fixes: 94b3c1a72507 ("net/i40e: move testpmd commands")
Fixes: bce83974ba2c ("net/i40e: set Tx loopback from PF")
Fixes: 96974a6600ec ("net/i40e: move private APIs to a specific file")
Fixes: 689bba33272d ("i40e: add VEB switching support")
Fixes: 440499cf5376 ("net/i40e: support floating VEB")
Fixes: ef4c16fd9148 ("net/i40e: refactor RSS flow")
Cc: sta...@dpdk.org
Signed-off-by: Mingjin Ye
---
v3: The i40e specific commands are moved to
drivers/net/i40e/i40e_testpmd.c.
---
drivers/net/i40e/i40e_ethdev.c | 43
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_testpmd.c | 88 +
drivers/net/i40e/rte_pmd_i40e.c | 20
drivers/net/i40e/rte_pmd_i40e.h | 17 +++
drivers/net/i40e/version.map| 1 +
6 files changed, 170 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index cb0070f94b..90d8e5a8bc 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5647,6 +5647,46 @@ i40e_enable_pf_lb(struct i40e_pf *pf)
hw->aq.asq_last_status);
}
+/* i40e_pf_set_source_prune
+ * @pf: pointer to the pf structure
+ * @on: Enable/disable source prune
+ *
+ * set source prune on pf
+ */
+int
+i40e_pf_set_source_prune(struct i40e_pf *pf, int on)
+{
+ struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+ struct i40e_vsi_context ctxt;
+ int ret;
+
+ memset(&ctxt, 0, sizeof(ctxt));
+ ctxt.seid = pf->main_vsi_seid;
+ ctxt.pf_num = hw->pf_id;
+ ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "cannot get pf vsi config, err %d, aq_err %d",
+ ret, hw->aq.asq_last_status);
+ return ret;
+ }
+ ctxt.flags = I40E_AQ_VSI_TYPE_PF;
+ ctxt.info.valid_sections =
+ rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
+ if (on)
+ ctxt.info.switch_id &=
+ ~rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
+ else
+ ctxt.info.switch_id |=
+ rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
+
+ ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
+ if (ret)
+ PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d",
+ hw->aq.asq_last_status);
+
+ return ret;
+}
+
/* Setup a VSI */
struct i40e_vsi *
i40e_vsi_setup(struct i40e_pf *pf,
@@ -5704,6 +5744,9 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
}
+ /* source prune is disabled to support VRRP in default*/
+ i40e_pf_set_source_prune(pf, 0);
+
vsi = rte_zmalloc("i40e_vsi", sizeof(struct i40e_vsi), 0);
if (!vsi) {
PMD_DRV_LOG(ERR, "Failed to allocate memory for vsi");
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 9b806d130e..6f65d5e0ac 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -1430,6 +1430,7 @@ int i40e_pf_calc_configured_queues_num(struct i40e_pf
*pf);
int i40e_pf_reset_rss_reta(struct i40e_pf *pf);
int i40e_pf_reset_rss_key(struct i40e_pf *pf);
int i40e_pf_config_rss(struct i40e_pf *pf);
+int i40e_pf_set_source_prune(struct i40e_pf *pf, int on);
int i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len);
int i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size);
int i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params);
diff --git a/drivers/net/i40e/i40e_testpmd.c b/drivers/net/i40e/i40e_testpmd.c
index 7be9fea5b0..b6ef5d6e42 100644
--- a/drivers/net/i40e/i40e_testpmd.c
+++ b/drivers/net/i40e/i40e_testpmd.c
@@ -2446,6 +2446,84 @@ static cmdline_parse_inst_t cmd_ptype_mapping_update = {
},
};
+/* *** configure source prune for port *** */
+struct cmd_config_src_prune_result {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t keyword;
+ cmdline_fixed_string_t port_all; /* valid if "allports" argument == 1 */
+ uint16_t port_id;/* valid if "allports" argument == 0 */
+ cmdline_fixed_string_t item;
+ cmdline_fixed_string_t enable;
+};
+
+static void cmd_config_pf_src_prune_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ void *allports)
+{
+ struct cmd_config_src_prune_result *res = parsed_result;
+ uint8_t enable;
+ uint16_t i;
+
+ if (!strcmp(res->enable, "on"))
+ enable = 1;
+ else
+ enable = 0;
+
+ /* all ports */
+ if (allports) {
+ RTE
[RFC v1 0/2] add IPv6 extenstion push remove
Add new rte actions to support push/remove IPv6 extension header. Rongwei Liu (2): ethdev: add IPv6 extension push remove action app/testpmd: add IPv6 extension push remove cli app/test-pmd/cmdline_flow.c| 443 - doc/guides/prog_guide/rte_flow.rst | 21 ++ lib/ethdev/rte_flow.c | 2 + lib/ethdev/rte_flow.h | 52 4 files changed, 517 insertions(+), 1 deletion(-) -- 2.27.0
[RFC v1 1/2] ethdev: add IPv6 extension push remove action
Add new rte_actions to push and remove the specific
type of IPv6 extension to and from original packets.
A new extension to be pushed should be the last extension
due to the next header awareness.
Remove can support the IPv6 extension in any position.
Signed-off-by: Rongwei Liu
---
doc/guides/prog_guide/rte_flow.rst | 21
lib/ethdev/rte_flow.c | 2 ++
lib/ethdev/rte_flow.h | 52 ++
3 files changed, 75 insertions(+)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 43e38839ae..6a7401c98a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3308,6 +3308,27 @@ and rte_mtr_policy_get() API respectively.
| ``policy`` | Meter policy object |
+--+--+
+Action: ``IPV6_EXT_PUSH``
+^
+
+Add an IPv6 extension into IPv6 header and its template is provided in
+its data buffer with the specific type as defined in the
+``rte_flow_action_ipv6_ext_push`` definition.
+
+This action modifies the payload of matched flows. The data supplied must
+be a valid extension in the specified type, it should be added the last one
+if preceding extension existed. When applied to the original packet the
+resulting packet must be a valid packet.
+
+Action: ``IPV6_EXT_REMOVE``
+^^^
+
+Remove an IPv6 extension whose type is provided in its type as defined in
+the ``rte_flow_action_ipv6_ext_remove``.
+
+This action modifies the payload of matched flow and the packet should be
+valid after removing.
+
Negative types
~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 26531ecb8e..4504bb3ae9 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -272,6 +272,8 @@ static const struct rte_flow_desc_data
rte_flow_desc_action[] = {
MK_FLOW_ACTION(SEND_TO_KERNEL, 0),
MK_FLOW_ACTION(QUOTA, sizeof(struct rte_flow_action_quota)),
MK_FLOW_ACTION(INDIRECT_LIST, 0),
+ MK_FLOW_ACTION(IPV6_EXT_PUSH, sizeof(struct
rte_flow_action_ipv6_ext_push)),
+ MK_FLOW_ACTION(IPV6_EXT_REMOVE, sizeof(struct
rte_flow_action_ipv6_ext_remove)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index dfad6d1af4..f5e0c22389 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3029,6 +3029,25 @@ enum rte_flow_action_type {
* RTE_FLOW_ACTION_TYPE_INDIRECT_LIST
*/
RTE_FLOW_ACTION_TYPE_INDIRECT_LIST,
+
+ /**
+* RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH
+*
+* Push IPv6 extension into IPv6 packet.
+*
+* @see struct rte_flow_action_ipv6_ext_push.
+*/
+ RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH,
+
+ /**
+* RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE
+*
+* Remove IPv6 extension from IPv6 packet whose type
+* is provided in its configuration buffer.
+*
+* @see struct rte_flow_action_ipv6_ext_remove.
+*/
+ RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE,
};
/**
@@ -3469,6 +3488,39 @@ struct rte_flow_action_vxlan_encap {
struct rte_flow_item *definition;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH
+ *
+ * Valid flow definition for RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH include:
+ *
+ * - IPV6_EXT TYPE / IPV6_EXT_HEADER_IN_TYPE / END
+ *
+ * size holds the number of bytes in @p data.
+ * The data must be added as the last IPv6 extension.
+ */
+struct rte_flow_action_ipv6_ext_push {
+ uint8_t *data; /**< IPv6 extension header data. */
+ size_t size; /**< Size of @p data. */
+ uint8_t type; /**< Type of IPv6 extension. */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE
+ *
+ * Valid flow definition for RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE include:
+ *
+ * - IPV6_EXT TYPE / END
+ */
+struct rte_flow_action_ipv6_ext_remove {
+ uint8_t type; /**< Type of IPv6 extension. */
+};
+
/**
* @warning
* @b EXPERIMENTAL: this structure may change without prior notice
--
2.27.0
[RFC v1 2/2] app/testpmd: add IPv6 extension push remove cli
Add command lines to generate IPv6 routing extension push and
remove patterns and follow the raw_encap/decap style.
Add the new actions to the action template parsing.
Generating the action patterns
1. IPv6 routing extension push
set ipv6_ext_push 1 ipv6_ext type is 43 /
ipv6_routing_ext ext_type is 4
ext_next_hdr is 17 ext_seg_left is 2 / end_set
2. IPv6 routing extension remove
set ipv6_ext_remove 1 ipv6_ext type is 43 / end_set
Specifying the action in the template
1. actions_template_id 1 template ipv6_ext_push index 1
2. actions_template_id 1 template ipv6_ext_remove index 1
Signed-off-by: Rongwei Liu
---
app/test-pmd/cmdline_flow.c | 443 +++-
1 file changed, 442 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88e6594c12..4ea1bd 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -78,6 +78,9 @@ enum index {
SET_RAW_INDEX,
SET_SAMPLE_ACTIONS,
SET_SAMPLE_INDEX,
+ SET_IPV6_EXT_REMOVE,
+ SET_IPV6_EXT_PUSH,
+ SET_IPV6_EXT_INDEX,
/* Top-level command. */
FLOW,
@@ -536,6 +539,8 @@ enum index {
ITEM_IB_BTH_PKEY,
ITEM_IB_BTH_DST_QPN,
ITEM_IB_BTH_PSN,
+ ITEM_IPV6_PUSH_REMOVE_EXT,
+ ITEM_IPV6_PUSH_REMOVE_EXT_TYPE,
/* Validate/create actions. */
ACTIONS,
@@ -721,6 +726,12 @@ enum index {
ACTION_SET_TCP_TP_DST,
ACTION_SET_TCP_TP_DST_TP_DST,
ACTION_IPSEC,
+ ACTION_IPV6_EXT_REMOVE,
+ ACTION_IPV6_EXT_REMOVE_INDEX,
+ ACTION_IPV6_EXT_REMOVE_INDEX_VALUE,
+ ACTION_IPV6_EXT_PUSH,
+ ACTION_IPV6_EXT_PUSH_INDEX,
+ ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -787,6 +798,42 @@ struct action_raw_decap_data {
uint16_t idx;
};
+/** Maximum data size in struct rte_flow_action_ipv6_ext_push. */
+#define ACTION_IPV6_EXT_PUSH_MAX_DATA 512
+#define IPV6_EXT_PUSH_CONFS_MAX_NUM 8
+
+/** Storage for struct rte_flow_action_ipv6_ext_push. */
+struct ipv6_ext_push_conf {
+ uint8_t data[ACTION_IPV6_EXT_PUSH_MAX_DATA];
+ size_t size;
+ uint8_t type;
+};
+
+struct ipv6_ext_push_conf ipv6_ext_push_confs[IPV6_EXT_PUSH_CONFS_MAX_NUM];
+
+/** Storage for struct rte_flow_action_ipv6_ext_push including external data.
*/
+struct action_ipv6_ext_push_data {
+ struct rte_flow_action_ipv6_ext_push conf;
+ uint8_t data[ACTION_IPV6_EXT_PUSH_MAX_DATA];
+ uint8_t type;
+ uint16_t idx;
+};
+
+/** Storage for struct rte_flow_action_ipv6_ext_remove. */
+struct ipv6_ext_remove_conf {
+ struct rte_flow_action_ipv6_ext_remove conf;
+ uint8_t type;
+};
+
+struct ipv6_ext_remove_conf ipv6_ext_remove_confs[IPV6_EXT_PUSH_CONFS_MAX_NUM];
+
+/** Storage for struct rte_flow_action_ipv6_ext_remove including external
data. */
+struct action_ipv6_ext_remove_data {
+ struct rte_flow_action_ipv6_ext_remove conf;
+ uint8_t type;
+ uint16_t idx;
+};
+
struct vxlan_encap_conf vxlan_encap_conf = {
.select_ipv4 = 1,
.select_vlan = 0,
@@ -2118,6 +2165,8 @@ static const enum index next_action[] = {
ACTION_SET_TCP_TP_SRC,
ACTION_SET_TCP_TP_DST,
ACTION_IPSEC,
+ ACTION_IPV6_EXT_REMOVE,
+ ACTION_IPV6_EXT_PUSH,
ZERO,
};
@@ -2326,6 +2375,18 @@ static const enum index action_raw_decap[] = {
ZERO,
};
+static const enum index action_ipv6_ext_remove[] = {
+ ACTION_IPV6_EXT_REMOVE_INDEX,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_ipv6_ext_push[] = {
+ ACTION_IPV6_EXT_PUSH_INDEX,
+ ACTION_NEXT,
+ ZERO,
+};
+
static const enum index action_set_tag[] = {
ACTION_SET_TAG_DATA,
ACTION_SET_TAG_INDEX,
@@ -2390,6 +2451,22 @@ static const enum index next_action_sample[] = {
ZERO,
};
+static const enum index item_ipv6_push_ext[] = {
+ ITEM_IPV6_PUSH_REMOVE_EXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_push_ext_type[] = {
+ ITEM_IPV6_PUSH_REMOVE_EXT_TYPE,
+ ZERO,
+};
+
+static const enum index item_ipv6_push_ext_header[] = {
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index action_modify_field_dst[] = {
ACTION_MODIFY_FIELD_DST_LEVEL,
ACTION_MODIFY_FIELD_DST_SUB_LEVEL,
@@ -2497,6 +2574,9 @@ static int parse_set_raw_encap_decap(struct context *,
const struct token *,
static int parse_set_sample_action(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
+static int parse_set_ipv6_ext_action(struct context *, const struct token *,
+const char *, unsigned int,
+void *, unsigned int);
static int parse_set_init(str
Re: [RFC 00/27] Add VDUSE support to Vhost library
On Fri, Apr 14, 2023 at 10:25 PM Ferruh Yigit wrote: > > On 4/14/2023 1:06 PM, Maxime Coquelin wrote: > > > > > > On 4/14/23 12:48, Ferruh Yigit wrote: > >> On 4/13/2023 8:59 AM, Maxime Coquelin wrote: > >>> Hi, > >>> > >>> On 4/13/23 09:08, Xia, Chenbo wrote: > > -Original Message- > > From: Morten Brørup > > Sent: Thursday, April 13, 2023 3:41 AM > > To: Maxime Coquelin ; Ferruh Yigit > > ; dev@dpdk.org; david.march...@redhat.com; Xia, > > Chenbo ; m...@redhat.com; f...@redhat.com; > > jasow...@redhat.com; Liang, Cunming ; Xie, > > Yongji > > ; echau...@redhat.com; epere...@redhat.com; > > amore...@redhat.com > > Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library > > > >> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > >> Sent: Wednesday, 12 April 2023 17.28 > >> > >> Hi Ferruh, > >> > >> On 4/12/23 13:33, Ferruh Yigit wrote: > >>> On 3/31/2023 4:42 PM, Maxime Coquelin wrote: > This series introduces a new type of backend, VDUSE, > to the Vhost library. > > VDUSE stands for vDPA device in Userspace, it enables > implementing a Virtio device in userspace and have it > attached to the Kernel vDPA bus. > > Once attached to the vDPA bus, it can be used either by > Kernel Virtio drivers, like virtio-net in our case, via > the virtio-vdpa driver. Doing that, the device is visible > to the Kernel networking stack and is exposed to userspace > as a regular netdev. > > It can also be exposed to userspace thanks to the > vhost-vdpa driver, via a vhost-vdpa chardev that can be > passed to QEMU or Virtio-user PMD. > > While VDUSE support is already available in upstream > Kernel, a couple of patches are required to support > network device type: > > https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc > > In order to attach the created VDUSE device to the vDPA > bus, a recent iproute2 version containing the vdpa tool is > required. > >>> > >>> Hi Maxime, > >>> > >>> Is this a replacement to the existing DPDK vDPA framework? What > >>> is the > >>> plan for long term? > >>> > >> > >> No, this is not a replacement for DPDK vDPA framework. > >> > >> We (Red Hat) don't have plans to support DPDK vDPA framework in our > >> products, but there are still contribution to DPDK vDPA by several > >> vDPA > >> hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is > >> going > >> to be deprecated soon. > > > > Ferruh's question made me curious... > > > > I don't know anything about VDUSE or vDPA, and don't use any of it, so > > consider me ignorant in this area. > > > > Is VDUSE an alternative to the existing DPDK vDPA framework? What are > > the > > differences, e.g. in which cases would an application developer (or > > user) > > choose one or the other? > > Maxime should give better explanation.. but let me just explain a bit. > > Vendors have vDPA HW that support vDPA framework (most likely in their > DPU/IPU > products). This work is introducing a way to emulate a SW vDPA > device in > userspace (DPDK), and this SW vDPA device also supports vDPA framework. > > So it's not an alternative to existing DPDK vDPA framework :) > >>> > >>> Correct. > >>> > >>> When using DPDK vDPA, the datapath of a Vhost-user port is offloaded to > >>> a compatible physical NIC (i.e. a NIC that implements Virtio rings > >>> support), the control path remains the same as a regular Vhost-user > >>> port, i.e. it provides a Vhost-user unix socket to the application (like > >>> QEMU or DPDK Virtio-user PMD). > >>> > >>> When using Kernel vDPA, the datapath is also offloaded to a vDPA > >>> compatible device, and the control path is managed by the vDPA bus. > >>> It can either be consumed by a Kernel Virtio device (here Virtio-net) > >>> when using Virtio-vDPA. In this case the device is exposed as a regular > >>> netdev and, in the case of Kubernetes, can be used as primary interfaces > >>> for the pods. > >>> Or it can be exposed to user-space via Vhost-vDPA, a chardev that can be > >>> seen as an alternative to Vhost-user sockets. In this case it can for > >>> example be used by QEMU or DPDK Virtio-user PMD. In Kubernetes, it can > >>> be used as a secondary interface. > >>> > >>> Now comes VDUSE. VDUSE is a Kernel vDPA device, but instead of being a > >>> physical device where the Virtio datapath is offloaded, the Virtio > >>> datapath is offloaded to a user-space application. With this series, a > >>> DPDK application, like OVS-DPDK for instance, can create VDUSE device > >>> and expose them either as regular netdev when binding them to
[PATCH v3 1/4] doc: announce new cpu flag added to rte_cpu_flag_t
A new flag RTE_CPUFLAG_MONITORX is added to rte_cpu_flag_t in DPDK 23.07 release to support monitorx instruction on EPYC processors. This results in ABI breakage for legacy apps. Signed-off-by: Sivaprasad Tummala --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index dcc1ca1696..831713983f 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -163,3 +163,6 @@ Deprecation Notices The new port library API (functions rte_swx_port_*) will gradually transition from experimental to stable status starting with DPDK 23.07 release. + +* eal/x86: The enum ``rte_cpu_flag_t`` will be extended with a new cpu flag + ``RTE_CPUFLAG_MONITORX`` to support monitorx instruction on EPYC processors. -- 2.34.1
[PATCH v3 2/4] eal: add x86 cpuid support for monitorx
Add a new CPUID flag to indicate support for monitorx instruction
on AMD EPYC processors.
Signed-off-by: Sivaprasad Tummala
---
lib/eal/x86/include/rte_cpuflags.h | 1 +
lib/eal/x86/rte_cpuflags.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/lib/eal/x86/include/rte_cpuflags.h
b/lib/eal/x86/include/rte_cpuflags.h
index 92e90fb6e0..d3e608533a 100644
--- a/lib/eal/x86/include/rte_cpuflags.h
+++ b/lib/eal/x86/include/rte_cpuflags.h
@@ -133,6 +133,7 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register
Intersection */
RTE_CPUFLAG_WAITPKG,/**< UMONITOR/UMWAIT/TPAUSE */
+ RTE_CPUFLAG_MONITORX, /**< MONITORX */
/* The last item */
RTE_CPUFLAG_NUMFLAGS, /**< This should always be the
last! */
diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b518251b..22f3bed412 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -133,6 +133,7 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(LAHF_SAHF, 0x8001, 0, RTE_REG_ECX, 0)
FEAT_DEF(LZCNT, 0x8001, 0, RTE_REG_ECX, 4)
+ FEAT_DEF(MONITORX, 0x8001, 0, RTE_REG_ECX, 29)
FEAT_DEF(SYSCALL, 0x8001, 0, RTE_REG_EDX, 11)
FEAT_DEF(XD, 0x8001, 0, RTE_REG_EDX, 20)
@@ -191,5 +192,7 @@ rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics
*intrinsics)
intrinsics->power_pause = 1;
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM))
intrinsics->power_monitor_multi = 1;
+ } else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_MONITORX)) {
+ intrinsics->power_monitor = 1;
}
}
--
2.34.1
[PATCH v3 3/4] eal: removed unnecessary checks in x86 power monitor APIs
current x86 power monitor implementation fails on platforms
with only monitor supported and not power_pause.
Signed-off-by: Sivaprasad Tummala
---
lib/eal/x86/rte_power_intrinsics.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/eal/x86/rte_power_intrinsics.c
b/lib/eal/x86/rte_power_intrinsics.c
index f749da9b85..6eb9e50807 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -30,6 +30,7 @@ __umwait_wakeup(volatile void *addr)
static bool wait_supported;
static bool wait_multi_supported;
+static bool monitor_supported;
static inline uint64_t
__get_umwait_val(const volatile void *p, const uint8_t sz)
@@ -81,7 +82,7 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
uint64_t cur_value;
/* prevent user from running this instruction if it's not supported */
- if (!wait_supported)
+ if (!monitor_supported)
return -ENOTSUP;
/* prevent non-EAL thread from using this API */
@@ -170,6 +171,8 @@ RTE_INIT(rte_power_intrinsics_init) {
wait_supported = 1;
if (i.power_monitor_multi)
wait_multi_supported = 1;
+ if (i.power_monitor)
+ monitor_supported = 1;
}
int
@@ -178,7 +181,7 @@ rte_power_monitor_wakeup(const unsigned int lcore_id)
struct power_wait_status *s;
/* prevent user from running this instruction if it's not supported */
- if (!wait_supported)
+ if (!monitor_supported)
return -ENOTSUP;
/* prevent buffer overrun */
--
2.34.1
[PATCH v3 4/4] power: amd power monitor support
mwaitx allows EPYC processors to enter a implementation dependent
power/performance optimized state (C1 state) for a specific period
or until a store to the monitored address range.
Signed-off-by: Sivaprasad Tummala
---
lib/eal/x86/rte_power_intrinsics.c | 77 +-
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/lib/eal/x86/rte_power_intrinsics.c
b/lib/eal/x86/rte_power_intrinsics.c
index 6eb9e50807..27055bab52 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -17,6 +17,60 @@ static struct power_wait_status {
volatile void *monitor_addr; /**< NULL if not currently sleeping */
} __rte_cache_aligned wait_status[RTE_MAX_LCORE];
+/**
+ * These functions uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+static void intel_umonitor(volatile void *addr)
+{
+ /* UMONITOR */
+ asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+ :
+ : "D"(addr));
+}
+
+static void intel_umwait(const uint64_t timeout)
+{
+ const uint32_t tsc_l = (uint32_t)timeout;
+ const uint32_t tsc_h = (uint32_t)(timeout >> 32);
+ /* UMWAIT */
+ asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+ : /* ignore rflags */
+ : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+}
+
+/**
+ * These functions uses MONITORX/MWAITX instructions and will enter C1 state.
+ * For more information about usage of these instructions, please refer to
+ * AMD64 Architecture Programmer’s Manual.
+ */
+static void amd_monitorx(volatile void *addr)
+{
+ /* MONITORX */
+ asm volatile(".byte 0x0f, 0x01, 0xfa;"
+ :
+ : "a"(addr),
+ "c"(0), /* no extensions */
+ "d"(0)); /* no hints */
+}
+
+static void amd_mwaitx(const uint64_t timeout)
+{
+ /* MWAITX */
+ asm volatile(".byte 0x0f, 0x01, 0xfb;"
+ : /* ignore rflags */
+ : "a"(0), /* enter C1 */
+ "c"(2), /* enable timer */
+ "b"(timeout));
+}
+
+static struct {
+ void (*mmonitor)(volatile void *addr);
+ void (*mwait)(const uint64_t timeout);
+} __rte_cache_aligned power_monitor_ops;
+
static inline void
__umwait_wakeup(volatile void *addr)
{
@@ -75,8 +129,6 @@ int
rte_power_monitor(const struct rte_power_monitor_cond *pmc,
const uint64_t tsc_timestamp)
{
- const uint32_t tsc_l = (uint32_t)tsc_timestamp;
- const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
const unsigned int lcore_id = rte_lcore_id();
struct power_wait_status *s;
uint64_t cur_value;
@@ -109,10 +161,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
* versions support this instruction natively.
*/
- /* set address for UMONITOR */
- asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
- :
- : "D"(pmc->addr));
+ /* set address for mmonitor */
+ power_monitor_ops.mmonitor(pmc->addr);
/* now that we've put this address into monitor, we can unlock */
rte_spinlock_unlock(&s->lock);
@@ -123,11 +173,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
if (pmc->fn(cur_value, pmc->opaque) != 0)
goto end;
- /* execute UMWAIT */
- asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
- : /* ignore rflags */
- : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
+ /* execute mwait */
+ power_monitor_ops.mwait(tsc_timestamp);
end:
/* erase sleep address */
@@ -173,6 +220,14 @@ RTE_INIT(rte_power_intrinsics_init) {
wait_multi_supported = 1;
if (i.power_monitor)
monitor_supported = 1;
+
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_MONITORX)) { /* AMD */
+ power_monitor_ops.mmonitor = &amd_monitorx;
+ power_monitor_ops.mwait = &amd_mwaitx;
+ } else { /* Intel */
+ power_monitor_ops.mmonitor = &intel_umonitor;
+ power_monitor_ops.mwait = &intel_umwait;
+ }
}
int
--
2.34.1
RE: [PATCH v3] eventdev/eth_rx: fix invalid memory access
Acked-by: Naga Harish K S V
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Friday, April 7, 2023 12:18 PM
> To: jer...@marvell.com; Naga Harish K, S V
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [PATCH v3] eventdev/eth_rx: fix invalid memory access
>
> From: Pavan Nikhilesh
>
> Rx adapter internal service structures are only initialized when non-internal
> port is added to the adapter.
> Check if Rx adapter service is initialized to determine if runtime set/get
> parameters are supported.
>
> Fixes: 3716f52186af ("eventdev/eth_rx: support runtime set/get
> parameters")
>
> Signed-off-by: Pavan Nikhilesh
> ---
> v3 Changes:
> --
> - Teardown queue when test is not supported.
>
> v2 Changes:
> --
> - Remove unused variables.
> - Fix spell check.
>
> app/test/test_event_eth_rx_adapter.c| 10 --
> lib/eventdev/rte_event_eth_rx_adapter.c | 24
> 2 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/app/test/test_event_eth_rx_adapter.c
> b/app/test/test_event_eth_rx_adapter.c
> index cfe6052d7e..52d146f97c 100644
> --- a/app/test/test_event_eth_rx_adapter.c
> +++ b/app/test/test_event_eth_rx_adapter.c
> @@ -1201,7 +1201,7 @@ adapter_intrq_instance_get(void) static int
> adapter_get_set_params(void)
> {
> - int err;
> + int err, rc;
> struct rte_event_eth_rx_adapter_runtime_params in_params;
> struct rte_event_eth_rx_adapter_runtime_params out_params;
> struct rte_event_eth_rx_adapter_queue_conf queue_config = {0};
> @@ -1230,6 +1230,10 @@ adapter_get_set_params(void)
> /* Case 1: Get the default value of mbufs processed by Rx adapter */
> err =
> rte_event_eth_rx_adapter_runtime_params_get(TEST_INST_ID,
> &out_params);
> + if (err == -ENOTSUP) {
> + rc = TEST_SKIPPED;
> + goto skip;
> + }
> TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>
> /* Case 2: Set max_nb_rx = 32 (=BATCH_SEIZE) */ @@ -1302,11
> +1306,13 @@ adapter_get_set_params(void)
> "Expected %u got %u",
> in_params.max_nb_rx, out_params.max_nb_rx);
>
> + rc = TEST_SUCCESS;
> +skip:
> err = rte_event_eth_rx_adapter_queue_del(TEST_INST_ID,
> TEST_ETHDEV_ID, 0);
> TEST_ASSERT(err == 0, "Expected 0 got %d", err);
>
> - return TEST_SUCCESS;
> + return rc;
> }
>
> static struct unit_test_suite event_eth_rx_tests = { diff --git
> a/lib/eventdev/rte_event_eth_rx_adapter.c
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index c1cd124002..a8a5564b65 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -3466,30 +3466,14 @@
> rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id, static int
> rxa_caps_check(struct event_eth_rx_adapter *rxa) {
> - uint16_t eth_dev_id;
> - uint32_t caps = 0;
> - int ret;
> -
> if (!rxa->nb_queues)
> return -EINVAL;
>
> - /* The eth_dev used is always of same type.
> - * Hence eth_dev_id is taken from first entry of poll array.
> - */
> - eth_dev_id = rxa->eth_rx_poll[0].eth_dev_id;
> - ret = rte_event_eth_rx_adapter_caps_get(rxa->eventdev_id,
> - eth_dev_id,
> - &caps);
> - if (ret) {
> - RTE_EDEV_LOG_ERR("Failed to get adapter caps edev %"
> PRIu8
> - "eth port %" PRIu16, rxa->eventdev_id, eth_dev_id);
> - return ret;
> - }
> -
> - if (caps & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT)
> - return -ENOTSUP;
> + /* Check if there is at least one non-internal ethernet port. */
> + if (rxa->service_inited)
> + return 0;
>
> - return 0;
> + return -ENOTSUP;
> }
>
> int
> --
> 2.25.1
Re: [PATCH] net/virtio-user: fix leak when initialisation fails
On 4/13/23 12:10, David Marchand wrote:
Caught with ASan.
If initialising a virtio_user port fails, we may leak the ifname passed
via a devargs.
Fixes: 4214a1b493f2 ("net/virtio-user: support changing tap interface name")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index f46a131b5c..744f3c30d2 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -696,11 +696,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char
*path, uint16_t queues,
dev->frontend_features = 0;
dev->unsupported_features = 0;
dev->backend_type = backend_type;
-
- if (*ifname) {
- dev->ifname = *ifname;
- *ifname = NULL;
- }
+ dev->ifname = *ifname;
if (virtio_user_dev_setup(dev) < 0) {
PMD_INIT_LOG(ERR, "(%s) backend set up fails", dev->path);
@@ -794,6 +790,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char
*path, uint16_t queues,
}
}
+ *ifname = NULL;
return 0;
notify_uninit:
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
