[dpdk-dev] [PATCH 0/7] NXP DPAAx ethernet PMD changes
This patch series adds changes to dpaaX ethernet pmd 1. Basic Traffic Management support for shaper and scheduler 2. Support external buffer in Transmit side. 3. Optimize the SG packet handling 4. Add support APIs in DPDMUX (SRIOV equivalent for DPAA2) 5. Fix isssues Gagandeep Singh (1): net/dpaa2: add traffic management driver Hemant Agrawal (3): net/dpaa2: allocate SGT table from first segment net/dpaa: support external buffers in Tx net/dpaa2: add support to configure dpdmux max Rx frame len Nipun Gupta (1): net/dpaa2: support external buffers in Tx Rohit Raj (1): net/dpaa2: fix link get API implementation Youri Querry (1): bus/fslmc: fix to use ci value for qbman 5.0 drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 5 + drivers/bus/fslmc/qbman/qbman_portal.c | 14 +- drivers/net/dpaa/dpaa_rxtx.c| 29 +- drivers/net/dpaa/dpaa_rxtx.h| 8 +- drivers/net/dpaa2/dpaa2_ethdev.c| 35 +- drivers/net/dpaa2/dpaa2_ethdev.h| 5 + drivers/net/dpaa2/dpaa2_mux.c | 28 +- drivers/net/dpaa2/dpaa2_rxtx.c | 103 +++- drivers/net/dpaa2/dpaa2_tm.c| 626 drivers/net/dpaa2/dpaa2_tm.h| 32 ++ drivers/net/dpaa2/mc/dpni.c | 313 +++- drivers/net/dpaa2/mc/fsl_dpni.h | 210 +++- drivers/net/dpaa2/mc/fsl_dpni_cmd.h | 59 ++- drivers/net/dpaa2/meson.build | 3 +- drivers/net/dpaa2/rte_pmd_dpaa2.h | 18 +- drivers/net/dpaa2/version.map | 1 + 16 files changed, 1436 insertions(+), 53 deletions(-) create mode 100644 drivers/net/dpaa2/dpaa2_tm.c create mode 100644 drivers/net/dpaa2/dpaa2_tm.h -- 2.17.1
[dpdk-dev] [PATCH 7/7] net/dpaa2: add support to configure dpdmux max Rx frame len
This patch introduce a new pmd api, which can help the applications
to configure the max framelen for a given dpdmux interface
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa2/dpaa2_mux.c | 28 +++-
drivers/net/dpaa2/rte_pmd_dpaa2.h | 18 +-
drivers/net/dpaa2/version.map | 1 +
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_mux.c b/drivers/net/dpaa2/dpaa2_mux.c
index f8366e839e..b397d333d6 100644
--- a/drivers/net/dpaa2/dpaa2_mux.c
+++ b/drivers/net/dpaa2/dpaa2_mux.c
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright 2018-2020 NXP
+ * Copyright 2018-2021 NXP
*/
#include
@@ -205,6 +205,32 @@ rte_pmd_dpaa2_mux_flow_create(uint32_t dpdmux_id,
return NULL;
}
+int
+rte_pmd_dpaa2_mux_rx_frame_len(uint32_t dpdmux_id, uint16_t max_rx_frame_len)
+{
+ struct dpaa2_dpdmux_dev *dpdmux_dev;
+ int ret;
+
+ /* Find the DPDMUX from dpdmux_id in our list */
+ dpdmux_dev = get_dpdmux_from_id(dpdmux_id);
+ if (!dpdmux_dev) {
+ DPAA2_PMD_ERR("Invalid dpdmux_id: %d", dpdmux_id);
+ return -1;
+ }
+
+ ret = dpdmux_set_max_frame_length(&dpdmux_dev->dpdmux,
+ CMD_PRI_LOW, dpdmux_dev->token, max_rx_frame_len);
+ if (ret) {
+ DPAA2_PMD_ERR("DPDMUX:Unable to set mtu. check config %d", ret);
+ return ret;
+ }
+
+ DPAA2_PMD_INFO("dpdmux mtu set as %u",
+ DPAA2_MAX_RX_PKT_LEN - RTE_ETHER_CRC_LEN);
+
+ return ret;
+}
+
static int
dpaa2_create_dpdmux_device(int vdev_fd __rte_unused,
struct vfio_device_info *obj_info __rte_unused,
diff --git a/drivers/net/dpaa2/rte_pmd_dpaa2.h
b/drivers/net/dpaa2/rte_pmd_dpaa2.h
index ec8df75af9..7204a8f951 100644
--- a/drivers/net/dpaa2/rte_pmd_dpaa2.h
+++ b/drivers/net/dpaa2/rte_pmd_dpaa2.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright 2018-2020 NXP
+ * Copyright 2018-2021 NXP
*/
#ifndef _RTE_PMD_DPAA2_H
@@ -40,6 +40,22 @@ rte_pmd_dpaa2_mux_flow_create(uint32_t dpdmux_id,
struct rte_flow_item *pattern[],
struct rte_flow_action *actions[]);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * demultiplex interface max rx frame length configure
+ *
+ * @param dpdmux_id
+ *ID of the DPDMUX MC object.
+ * @param max_rx_frame_len
+ *maximum receive frame length (will be checked to be minimux of all dpnis)
+ *
+ */
+__rte_experimental
+int
+rte_pmd_dpaa2_mux_rx_frame_len(uint32_t dpdmux_id, uint16_t max_rx_frame_len);
+
/**
* @warning
* @b EXPERIMENTAL: this API may change, or be removed, without prior notice
diff --git a/drivers/net/dpaa2/version.map b/drivers/net/dpaa2/version.map
index 72d1b2b1c8..3c087c2423 100644
--- a/drivers/net/dpaa2/version.map
+++ b/drivers/net/dpaa2/version.map
@@ -2,6 +2,7 @@ EXPERIMENTAL {
global:
rte_pmd_dpaa2_mux_flow_create;
+ rte_pmd_dpaa2_mux_rx_frame_len;
rte_pmd_dpaa2_set_custom_hash;
};
--
2.17.1
Re: [dpdk-dev] [PATCH 2/2] test/crypto: support SSL/TLS way of cipher-auth operations
Hi Akhil and Fan, I'll send v2 moving SSL/TLS test cases to aes_chain_test_cases array. Thanks Tejasree > -Original Message- > From: Zhang, Roy Fan > Sent: Wednesday, January 20, 2021 8:04 PM > To: Akhil Goyal ; Tejasree Kondoj > ; Nicolau, Radu ; Trahe, > Fiona > Cc: Anoob Joseph ; Ankur Dwivedi > ; dev@dpdk.org > Subject: [EXT] RE: [PATCH 2/2] test/crypto: support SSL/TLS way of cipher- > auth operations > > External Email > > -- > Hi Akhil, > > I just did the check. QAT Raw API test did failed on newly added cases. > The patch needs to be updated - as all newly added tests are in > aes_cipheronly_test_cases array, where clearly they are chained algorithm > tests. > > But the problem is not the only reason that causes the test fail - I will > submit > a QAT PMD fix patch for that. > > Regards, > Fan > > > -Original Message- > > From: Akhil Goyal > > Sent: Tuesday, January 19, 2021 5:01 PM > > To: Tejasree Kondoj ; Nicolau, Radu > > ; Trahe, Fiona ; Zhang, > > Roy Fan > > Cc: Anoob Joseph ; Ankur Dwivedi > > ; dev@dpdk.org > > Subject: RE: [PATCH 2/2] test/crypto: support SSL/TLS way of > > cipher-auth operations > > > > Hi Tejasree, > > > > > Subject: [PATCH 2/2] test/crypto: support SSL/TLS way of cipher-auth > > operations > > > > > > Adding support for SSL/TLS way of cipher-auth operations order > > > - auth generation followed by encryption > > > - decryption followed by auth verify > > > > > > Signed-off-by: Tejasree Kondoj > > > --- > > > > With this patch the following existing case is failing on NXP > > platforms. Please check. > > > > 10) TestCase AES-128-CBC HMAC-SHA1 Encryption Digest Scatter Gather > > line > > 634 FAILED: Generated digest data not as expected > > > > Fiona/Fan, > > Could you please check this patch on intel platform? > > > > Regards, > > Akhil > >
Re: [dpdk-dev] [PATCH v5 3/3] PCI: don't use vfio ioctl call to access PIO resource
On 2021/1/13 0:58, Maxime Coquelin wrote: On 1/12/21 10:37 AM, Maxime Coquelin wrote: bus/pci: ... On 10/22/20 5:51 PM, 谢华伟(此时此刻） wrote: From: "huawei.xhw" VFIO should use the same way to map/read/write PORT IO as UIO, for virtio PMD. Please provide more details in the commit message on why the way VFIO works today is wrong (The cover letter is lost once applied). ok Signed-off-by: huawei.xhw Same comment about name format as on previous patches. --- drivers/bus/pci/linux/pci.c | 8 drivers/bus/pci/linux/pci_uio.c | 4 +++- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c index 0dc99e9..2ed9f2b 100644 --- a/drivers/bus/pci/linux/pci.c +++ b/drivers/bus/pci/linux/pci.c @@ -687,7 +687,7 @@ int rte_pci_write_config(const struct rte_pci_device *device, #ifdef VFIO_PRESENT case RTE_PCI_KDRV_VFIO: if (pci_vfio_is_enabled()) - ret = pci_vfio_ioport_map(dev, bar, p); + ret = pci_uio_ioport_map(dev, bar, p); Doesn't it create a regression with regards to needed capabilities? My understanding is that before this patch we don't need to call iopl(), whereas once applied it is required, correct? I did some testing today, and think it is not a regression with para- virtualized Virtio devices. Indeed, I thought it would be a regression with Legacy devices when IOMMU is enabled and the program is run as non-root (IOMMU enabled just to suport IOVA as VA mode). But it turns out para-virtualized Virtio legacy device and vIOMMU enabled is not a supported configuration by QEMU. Note that when noiommu mode is enabled, the app needs cap_sys_rawio, so same as iopl(). No regression in this case too. That said, with real (non para-virtualized) Virtio device using PIO like yours, doesn't your patch introduce a restriction for your device that it will require cap_sys_rawio whereas it would not be needed? I don't catch the regression issue. With real virtio device(hardware implemented), if it is using MMIO, no cap_sys_rawio is required. If it is using PIO, iopl is required always. Thanks, Maxime Regards, Maxime
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On 20/1/2021 2:28 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
IMO this should be part of the first patch, otherwise the build could
(will?) be broken until this patch.
Hi Anatoly,
It was broken before this patch set. I wanted to have everything in
place, including the correct naming of structs/defines before allowing
builds against the new header file, hence this order in the patch set.
Rgds,
Dave.
Re: [dpdk-dev] [PATCH v3 3/6] power: rename public structs
On 20/1/2021 2:27 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
rename the public structs to have an rte_power_ prefix.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
RTE_LOG(ERR, GUEST_CLI, "Error receiving message.\n");
@@ -293,14 +294,15 @@ cmd_query_caps_list_parsed(void *parsed_result,
{
struct cmd_query_caps_result *res = parsed_result;
unsigned int lcore_id;
- struct channel_packet_caps_list pkt_caps_list;
- struct channel_packet pkt;
+ struct rte_power_channel_packet_caps_list pkt_caps_list;
+ struct rte_power_channel_packet pkt;
bool query_list = false;
int ret;
char *ep;
- memset(&pkt, 0, sizeof(struct channel_packet));
- memset(&pkt_caps_list, 0, sizeof(struct channel_packet_caps_list));
+ memset(&pkt, 0, sizeof(struct rte_power_channel_packet));
+ memset(&pkt_caps_list, 0,
+ sizeof(struct rte_power_channel_packet_caps_list));
Here and in other places where you do sizeof(), you might want to
avoid future changes by replacing it with sizeof(*pkt) instead?
Good point. Will do.
Thanks.
Re: [dpdk-dev] [PATCH v2 0/5] Add the E-Switch mirroring and jump supports
Hi, > -Original Message- > From: Jiawei Wang > Sent: Tuesday, January 12, 2021 12:29 PM > To: Slava Ovsiienko ; Matan Azrad > ; Ori Kam > Cc: dev@dpdk.org; Raslan Darawsheh > Subject: [PATCH v2 0/5] Add the E-Switch mirroring and jump supports > > MLX5 E-Switch mirroring is implemented as multiple destination array in > one steering table. The array currently supports only port ID as > destination actions. > > This patchset adds the below supports for MLX5 PMD driver: > - Supports the metadata register Cx preserve capability query. > - Supports the jump action support as one of destination of array. > - Supports the modify action only impact on the one of destination. > > The examples for the E-Switch flow use case and result as below: > set sample_actions 0 port_id id 1 / end > flow create 0 ingress transfer pattern eth / end actions sample ratio 1 > index > 0 / jump group 1 / end > flow create 1 ingress transfer group 1 pattern eth / end actions > set_mac_dst mac_addr 00:aa:bb:cc:dd:ee / port_id id 2 / end > > The flow results all the matched ingress packets are mirrored > to port id 1 and go to group 1. In the group 1, packets are modified > with the destination mac and sent to port id 2. > > v2: > * Rebase > * Update commit message and document description > > Jiawei Wang (5): > common/mlx5: query register c preserve capability via DevX > net/mlx5: support E-Switch mirroring and jump in one flow > net/mlx5: extend the skip scale flag > net/mlx5: update modify actions support for E-Switch mirror > doc: update the advanced E-switch mirroring supports > > doc/guides/nics/mlx5.rst | 2 + > doc/guides/rel_notes/release_21_02.rst | 7 ++ > drivers/common/mlx5/mlx5_devx_cmds.c | 2 + > drivers/common/mlx5/mlx5_devx_cmds.h | 1 + > drivers/common/mlx5/mlx5_prm.h | 4 +- > drivers/net/mlx5/mlx5_flow.c | 203 +++-- > > drivers/net/mlx5/mlx5_flow.h | 23 +++- > drivers/net/mlx5/mlx5_flow_dv.c| 92 +-- > 8 files changed, 235 insertions(+), 99 deletions(-) > > -- > 1.8.3.1 Series rebased and applied to next-net-mlx, Kindest regards, Raslan Darawsheh
Re: [dpdk-dev] [PATCH v2 16/19] app/chkincs: add chkincs app to verify headers
On Wed, Jan 20, 2021 at 3:34 PM Bruce Richardson wrote: > On Fri, Jan 15, 2021 at 02:59:08PM +, Bruce Richardson wrote: > > On Fri, Jan 15, 2021 at 02:55:41PM +, Bruce Richardson wrote: > > > On Fri, Jan 15, 2021 at 03:09:25PM +0100, Thomas Monjalon wrote: > > > I'm honestly fine either way on this (as with directory where > > > implementation lives) - main thing is to have the checking done, rather > > > than ignored. > > > > > And I (obviously) forgot to mention that the existing script is not > > currently > > integrated into existing build or build-test scripts. I haven't looked into > > how complex this would be, but it would require investigation time. > > I do plan to look into re-using the script and other options around this > area - hopefully in RC2 timeframe. However, to make the patchset rework a > little easier, perhaps the small header fixes could be picked up for ahead > of any rework? I'll merge those fixes hopefully tomorrow. -- David Marchand
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On Wed, Jan 20, 2021 at 02:28:59PM +, Burakov, Anatoly wrote:
> On 20-Jan-21 1:55 PM, David Hunt wrote:
> > From: Bruce Richardson
> >
> > Adjust meson.build so that 'ninja install' copies the new header
> > file into the installation directory.
> >
> > Fixes: 210c383e247b ("power: packet format for vm power management")
> > Fixes: cd0d5547e873 ("power: vm communication channels in guest")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Bruce Richardson
> > Signed-off-by: David Hunt
> > ---
>
> IMO this should be part of the first patch, otherwise the build could
> (will?) be broken until this patch.
>
Since things were already broken before the set, I'm not sure this really
matters.
Re: [dpdk-dev] [PATCH v3 2/6] power: make channel msg functions public
On 20/1/2021 2:26 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Move the 2 public functions into rte_power_guest_channel.h
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
+/**
+ * Send a message contained in pkt over the Virtio-Serial to the
host endpoint.
+ *
+ * @param pkt
+ * Pointer to a populated struct channel_packet
+ *
+ * @param lcore_id
+ * lcore_id.
Not very informative doxygen comment :)
Maybe "Use channel specific to this lcore_id"?
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+__rte_experimental
+int rte_power_guest_channel_send_msg(struct channel_packet *pkt,
+ unsigned int lcore_id);
+
+/**
+ * Receive a message contained in pkt over the Virtio-Serial
+ * from the host endpoint.
+ *
Nitpick, but we generally add a warning to experimental functions,
like so:
* @warning
* @b EXPERIMENTAL: this API may change, or be removed, without prior
notice.
also, presumably this is not meant to be public API and exists solely
because there's no other way to do it without significant rework, so
maybe mark as @internal too?
Yes, I believe so. I will add @internal.
+ * @param pkt
+ * Pointer to channel_packet or
+ * channel_packet_freq_list struct.
+ *
+ * @param pkt_len
+ * Size of expected data packet.
+ *
+ * @param lcore_id
+ * lcore_id.
Same here.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+__rte_experimental
+int rte_power_guest_channel_receive_msg(void *pkt,
+ size_t pkt_len,
+ unsigned int lcore_id);
+
#ifdef __cplusplus
}
Re: [dpdk-dev] [PATCH v3 1/6] power: create guest channel public header file
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
In preparation for making the header file public, we first rename
channel_commands.h as rte_power_guest_channel.h.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
You should also add the new API's to the map file.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 1/6] power: create guest channel public header file
On 20/1/2021 3:09 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
In preparation for making the header file public, we first rename
channel_commands.h as rte_power_guest_channel.h.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
You should also add the new API's to the map file.
Yes, spotted this earlier. Will be in the next respin. Thanks.
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On 20-Jan-21 3:01 PM, David Hunt wrote:
On 20/1/2021 2:28 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
IMO this should be part of the first patch, otherwise the build could
(will?) be broken until this patch.
Hi Anatoly,
It was broken before this patch set. I wanted to have everything in
place, including the correct naming of structs/defines before allowing
builds against the new header file, hence this order in the patch set.
Rgds,
Dave.
It's only my opinion obviously, but i rather prefer an approach of
fixing build issues first, and then renaming everything, as I like to
have each patch build at every step of the way. You probably know
better, but from a cursory look, you should be able to keep
progressively changing things but also keep everything building
correctly every step of the way.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On 20-Jan-21 3:08 PM, Bruce Richardson wrote:
On Wed, Jan 20, 2021 at 02:28:59PM +, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
IMO this should be part of the first patch, otherwise the build could
(will?) be broken until this patch.
Since things were already broken before the set, I'm not sure this really
matters.
If they can be *un*broken sooner, that's a win in my book :)
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 2/6] power: make channel msg functions public
On 20-Jan-21 3:08 PM, David Hunt wrote:
On 20/1/2021 2:26 PM, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Move the 2 public functions into rte_power_guest_channel.h
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
+/**
+ * Send a message contained in pkt over the Virtio-Serial to the
host endpoint.
+ *
+ * @param pkt
+ * Pointer to a populated struct channel_packet
+ *
+ * @param lcore_id
+ * lcore_id.
Not very informative doxygen comment :)
Maybe "Use channel specific to this lcore_id"?
Something like that, yes. Or, "Use channel associated with this lcore ID".
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On 20/1/2021 3:18 PM, Burakov, Anatoly wrote:
On 20-Jan-21 3:08 PM, Bruce Richardson wrote:
On Wed, Jan 20, 2021 at 02:28:59PM +, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
IMO this should be part of the first patch, otherwise the build could
(will?) be broken until this patch.
Since things were already broken before the set, I'm not sure this
really
matters.
If they can be *un*broken sooner, that's a win in my book :)
I'll keep that in mind for future patch sets. For this one, the effort
to change far outweighs the benefits, so I'll leave as is. OK with you?
Re: [dpdk-dev] [PATCH v2 02/44] bus/vdev: add driver IOVA VA mode requirement
On Tue, Jan 19, 2021 at 10:25 PM Maxime Coquelin
wrote:
>
> This patch adds driver flag in vdev bus driver so that
> vdev drivers can require VA IOVA mode to be used, which
> for example the case of Virtio-user PMD.
>
> The patch implements the .get_iommu_class() callback, that
> is called before devices probing to determine the IOVA mode
> to be used.
>
> It also adds a check right before the device is probed to
> ensure compatible IOVa mode has been selected.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/bus/vdev/rte_bus_vdev.h | 4
> drivers/bus/vdev/vdev.c | 31 +++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
> index f99a41f825..c8b41e649c 100644
> --- a/drivers/bus/vdev/rte_bus_vdev.h
> +++ b/drivers/bus/vdev/rte_bus_vdev.h
> @@ -113,8 +113,12 @@ struct rte_vdev_driver {
> rte_vdev_remove_t *remove; /**< Virtual device remove function.
> */
> rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map
> function. */
> rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap
> function. */
> + uint32_t drv_flags;/**< Flags RTE_VDEV_DRV_*. */
This will probably get broken in the future, but for now, can you
indent the comment in the same way as earlier lines?
The ABI check will complain about this change so we need an exception.
rte_vdev_driver is exposed only through driver API.
We could flag the whole structure like we did for ethdev.
But there is also the alternative of just flagging the required
symbols so that we won't miss later the inclusion of this structure in
an API used by final users.
How about:
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 1dc84fa74b..435913d908 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -11,6 +11,8 @@
; Explicit ignore for driver-only ABI
[suppress_type]
name = eth_dev_ops
+[suppress_function]
+name_regexp = rte_vdev_(|un)register
; Ignore fields inserted in cacheline boundary of rte_cryptodev
[suppress_type]
> };
>
> +/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
> +#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
> +
> /**
> * Register a virtual device driver.
> *
> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
> index acfd78828f..56f15e8201 100644
> --- a/drivers/bus/vdev/vdev.c
> +++ b/drivers/bus/vdev/vdev.c
> @@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
> {
> const char *name;
> struct rte_vdev_driver *driver;
> + enum rte_iova_mode iova_mode;
> int ret;
>
> if (rte_dev_is_probed(&dev->device))
> @@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>
> if (vdev_parse(name, &driver))
> return -1;
> +
> + iova_mode = rte_eal_iova_mode();
> + if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode
> == RTE_IOVA_PA)) {
> + VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is
> PA, not initializing",
> + name);
> + return -1;
> + }
> +
> ret = driver->probe(dev);
> if (ret == 0)
> dev->device.driver = &driver->driver;
> @@ -594,6 +603,27 @@ vdev_unplug(struct rte_device *dev)
> return rte_vdev_uninit(dev->name);
> }
>
> +static enum rte_iova_mode
> +vdev_get_iommu_class(void)
> +{
> + const char *name;
> + struct rte_vdev_device *dev;
> + struct rte_vdev_driver *driver;
> +
> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
> + name = rte_vdev_device_name(dev);
> + if (!name)
> + continue;
Afaics, a device in vdev_device_list always has a name.
> + if (vdev_parse(name, &driver))
> + continue;
> +
> + if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
> + return RTE_IOVA_VA;
> + }
> +
> + return RTE_IOVA_DC;
> +}
> +
> static struct rte_bus rte_vdev_bus = {
> .scan = vdev_scan,
> .probe = vdev_probe,
> @@ -603,6 +633,7 @@ static struct rte_bus rte_vdev_bus = {
> .parse = vdev_parse,
> .dma_map = vdev_dma_map,
> .dma_unmap = vdev_dma_unmap,
> + .get_iommu_class = vdev_get_iommu_class,
> .dev_iterate = rte_vdev_dev_iterate,
> };
>
> --
> 2.29.2
>
--
David Marchand
Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev
Question to an expert, Dodji,
We have this structure:
struct rte_cryptodev {
lot of fields...
uint8_t attached : 1;
} __rte_cache_aligned;
Because of the cache alignment, there is enough padding in the struct
(no matter the size of the cache line) for adding two more pointers:
struct rte_cryptodev {
lot of fields...
uint8_t attached : 1;
struct rte_cryptodev_cb_rcu *enq_cbs;
struct rte_cryptodev_cb_rcu *deq_cbs;
} __rte_cache_aligned;
We checked manually that the ABI is still compatible.
Then I've added (quickly) a libabigail exception rule:
[suppress_type]
name = rte_cryptodev
has_data_member_inserted_between = {0, 1023}
Now we want to improve this rule to restrict the offsets
to the padding at the end of the struct only,
so we keep forbidding changes in existing fields,
and forbidding additions further the current struct size.
Is this new rule good?
has_data_member_inserted_between = {offset_after(attached), end}
Do you confirm that the keyword "end" means the old reference size?
What else do we need to check for adding a new field in a padding?
Thank you
20/01/2021 15:25, Ray Kinsella:
> Update the ignore entry for crytodev to use named fields instead of
> bit positions.
>
> Fixes: 1c3ffb9559
>
> Signed-off-by: Ray Kinsella
> ---
> devtools/libabigail.abignore | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..1f17fbed58 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -15,4 +15,4 @@
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
> name = rte_cryptodev
> -has_data_member_inserted_between = {0, 1023}
> +has_data_member_inserted_between = {offset_after(attached), end}
[dpdk-dev] [Bug 621] [aarch64] build failure in vhost/virtio
https://bugs.dpdk.org/show_bug.cgi?id=621 Bug ID: 621 Summary: [aarch64] build failure in vhost/virtio Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: sub...@nvidia.com Target Milestone: --- $ meson build -Ddisable_drivers='event/octeontx2' && ninja -C build ``` ninja: Entering directory `build' [1787/2495] Compiling C object 'drivers/drivers@@tmp_rte_net_virtio@sta/net_virtio_virtio_rxtx_packed.c.o'. FAILED: drivers/drivers@@tmp_rte_net_virtio@sta/net_virtio_virtio_rxtx_packed.c.o cc -Idrivers/drivers@@tmp_rte_net_virtio@sta -Idrivers -I../drivers -Idrivers/net/virtio -I../drivers/net/virtio -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I../ -Iconfig -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include -Ilib/librte_eal/arm/include -I../lib/librte_eal/arm/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_telemetry/../librte_metrics -I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/librte_pci -I../lib/librte_pci -Idrivers/bus/vdev -I../drivers/bus/vdev -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -MD -MQ 'drivers/drivers@@tmp_rte_net_virtio@sta/net_virtio_virtio_rxtx_packed.c.o' -MF 'drivers/drivers@@tmp_rte_net_virtio@sta/net_virtio_virtio_rxtx_packed.c.o.d' -o 'drivers/drivers@@tmp_rte_net_virtio@sta/net_virtio_virtio_rxtx_packed.c.o' -c ../drivers/net/virtio/virtio_rxtx_packed.c In file included from ../drivers/net/virtio/virtio_rxtx_packed.c:22:0: ../drivers/net/virtio/virtio_rxtx_packed_neon.h: In function ‘virtqueue_enqueue_batch_packed_vec’: ../drivers/net/virtio/virtio_rxtx_packed_neon.h:74:2: warning: implicit declaration of function ‘vreinterpretq_p128_u32’ [-Wimplicit-function-declaration] poly128_t cmp1 = vreinterpretq_p128_u32(~vceqq_u32(ref_seg, def_ref_seg)); ^ ../drivers/net/virtio/virtio_rxtx_packed_neon.h:74:2: warning: nested extern declaration of ‘vreinterpretq_p128_u32’ [-Wnested-externs] ../drivers/net/virtio/virtio_rxtx_packed_neon.h:74:19: error: incompatible types when initializing type ‘poly128_t’ using type ‘int’ poly128_t cmp1 = vreinterpretq_p128_u32(~vceqq_u32(ref_seg, def_ref_seg)); ^ In file included from ../lib/librte_eal/arm/include/rte_atomic_64.h:18:0, from ../lib/librte_eal/arm/include/rte_atomic.h:9, from ../lib/librte_eal/include/generic/rte_pause.h:19, from ../lib/librte_eal/arm/include/rte_pause_64.h:19, from ../lib/librte_eal/arm/include/rte_pause.h:13, from ../lib/librte_eal/include/generic/rte_spinlock.h:25, from ../lib/librte_eal/arm/include/rte_spinlock.h:17, from ../lib/librte_mempool/rte_mempool.h:44, from ../lib/librte_mbuf/rte_mbuf.h:38, from ../lib/librte_net/rte_ip.h:24, from ../lib/librte_net/rte_net.h:12, from ../drivers/net/virtio/virtio_rxtx_packed.c:11: ../lib/librte_eal/include/rte_branch_prediction.h:38:39: error: wrong type argument to unary exclamation mark #define unlikely(x) __builtin_expect(!!(x), 0) ^ ../drivers/net/virtio/virtio_rxtx_packed_neon.h:75:6: note: in expansion of macro ‘unlikely’ if (unlikely(cmp1)) ^ In file included from ../drivers/net/virtio/virtio_rxtx_packed.c:22:0: ../drivers/net/virtio/virtio_rxtx_packed_neon.h: In function ‘virtqueue_dequeue_batch_packed_vec’: ../drivers/net/virtio/virtio_rxtx_packed_neon.h:228:25: error: incompatible types when initializing type ‘poly128_t’ using type ‘int’ poly128_t desc_stats = vreinterpretq_p128_u32(~vceqq_u32(v_flag, v_used_flag)); ^ ../drivers/net/virtio/virtio_rxtx_packed_neon.h:231:6: error: used vector type where scalar is required if (desc_stats) ^ ../drivers/net/virtio/virtio_rxtx_packed_neon.h:228:12: warning: variable ‘desc_stats’ set but not used [-Wunused-but-set-variable] poly128_t
Re: [dpdk-dev] [PATCH v3 5/6] power: add new header file to export list
On 20-Jan-21 3:29 PM, David Hunt wrote:
On 20/1/2021 3:18 PM, Burakov, Anatoly wrote:
On 20-Jan-21 3:08 PM, Bruce Richardson wrote:
On Wed, Jan 20, 2021 at 02:28:59PM +, Burakov, Anatoly wrote:
On 20-Jan-21 1:55 PM, David Hunt wrote:
From: Bruce Richardson
Adjust meson.build so that 'ninja install' copies the new header
file into the installation directory.
Fixes: 210c383e247b ("power: packet format for vm power management")
Fixes: cd0d5547e873 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Signed-off-by: David Hunt
---
IMO this should be part of the first patch, otherwise the build could
(will?) be broken until this patch.
Since things were already broken before the set, I'm not sure this
really
matters.
If they can be *un*broken sooner, that's a win in my book :)
I'll keep that in mind for future patch sets. For this one, the effort
to change far outweighs the benefits, so I'll leave as is. OK with you?
Sure.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
20/01/2021 09:41, Juraj Linkeš:
> From: Honnappa Nagarahalli
> > > 20/01/2021 02:04, Honnappa Nagarahalli:
> > > > > On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote:
> > > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > > From: Thomas Monjalon
> > > > > > > > 15/01/2021 14:26, Juraj Linkeš:
> > > > > > > > > --- a/meson_options.txt
> > > > > > > > > +++ b/meson_options.txt
> > > > > > > > > +option('arm_soc', type: 'string', value: '',
> > > > > > > > > + description: 'Specify if you want to build for a
> > > > > > > > > +particular
> > > > > > > > > +aarch64 Arm SoC when building on an aarch64 machine.')
> > > > > > > >
> > > > > > > > Why the option is named "arm_soc" and not just "soc"?
> > > > > > > > The same option could be used by other archs, isn't it?
> > > > > > >
> > > > > > > Agree that a more generic name would be better.
> > > > > > > I'll change it to "soc" if there are no other suggestions.
> > > > > >
> > > > > > Another name could be "machine".
> > > > > > Should it be the same mechanism as compiling for a specific x86
> > > > > > CPU from an x86 machine?
> > > > > >
> > > > > I'd rather not re-use the term "machine", for a new use, better to
> > > > > use a new term IMHO.
> > > > +1, agree. 'soc' sounds good to me.
> > >
> > > Another possible word is "platform",
> > > as in http://doc.dpdk.org/guides/platform/index.html
> > I am fine with 'platform' too.
> >
>
> 'platform' is likely the best and actually works nicely with
> http://patches.dpdk.org/patch/85956/. Taken together, 'platform' could be
> either 'native', 'generic' or an soc, which is, I believe, exactly what we
> want.
I am not sure what we want :)
We need to specify the instruction set, and the specific target.
We could deduce the instruction set from the target,
but I think it is good to be able to overwrite the instruction set
in case there can be multiple instruction sets for a target.
I think "native" and "generic" should be specified as instruction set,
in the existing option "machine" or renamed as "instruction_set" or "isa".
Let's imagine the first option is "isa" and the new second option is "platform".
We can have a default "isa" per "platform".
The default "platform" would have a default "isa": native or generic?
What else do we need?
Re: [dpdk-dev] [PATCH v2] net/mlx5: enlarge maximal flow priority value
Hi, > -Original Message- > From: Dong Zhou > Sent: Tuesday, January 12, 2021 8:40 AM > To: Matan Azrad ; Slava Ovsiienko > ; Ori Kam > Cc: dev@dpdk.org; Raslan Darawsheh > Subject: [PATCH v2] net/mlx5: enlarge maximal flow priority value > > Currently, the maximal flow priority in non-root table to user > is 4, it's not enough for user to do some flow match by priority, > such as LPM, for one IPV4 address, we need 32 priorities for each > bit of 32 mask length. > > PMD will manage 3 sub-priorities per user priority according to L2, > L3 and L4. The internal priority is 16 bits, user can use priorities > from 0 - 21843. > > Those enlarged flow priorities are only used for ingress or egress > flow groups greater than 0 and for any transfer flow group. > > Signed-off-by: Dong Zhou > Acked-by: Matan Azrad > --- > v2: > * fix coding style issues, 'prority' to 'priority'. > --- Patch rebased and applied to next-net-mlx, Kindest regards, Raslan Darawsheh
[dpdk-dev] [dpdk-announce] DPDK 18.11.11 (LTS) released
Hi all, Here is a new LTS release: https://fast.dpdk.org/rel/dpdk-18.11.11.tar.xz The git tree is at: https://dpdk.org/browse/dpdk-stable/?h=18.11 This is the last planned 18.11 LTS release. Thanks to the authors who helped cleaning up the fixes that were hanging around for a while and needed some attention. >From this point onwards the 18.11 LTS branch is no longer maintained. I want to acknowledge all the work done by validation teams from Intel, Nvidia, Microsoft and Red Hat who have made the releases possible by providing validation over the last two years. Some statistics about 18.11 LTS releases: - 1911 commits - 1164 files changed, 26064 insertions(+), 13576 deletions(-) - Changes per subdir -- 3.4% app/ -- 17.7% doc/ -- 50.0% drivers/ -- 5.8% examples/ -- 15.6% lib/ -- 3.8% test/ Long may you run! Kevin. --- MAINTAINERS| 186 ++- app/test-crypto-perf/meson.build | 3 + app/test-eventdev/evt_options.c| 4 + app/test-pmd/bpf_cmd.c | 4 +- app/test-pmd/cmdline.c | 11 +- app/test-pmd/cmdline_flow.c| 15 +- app/test-pmd/config.c | 88 +++-- app/test-pmd/meson.build | 12 + buildtools/meson.build | 2 + buildtools/pmdinfogen/pmdinfogen.h | 2 +- config/defconfig_arm-armv7a-linuxapp-gcc | 1 - config/meson.build | 8 +- config/rte_config.h| 3 + devtools/check-forbidden-tokens.awk| 2 +- doc/build-sdk-meson.txt| 23 +- doc/guides/cryptodevs/features/octeontx.ini| 1 + doc/guides/linux_gsg/build_sample_apps.rst | 4 +- doc/guides/linux_gsg/enable_func.rst | 60 +++- doc/guides/linux_gsg/linux_drivers.rst | 2 +- doc/guides/linux_gsg/nic_perf_intel_platform.rst | 3 + doc/guides/linux_gsg/sys_reqs.rst | 76 +++-- doc/guides/nics/dpaa2.rst | 4 +- doc/guides/nics/i40e.rst | 9 + doc/guides/nics/mlx5.rst | 24 ++ doc/guides/nics/nfp.rst| 39 ++- doc/guides/nics/pcap_ring.rst | 2 +- doc/guides/nics/sfc_efx.rst| 4 +- doc/guides/prog_guide/kernel_nic_interface.rst | 2 +- doc/guides/prog_guide/multi_proc_support.rst | 2 +- .../prog_guide/packet_classif_access_ctrl.rst | 6 + doc/guides/rel_notes/release_18_11.rst | 366 + doc/guides/sample_app_ug/flow_classify.rst | 2 +- doc/guides/sample_app_ug/flow_filtering.rst| 2 +- .../sample_app_ug/l3_forward_access_ctrl.rst | 8 +- doc/guides/sample_app_ug/l3_forward_power_man.rst | 2 +- doc/guides/testpmd_app_ug/testpmd_funcs.rst| 6 +- drivers/baseband/turbo_sw/bbdev_turbo_software.c | 35 +- drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 9 +- drivers/bus/pci/bsd/pci.c | 49 --- drivers/bus/pci/linux/pci.c| 12 - drivers/bus/pci/linux/pci_vfio.c | 8 +- drivers/bus/pci/private.h | 15 - drivers/common/qat/qat_device.c| 1 + drivers/compress/isal/isal_compress_pmd_ops.c | 20 +- drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c| 8 +- drivers/crypto/octeontx/otx_cryptodev_ops.c| 1 + drivers/crypto/scheduler/meson.build | 2 +- drivers/event/dpaa2/dpaa2_eventdev.c | 8 +- drivers/mempool/octeontx/octeontx_fpavf.c | 6 +- drivers/net/avf/avf.h | 2 +- drivers/net/avf/avf_ethdev.c | 84 ++--- drivers/net/avf/avf_rxtx.c | 2 + drivers/net/avf/avf_rxtx_vec_sse.c | 49 ++- drivers/net/avf/avf_vchnl.c| 6 +- drivers/net/bnx2x/bnx2x_ethdev.c | 4 + drivers/net/bnxt/bnxt_ethdev.c | 20 +- drivers/net/bnxt/bnxt_filter.c | 15 +- drivers/net/bnxt/bnxt_flow.c | 12 + drivers/net/bnxt/bnxt_hwrm.c | 59 ++-- drivers/net/bnxt/bnxt_hwrm.h | 1 + drivers/net/bnxt/bnxt_ring.h | 2 +- drivers/net/bnxt/bnxt_rxq.c| 48 ++- drivers/net/bnxt/bnxt_rxq.h| 4 + drivers/net/bnxt/bnxt_rxr.c| 40 ++- drivers/net/bnxt/bnxt_txq.c| 32 +- drivers/net/bnxt/bnxt_txr.c| 2 + drivers/net/bnxt/bnxt_vnic.c | 3 + drivers/net/bonding/rte_et
[dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
AVX512 does not seem supported with FC32 and Windows mingw:
FAILED:
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
x86_64-w64-mingw32-gcc -Idrivers/net/i40e/libi40e_avx512_lib.a.p
-Idrivers/net/i40e -I../../dpdk/drivers/net/i40e -Idrivers/net/i40e/base
-I../../dpdk/drivers/net/i40e/base -Ilib/librte_ethdev
-I../../dpdk/lib/librte_ethdev -I. -I../../dpdk -Iconfig
-I../../dpdk/config -Ilib/librte_eal/include
-I../../dpdk/lib/librte_eal/include -Ilib/librte_eal/windows/include
-I../../dpdk/lib/librte_eal/windows/include -Ilib/librte_eal/x86/include
-I../../dpdk/lib/librte_eal/x86/include -Ilib/librte_eal/common
-I../../dpdk/lib/librte_eal/common -Ilib/librte_eal
-I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
-I../../dpdk/lib/librte_kvargs -Ilib/librte_net
-I../../dpdk/lib/librte_net -Ilib/librte_mbuf
-I../../dpdk/lib/librte_mbuf -Ilib/librte_mempool
-I../../dpdk/lib/librte_mempool -Ilib/librte_ring
-I../../dpdk/lib/librte_ring -Ilib/librte_meter
-I../../dpdk/lib/librte_meter -I../../dpdk/lib/librte_metrics
-Ilib/librte_telemetry -I../../dpdk/lib/librte_telemetry
-Ilib/librte_hash -I../../dpdk/lib/librte_hash -Ilib/librte_rcu
-I../../dpdk/lib/librte_rcu
-I/home/dmarchan/intel-ipsec-mb/install/include
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -D_WIN32_WINNT=0x0A00
-D__USE_MINGW_ANSI_STDIO -march=native -DALLOW_EXPERIMENTAL_API
-DALLOW_INTERNAL_API -Wno-format-truncation -DPF_DRIVER -DVF_DRIVER
-DINTEGRATED_VF -DX722_A0_SUPPORT -DCC_AVX2_SUPPORT -DCC_AVX512_SUPPORT
-mavx512f -mavx512bw -march=skylake-avx512 -MD -MQ
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -MF
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj.d -o
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -c
../../dpdk/drivers/net/i40e/i40e_rxtx_vec_avx512.c
{standard input}: Assembler messages:
{standard input}:112: Error: invalid register for .seh_savexmm
{standard input}:114: Error: invalid register for .seh_savexmm
{standard input}:116: Error: invalid register for .seh_savexmm
{standard input}:118: Error: invalid register for .seh_savexmm
...
Fixes: e6a6a138919f ("net/i40e: add AVX512 vector path")
Signed-off-by: David Marchand
---
There is probably better to do rather than disabling AVX512 globally for
Windows but since I saw no patch fixing this, here it is.
---
drivers/net/i40e/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
index c0acdf4fd4..c9a1a50407 100644
--- a/drivers/net/i40e/meson.build
+++ b/drivers/net/i40e/meson.build
@@ -54,7 +54,7 @@ if arch_subdir == 'x86'
cc.has_argument('-mavx512f') and
cc.has_argument('-mavx512bw'))
- if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
+ if not is_windows and (i40e_avx512_cpu_support == true or
i40e_avx512_cc_support == true)
cflags += ['-DCC_AVX512_SUPPORT']
avx512_args = [cflags, '-mavx512f', '-mavx512bw']
if cc.has_argument('-march=skylake-avx512')
--
2.23.0
Re: [dpdk-dev] DPDK 18.11.11 (LTS) released
20/01/2021 16:58, Kevin Traynor: > This is the last planned 18.11 LTS release. Thanks to the > authors who helped cleaning up the fixes that were hanging > around for a while and needed some attention. > > From this point onwards the 18.11 LTS branch is no longer > maintained. > > I want to acknowledge all the work done by validation > teams from Intel, Nvidia, Microsoft and Red Hat who have > made the releases possible by providing validation over the > last two years. > > Some statistics about 18.11 LTS releases: > - 1911 commits > > - 1164 files changed, 26064 insertions(+), 13576 deletions(-) > > - Changes per subdir > -- 3.4% app/ > -- 17.7% doc/ > -- 50.0% drivers/ > -- 5.8% examples/ > -- 15.6% lib/ > -- 3.8% test/ > > Long may you run! Good job, thank you Kevin for the dedication!
[dpdk-dev] [Bug 574] get_num_hugepages_on_node() doesn't mention which node doesn't have free hugepages
https://bugs.dpdk.org/show_bug.cgi?id=574 Thomas Monjalon (tho...@monjalon.net) changed: What|Removed |Added Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Monjalon (tho...@monjalon.net) --- Patch merged: https://git.dpdk.org/dpdk/commit/?id=c6915067989 -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] DPDK 18.11.11 (LTS) released
On Wed, Jan 20, 2021 at 6:12 PM Thomas Monjalon wrote: > > 20/01/2021 16:58, Kevin Traynor: > > This is the last planned 18.11 LTS release. Thanks to the > > authors who helped cleaning up the fixes that were hanging > > around for a while and needed some attention. > > > > From this point onwards the 18.11 LTS branch is no longer > > maintained. > > > > I want to acknowledge all the work done by validation > > teams from Intel, Nvidia, Microsoft and Red Hat who have > > made the releases possible by providing validation over the > > last two years. > > > > Some statistics about 18.11 LTS releases: > > - 1911 commits Now for Luca to reach 2011 commits. > > > > - 1164 files changed, 26064 insertions(+), 13576 deletions(-) > > > > - Changes per subdir > > -- 3.4% app/ > > -- 17.7% doc/ > > -- 50.0% drivers/ > > -- 5.8% examples/ > > -- 15.6% lib/ > > -- 3.8% test/ > > > > Long may you run! > > > Good job, thank you Kevin for the dedication! Thanks Kevin! -- David Marchand
[dpdk-dev] [PATCH v3 1/4] test/cryptodev: fix latency test csv output
The csv output for the latency performance test had an extra header,
"Packet Size", which is a duplicate of "Buffer Size", and had no
corresponding value in the output. This is now removed.
Fixes: f6cefe253cc8 ("app/crypto-perf: add range/list of sizes")
Cc: pablo.de.lara.gua...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
Acked-by: Declan Doherty
Acked-by: Adam Dybkowski
---
app/test-crypto-perf/cperf_test_latency.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-crypto-perf/cperf_test_latency.c
b/app/test-crypto-perf/cperf_test_latency.c
index 0e4d0e1538..c2590a4dcf 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -310,7 +310,7 @@ cperf_latency_test_runner(void *arg)
if (ctx->options->csv) {
if (rte_atomic16_test_and_set(&display_once))
printf("\n# lcore, Buffer Size, Burst Size,
Pakt Seq #, "
- "Packet Size, cycles, time
(us)");
+ "cycles, time (us)");
for (i = 0; i < ctx->options->total_ops; i++) {
--
2.25.1
[dpdk-dev] [PATCH v3 0/4] add crypto perf test graphing script
This patchset introduces a python script to run various crypto performance test cases, and graph the results in a consumable manner. The test suites are configured via JSON file. Some config files are provided, or the user may create one. Currently throughput and latency ptests for devices crypto_qat, crypto_aesni_mb and crypto_aesni_gcm are supported. The final collection of graphs are output in PDF format, with multiple PDFs per test suite, one for each graph type. Some fixes are included for the throughput performance test and latency performance test csv outputs also. v3: - Moved script and configs to app/test-crypto-perf directory. - Made changes to documentation and MAINTAINERS to reflect the above change. v2: - Reduced changes to only fix csv format for all perf test types. - Added functionality for additional args such as config file, output directory and verbose. - Improved help text for script. - Improved script console output. - Added support for latency test cases with burst or buffer size lists. - Split config file into smaller config files, one for each device. - Split output PDFs into smaller files, based on test suite graph types. - Modified output directory naming and structure. - Made some general improvements to script. - Updated and improved documentation. Ciara Power (4): test/cryptodev: fix latency test csv output test/cryptodev: fix csv output format test/cryptodev: add script to graph perf results maintainers: update crypto perf app maintainers MAINTAINERS | 1 + .../configs/crypto-perf-aesni-gcm.json| 99 ++ .../configs/crypto-perf-aesni-mb.json | 108 ++ .../configs/crypto-perf-qat.json | 94 ++ app/test-crypto-perf/cperf_test_latency.c | 4 +- .../cperf_test_pmd_cyclecount.c | 2 +- app/test-crypto-perf/cperf_test_throughput.c | 4 +- app/test-crypto-perf/cperf_test_verify.c | 2 +- .../dpdk-graph-crypto-perf.py | 309 ++ doc/guides/tools/cryptoperf.rst | 143 10 files changed, 760 insertions(+), 6 deletions(-) create mode 100644 app/test-crypto-perf/configs/crypto-perf-aesni-gcm.json create mode 100644 app/test-crypto-perf/configs/crypto-perf-aesni-mb.json create mode 100644 app/test-crypto-perf/configs/crypto-perf-qat.json create mode 100755 app/test-crypto-perf/dpdk-graph-crypto-perf.py -- 2.25.1
[dpdk-dev] [PATCH v3 2/4] test/cryptodev: fix csv output format
The csv output for each ptest type used ";" instead of ",".
This has now been fixed to use the comma format that is used in the csv
headers.
Fixes: f6cefe253cc8 ("app/crypto-perf: add range/list of sizes")
Fixes: 96dfeb609be1 ("app/crypto-perf: add new PMD benchmarking mode")
Fixes: da40ebd6d383 ("app/crypto-perf: display results in test runner")
Cc: anatoly.bura...@intel.com
Cc: pablo.de.lara.gua...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
Acked-by: Declan Doherty
Acked-by: Adam Dybkowski
---
v2:
- Reduced changes to only fix csv format.
---
app/test-crypto-perf/cperf_test_latency.c| 2 +-
app/test-crypto-perf/cperf_test_pmd_cyclecount.c | 2 +-
app/test-crypto-perf/cperf_test_throughput.c | 4 ++--
app/test-crypto-perf/cperf_test_verify.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/app/test-crypto-perf/cperf_test_latency.c
b/app/test-crypto-perf/cperf_test_latency.c
index c2590a4dcf..159fe8492b 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -314,7 +314,7 @@ cperf_latency_test_runner(void *arg)
for (i = 0; i < ctx->options->total_ops; i++) {
- printf("\n%u;%u;%u;%"PRIu64";%"PRIu64";%.3f",
+ printf("\n%u,%u,%u,%"PRIu64",%"PRIu64",%.3f",
ctx->lcore_id,
ctx->options->test_buffer_size,
test_burst_size, i + 1,
ctx->res[i].tsc_end -
ctx->res[i].tsc_start,
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index 4e67d3aebd..844659aeca 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -16,7 +16,7 @@
#define PRETTY_HDR_FMT "%12s%12s%12s%12s%12s%12s%12s%12s%12s%12s\n\n"
#define PRETTY_LINE_FMT "%12u%12u%12u%12u%12u%12u%12u%12.0f%12.0f%12.0f\n"
#define CSV_HDR_FMT "%s,%s,%s,%s,%s,%s,%s,%s,%s,%s\n"
-#define CSV_LINE_FMT "%10u;%10u;%u;%u;%u;%u;%u;%.3f;%.3f;%.3f\n"
+#define CSV_LINE_FMT "%10u,%10u,%u,%u,%u,%u,%u,%.3f,%.3f,%.3f\n"
struct cperf_pmd_cyclecount_ctx {
uint8_t dev_id;
diff --git a/app/test-crypto-perf/cperf_test_throughput.c
b/app/test-crypto-perf/cperf_test_throughput.c
index f30f7d5c2c..f6eb8cf259 100644
--- a/app/test-crypto-perf/cperf_test_throughput.c
+++ b/app/test-crypto-perf/cperf_test_throughput.c
@@ -299,8 +299,8 @@ cperf_throughput_test_runner(void *test_ctx)
"Failed
Deq,Ops(Millions),Throughput(Gbps),"
"Cycles/Buf\n\n");
-
printf("%u;%u;%u;%"PRIu64";%"PRIu64";%"PRIu64";%"PRIu64";"
- "%.3f;%.3f;%.3f\n",
+
printf("%u,%u,%u,%"PRIu64",%"PRIu64",%"PRIu64",%"PRIu64","
+ "%.3f,%.3f,%.3f\n",
ctx->lcore_id,
ctx->options->test_buffer_size,
test_burst_size,
diff --git a/app/test-crypto-perf/cperf_test_verify.c
b/app/test-crypto-perf/cperf_test_verify.c
index 833bc9a552..2939aeaa93 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -406,7 +406,7 @@ cperf_verify_test_runner(void *test_ctx)
"Burst Size,Enqueued,Dequeued,Failed Enq,"
"Failed Deq,Failed Ops\n");
- printf("%10u;%10u;%u;%"PRIu64";%"PRIu64";%"PRIu64";%"PRIu64";"
+ printf("%10u,%10u,%u,%"PRIu64",%"PRIu64",%"PRIu64",%"PRIu64","
"%"PRIu64"\n",
ctx->lcore_id,
ctx->options->max_buffer_size,
--
2.25.1
[dpdk-dev] [PATCH v3 3/4] test/cryptodev: add script to graph perf results
The python script introduced in this patch runs the crypto performance
test application for various test cases, and graphs the results.
Test cases are defined in config JSON files, this is where parameters
are specified for each test. Currently there are various test cases for
devices crypto_qat, crypto_aesni_mb and crypto_gcm. Tests for the
ptest types Throughput and Latency are supported for each.
The results of each test case are graphed and saved in PDFs (one PDF for
each test suite graph type, with all test cases).
The graphs output include various grouped barcharts for throughput
tests, and histogram and boxplot graphs are used for latency tests.
Documentation is added to outline the configuration and usage for the
script.
Usage:
A JSON config file must be specified when running the script,
"./dpdk-graph-crypto-perf "
The script uses the installed app by default (from ninja install).
Alternatively we can pass path to app by
"-f //app/dpdk-test-crypto-perf"
All device test suites are run by default.
Alternatively we can specify by adding arguments,
"-t latency" - to run latency test suite only
"-t throughput latency"
- to run both throughput and latency test suites
A directory can be specified for all output files,
or the script directory is used by default.
"-o "
To see the output from the dpdk-test-crypto-perf app,
use the verbose option "-v".
Signed-off-by: Ciara Power
Acked-by: Declan Doherty
Acked-by: Adam Dybkowski
---
v3:
- Moved script and configs to app/test-crypto-perf directory.
- Made small changes to commit log, documentation and MAINTAINERS
file to reflect the above change.
v2:
- Added functionality for additional args such as config file,
output directory and verbose.
- Improved help text for script.
- Improved script console output.
- Added support for latency test cases with burst or buffer size lists.
- Split config file into smaller config files, one for each device.
- Split output PDFs into smaller files, based on test suite graph types.
- Modified output directory naming and structure.
- Made some general improvements to script.
- Updated and improved documentation.
- Updated copyright year.
---
.../configs/crypto-perf-aesni-gcm.json| 99 ++
.../configs/crypto-perf-aesni-mb.json | 108 ++
.../configs/crypto-perf-qat.json | 94 ++
.../dpdk-graph-crypto-perf.py | 309 ++
doc/guides/tools/cryptoperf.rst | 143
5 files changed, 753 insertions(+)
create mode 100644 app/test-crypto-perf/configs/crypto-perf-aesni-gcm.json
create mode 100644 app/test-crypto-perf/configs/crypto-perf-aesni-mb.json
create mode 100644 app/test-crypto-perf/configs/crypto-perf-qat.json
create mode 100755 app/test-crypto-perf/dpdk-graph-crypto-perf.py
diff --git a/app/test-crypto-perf/configs/crypto-perf-aesni-gcm.json
b/app/test-crypto-perf/configs/crypto-perf-aesni-gcm.json
new file mode 100644
index 00..608a46e34f
--- /dev/null
+++ b/app/test-crypto-perf/configs/crypto-perf-aesni-gcm.json
@@ -0,0 +1,99 @@
+{
+ "throughput": {
+ "default": {
+ "eal": {
+ "l": "1,2",
+ "vdev": "crypto_aesni_gcm"
+ },
+ "app": {
+ "csv-friendly": true,
+ "buffer-sz":
"64,128,256,512,768,1024,1408,2048",
+ "burst-sz": "1,4,8,16,32",
+ "ptest": "throughput",
+ "devtype": "crypto_aesni_gcm"
+ }
+ },
+ "AES-GCM-128 aead-op encrypt": {
+ "aead-algo": "aes-gcm",
+ "aead-key-sz": "16",
+ "aead-iv-sz": "12",
+ "aead-op": "encrypt",
+ "aead-aad-sz": "16",
+ "digest-sz": "16",
+ "optype": "aead",
+ "total-ops": "1000"
+ },
+ "AES-GCM-128 aead-op decrypt": {
+ "aead-algo": "aes-gcm",
+ "aead-key-sz": "16",
+ "aead-op": "decrypt",
+ "aead-aad-sz": "16",
+ "aead-iv-sz": "12",
+ "digest-sz": "16",
+ "optype": "aead",
+ "total-ops": "1000"
+ },
+ "AES-GCM-256 aead-op encrypt": {
+ "aead-algo": "aes-gcm",
+ "aead-key-sz": "32",
+ "aead-op": "encrypt",
+ "aead-aad-sz": "32",
+ "aead-iv-sz": "12",
+ "digest-sz": "16",
+ "optype": "aead",
[dpdk-dev] [PATCH v3 4/4] maintainers: update crypto perf app maintainers
This patch adds a maintainer for the crypto perf test application, to cover the new perf test graphing script. Signed-off-by: Ciara Power Acked-by: Declan Doherty Acked-by: Adam Dybkowski --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index aa973a3960..395f8ec384 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1585,6 +1585,7 @@ F: doc/guides/tools/comp_perf.rst Crypto performance test application M: Declan Doherty +M: Ciara Power T: git://dpdk.org/next/dpdk-next-crypto F: app/test-crypto-perf/ F: doc/guides/tools/cryptoperf.rst -- 2.25.1
[dpdk-dev] crypto/qat: fix digest in buffer
This patch fixes the missed digest in buffer support to
QAT symmetric raw API. Originally digest in buffer is
supported only for wireless algorithms
Fixes: 728c76b0e50f ("crypto/qat: support raw datapath API")
Cc: roy.fan.zh...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
drivers/crypto/qat/qat_sym_hw_dp.c | 97 +++---
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git a/drivers/crypto/qat/qat_sym_hw_dp.c
b/drivers/crypto/qat/qat_sym_hw_dp.c
index dfbbad59b..01afb883e 100644
--- a/drivers/crypto/qat/qat_sym_hw_dp.c
+++ b/drivers/crypto/qat/qat_sym_hw_dp.c
@@ -558,55 +558,6 @@ enqueue_one_chain_job(struct qat_sym_session *ctx,
case ICP_QAT_HW_AUTH_ALGO_KASUMI_F9:
case ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3:
auth_param->u1.aad_adr = auth_iv->iova;
-
- if (unlikely(n_data_vecs > 1)) {
- int auth_end_get = 0, i = n_data_vecs - 1;
- struct rte_crypto_vec *cvec = &data[0];
- uint32_t len;
-
- len = data_len - ofs.ofs.auth.tail;
-
- while (i >= 0 && len > 0) {
- if (cvec->len >= len) {
- auth_iova_end = cvec->iova +
- (cvec->len - len);
- len = 0;
- auth_end_get = 1;
- break;
- }
- len -= cvec->len;
- i--;
- cvec++;
- }
-
- if (unlikely(auth_end_get == 0))
- return -1;
- } else
- auth_iova_end = data[0].iova + auth_param->auth_off +
- auth_param->auth_len;
-
- /* Then check if digest-encrypted conditions are met */
- if ((auth_param->auth_off + auth_param->auth_len <
- cipher_param->cipher_offset +
- cipher_param->cipher_length) &&
- (digest->iova == auth_iova_end)) {
- /* Handle partial digest encryption */
- if (cipher_param->cipher_offset +
- cipher_param->cipher_length <
- auth_param->auth_off +
- auth_param->auth_len +
- ctx->digest_length)
- req->comn_mid.dst_length =
- req->comn_mid.src_length =
- auth_param->auth_off +
- auth_param->auth_len +
- ctx->digest_length;
- struct icp_qat_fw_comn_req_hdr *header =
- &req->comn_hdr;
- ICP_QAT_FW_LA_DIGEST_IN_BUFFER_SET(
- header->serv_specif_flags,
- ICP_QAT_FW_LA_DIGEST_IN_BUFFER);
- }
break;
case ICP_QAT_HW_AUTH_ALGO_GALOIS_128:
case ICP_QAT_HW_AUTH_ALGO_GALOIS_64:
@@ -615,6 +566,54 @@ enqueue_one_chain_job(struct qat_sym_session *ctx,
break;
}
+ if (unlikely(n_data_vecs > 1)) {
+ int auth_end_get = 0, i = n_data_vecs - 1;
+ struct rte_crypto_vec *cvec = &data[0];
+ uint32_t len;
+
+ len = data_len - ofs.ofs.auth.tail;
+
+ while (i >= 0 && len > 0) {
+ if (cvec->len >= len) {
+ auth_iova_end = cvec->iova + len;
+ len = 0;
+ auth_end_get = 1;
+ break;
+ }
+ len -= cvec->len;
+ i--;
+ cvec++;
+ }
+
+ if (unlikely(auth_end_get == 0))
+ return -1;
+ } else
+ auth_iova_end = data[0].iova + auth_param->auth_off +
+ auth_param->auth_len;
+
+ /* Then check if digest-encrypted conditions are met */
+ if ((auth_param->auth_off + auth_param->auth_len <
+ cipher_param->cipher_offset +
+ cipher_param->cipher_length) &&
+ (digest->iova == auth_iova_end)) {
+ /* Handle partial digest encryption */
+ if (cipher_param->cipher_offset +
+ cipher_param->cipher_length <
+ auth_param->auth_off +
+ auth_param->auth_len +
+ ctx->digest_length)
+
Re: [dpdk-dev] DPDK 18.11.11 (LTS) released
On Wed, 2021-01-20 at 18:28 +0100, David Marchand wrote: > On Wed, Jan 20, 2021 at 6:12 PM Thomas Monjalon wrote: > > 20/01/2021 16:58, Kevin Traynor: > > > This is the last planned 18.11 LTS release. Thanks to the > > > authors who helped cleaning up the fixes that were hanging > > > around for a while and needed some attention. > > > > > > From this point onwards the 18.11 LTS branch is no longer > > > maintained. > > > > > > I want to acknowledge all the work done by validation > > > teams from Intel, Nvidia, Microsoft and Red Hat who have > > > made the releases possible by providing validation over the > > > last two years. > > > > > > Some statistics about 18.11 LTS releases: > > > - 1911 commits > > Now for Luca to reach 2011 commits. -- Kind regards, Luca Boccassi
Re: [dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
On Wed, Jan 20, 2021 at 5:40 PM David Marchand wrote: > There is probably better to do rather than disabling AVX512 globally for > Windows but since I saw no patch fixing this, here it is. Interesting... This patch does not work with UNH job. Seeing the same error but now on a different file, I am not sure what is wrong. -- David Marchand
Re: [dpdk-dev] [PATCH v2 02/44] bus/vdev: add driver IOVA VA mode requirement
On 1/20/21 4:32 PM, David Marchand wrote:
> On Tue, Jan 19, 2021 at 10:25 PM Maxime Coquelin
> wrote:
>>
>> This patch adds driver flag in vdev bus driver so that
>> vdev drivers can require VA IOVA mode to be used, which
>> for example the case of Virtio-user PMD.
>>
>> The patch implements the .get_iommu_class() callback, that
>> is called before devices probing to determine the IOVA mode
>> to be used.
>>
>> It also adds a check right before the device is probed to
>> ensure compatible IOVa mode has been selected.
>>
>> Signed-off-by: Maxime Coquelin
>> ---
>> drivers/bus/vdev/rte_bus_vdev.h | 4
>> drivers/bus/vdev/vdev.c | 31 +++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/bus/vdev/rte_bus_vdev.h
>> b/drivers/bus/vdev/rte_bus_vdev.h
>> index f99a41f825..c8b41e649c 100644
>> --- a/drivers/bus/vdev/rte_bus_vdev.h
>> +++ b/drivers/bus/vdev/rte_bus_vdev.h
>> @@ -113,8 +113,12 @@ struct rte_vdev_driver {
>> rte_vdev_remove_t *remove; /**< Virtual device remove
>> function. */
>> rte_vdev_dma_map_t *dma_map; /**< Virtual device DMA map
>> function. */
>> rte_vdev_dma_unmap_t *dma_unmap; /**< Virtual device DMA unmap
>> function. */
>> + uint32_t drv_flags;/**< Flags RTE_VDEV_DRV_*. */
>
> This will probably get broken in the future, but for now, can you
> indent the comment in the same way as earlier lines?
>
>
> The ABI check will complain about this change so we need an exception.
>
> rte_vdev_driver is exposed only through driver API.
> We could flag the whole structure like we did for ethdev.
> But there is also the alternative of just flagging the required
> symbols so that we won't miss later the inclusion of this structure in
> an API used by final users.
> How about:
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 1dc84fa74b..435913d908 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -11,6 +11,8 @@
> ; Explicit ignore for driver-only ABI
> [suppress_type]
> name = eth_dev_ops
> +[suppress_function]
> +name_regexp = rte_vdev_(|un)register
>
> ; Ignore fields inserted in cacheline boundary of rte_cryptodev
> [suppress_type]
>
>
This is fine by me.
>> };
>>
>> +/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
>> +#define RTE_VDEV_DRV_NEED_IOVA_AS_VA 0x0001
>> +
>> /**
>> * Register a virtual device driver.
>> *
>> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
>> index acfd78828f..56f15e8201 100644
>> --- a/drivers/bus/vdev/vdev.c
>> +++ b/drivers/bus/vdev/vdev.c
>> @@ -189,6 +189,7 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>> {
>> const char *name;
>> struct rte_vdev_driver *driver;
>> + enum rte_iova_mode iova_mode;
>> int ret;
>>
>> if (rte_dev_is_probed(&dev->device))
>> @@ -199,6 +200,14 @@ vdev_probe_all_drivers(struct rte_vdev_device *dev)
>>
>> if (vdev_parse(name, &driver))
>> return -1;
>> +
>> + iova_mode = rte_eal_iova_mode();
>> + if ((driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA) && (iova_mode
>> == RTE_IOVA_PA)) {
>> + VDEV_LOG(ERR, "%s requires VA IOVA mode but current mode is
>> PA, not initializing",
>> + name);
>> + return -1;
>> + }
>> +
>> ret = driver->probe(dev);
>> if (ret == 0)
>> dev->device.driver = &driver->driver;
>> @@ -594,6 +603,27 @@ vdev_unplug(struct rte_device *dev)
>> return rte_vdev_uninit(dev->name);
>> }
>>
>> +static enum rte_iova_mode
>> +vdev_get_iommu_class(void)
>> +{
>> + const char *name;
>> + struct rte_vdev_device *dev;
>> + struct rte_vdev_driver *driver;
>> +
>> + TAILQ_FOREACH(dev, &vdev_device_list, next) {
>> + name = rte_vdev_device_name(dev);
>> + if (!name)
>> + continue;
>
> Afaics, a device in vdev_device_list always has a name.
Indeed, I will remove the check in next revision.
Thanks,
Maxime
>
>> + if (vdev_parse(name, &driver))
>> + continue;
>> +
>> + if (driver->drv_flags & RTE_VDEV_DRV_NEED_IOVA_AS_VA)
>> + return RTE_IOVA_VA;
>> + }
>> +
>> + return RTE_IOVA_DC;
>> +}
>> +
>> static struct rte_bus rte_vdev_bus = {
>> .scan = vdev_scan,
>> .probe = vdev_probe,
>> @@ -603,6 +633,7 @@ static struct rte_bus rte_vdev_bus = {
>> .parse = vdev_parse,
>> .dma_map = vdev_dma_map,
>> .dma_unmap = vdev_dma_unmap,
>> + .get_iommu_class = vdev_get_iommu_class,
>> .dev_iterate = rte_vdev_dev_iterate,
>> };
>>
>> --
>> 2.29.2
>>
>
>
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On 1/20/2021 10:05 AM, Ali Alnubani wrote: For info, I don't reproduce the compilation issue on my machine. My build system has been upgraded from fc31 to fc32 so I guess this has something to do with it. I can reproduce with (Fedora MinGW 9.2.1-6.fc32), but not with (Fedora MinGW 10.2.1-2.fc33). First of all, for the patch @Tal provided its link, the windows build and the mingw build errors are different. And the windows build error should be already fixed by a patch that squashed in next-net (https://patches.dpdk.org/patch/86804/). And for the mingw, I have same result with Ali, I can reproduce with (Fedora MinGW 9.2.1-6.fc32). But different from the CI, I am getting the error [1] for all following files: rte_random.c i40e_rxtx_vec_sse.c i40e_rxtx_vec_avx512.c i40e_rxtx_vec_avx2.c rte_ethdev.c [1] Error: invalid register for .seh_savexmm There is a stackoverflow entry for it: https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin If I use '-fno-asynchronous-unwind-tables' as suggested there, the build works fine. So the problem may not be just 'i40e_rxtx_vec_avx512.c'. If I change the machine type from 'native' to 'corei7' [2], the build error reduced to only 'i40e_rxtx_vec_avx512.c', so the problem seems happens when avx512 is supported by CPU, in this case compiler seems has a defect. And since for 'i40e_rxtx_vec_avx512.c' the '-march=skylake-avx512' explicitly set can cause the problem seen in all machines. [2] diff --git a/config/x86/cross-mingw b/config/x86/cross-mingw index 4c15a7fa2e..7cee238add 100644 --- a/config/x86/cross-mingw +++ b/config/x86/cross-mingw @@ -9,5 +9,5 @@ pkgconfig = 'x86_64-w64-mingw32-pkg-config' [host_machine] system = 'windows' cpu_family = 'x86_64' -cpu = 'native' +cpu = 'corei7' endian = 'little' @Ranjit, @Pallavi, Are you building using mingw, and if so are you observing same problem?
Re: [dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
On 1/20/2021 5:46 PM, David Marchand wrote: On Wed, Jan 20, 2021 at 5:40 PM David Marchand wrote: There is probably better to do rather than disabling AVX512 globally for Windows but since I saw no patch fixing this, here it is. Interesting... This patch does not work with UNH job. Seeing the same error but now on a different file, I am not sure what is wrong. I have just replied to the original thread [1], the problem seems not just related to the 'i40e_rxtx_vec_avx512.c'. [1] http://inbox.dpdk.org/dev/20201215021945.103396-1-leyi.r...@intel.com/T/#mc47abfa0b72b068f26f4b8deb0dacea840d721e9
Re: [dpdk-dev] [PATCH v7] app/testpmd: fix testpmd packets dump overlapping
On 1/20/2021 6:50 AM, Jiawei Wang wrote:
When testpmd enabled the verbosity for the received packets, if two packets
were received at the same time, for example, sampling packet and normal
packet, the dump output of these packets may be overlapping due to multiple
core handling the multiple queues simultaneously.
The patch uses one string buffer that collects all the packet dump output
into this buffer and then printouts it at last, that guarantees to printout
separately the dump output per packet.
Fixes: d862c45 ("app/testpmd: move dumping packets to a separate function")
Signed-off-by: Jiawei Wang
Acked-by: Viacheslav Ovsiienko
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On 1/20/2021 5:51 PM, Ferruh Yigit wrote: On 1/20/2021 10:05 AM, Ali Alnubani wrote: For info, I don't reproduce the compilation issue on my machine. My build system has been upgraded from fc31 to fc32 so I guess this has something to do with it. I can reproduce with (Fedora MinGW 9.2.1-6.fc32), but not with (Fedora MinGW 10.2.1-2.fc33). First of all, for the patch @Tal provided its link, the windows build and the mingw build errors are different. And the windows build error should be already fixed by a patch that squashed in next-net (https://patches.dpdk.org/patch/86804/). And for the mingw, I have same result with Ali, I can reproduce with (Fedora MinGW 9.2.1-6.fc32). But different from the CI, I am getting the error [1] for all following files: rte_random.c i40e_rxtx_vec_sse.c i40e_rxtx_vec_avx512.c i40e_rxtx_vec_avx2.c rte_ethdev.c [1] Error: invalid register for .seh_savexmm Build log for above errors: https://pastebin.com/jD4jRVzL There is a stackoverflow entry for it: https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin If I use '-fno-asynchronous-unwind-tables' as suggested there, the build works fine. So the problem may not be just 'i40e_rxtx_vec_avx512.c'. If I change the machine type from 'native' to 'corei7' [2], the build error reduced to only 'i40e_rxtx_vec_avx512.c', so the problem seems happens when avx512 is supported by CPU, in this case compiler seems has a defect. And since for 'i40e_rxtx_vec_avx512.c' the '-march=skylake-avx512' explicitly set can cause the problem seen in all machines. [2] diff --git a/config/x86/cross-mingw b/config/x86/cross-mingw index 4c15a7fa2e..7cee238add 100644 --- a/config/x86/cross-mingw +++ b/config/x86/cross-mingw @@ -9,5 +9,5 @@ pkgconfig = 'x86_64-w64-mingw32-pkg-config' [host_machine] system = 'windows' cpu_family = 'x86_64' -cpu = 'native' +cpu = 'corei7' endian = 'little' @Ranjit, @Pallavi, Are you building using mingw, and if so are you observing same problem?
Re: [dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
On Wed, 20 Jan 2021 17:40:16 +0100, David Marchand wrote:
> There is probably better to do rather than disabling AVX512 globally for
> Windows but since I saw no patch fixing this, here it is.
>
> ---
> drivers/net/i40e/meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
> index c0acdf4fd4..c9a1a50407 100644
> --- a/drivers/net/i40e/meson.build
> +++ b/drivers/net/i40e/meson.build
> @@ -54,7 +54,7 @@ if arch_subdir == 'x86'
> cc.has_argument('-mavx512f') and
> cc.has_argument('-mavx512bw'))
>
> - if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
> + if not is_windows and (i40e_avx512_cpu_support == true or
> i40e_avx512_cc_support == true)
> cflags += ['-DCC_AVX512_SUPPORT']
> avx512_args = [cflags, '-mavx512f', '-mavx512bw']
> if cc.has_argument('-march=skylake-avx512')
Clang doesn't seem to be affected, suggesting a cc.get_id() == 'gcc' check.
The error seems related to SEH (structured exception handling). Some MinGW
flavours don't use it, which can explain why the bug isn't not 100%
reproducible. IMO, just disabling AVX512 for MinGW is enough.
A nit, is there a reason to prefer "x == true" over "x"?
Re: [dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
On 1/20/2021 6:21 PM, Dmitry Kozlyuk wrote:
On Wed, 20 Jan 2021 17:40:16 +0100, David Marchand wrote:
There is probably better to do rather than disabling AVX512 globally for
Windows but since I saw no patch fixing this, here it is.
---
drivers/net/i40e/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
index c0acdf4fd4..c9a1a50407 100644
--- a/drivers/net/i40e/meson.build
+++ b/drivers/net/i40e/meson.build
@@ -54,7 +54,7 @@ if arch_subdir == 'x86'
cc.has_argument('-mavx512f') and
cc.has_argument('-mavx512bw'))
- if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
+ if not is_windows and (i40e_avx512_cpu_support == true or
i40e_avx512_cc_support == true)
cflags += ['-DCC_AVX512_SUPPORT']
avx512_args = [cflags, '-mavx512f', '-mavx512bw']
if cc.has_argument('-march=skylake-avx512')
Clang doesn't seem to be affected, suggesting a cc.get_id() == 'gcc' check.
The error seems related to SEH (structured exception handling). Some MinGW
flavours don't use it, which can explain why the bug isn't not 100%
reproducible. IMO, just disabling AVX512 for MinGW is enough.
Is there a way to disable it selectively, only for the compiler versions that
doesn't support it?
A nit, is there a reason to prefer "x == true" over "x"?
[dpdk-dev] [PATCH 1/2] net/mlx5: fix MARK action in active tunnel offload
Tunnel offload mode allows application to restore partially offloaded tunneled packets to its original state. MLX5 PMD stores internal data required to restore partially offloaded packet in packet mark section. Therefore MLX5 PMD will not allow applications to use mark action if tunnel offload mode was activated. The restriction is applied both to regular and tunnel offload rules. The patch rejects application rules with mark action while tunnel offload is active. Signed-off-by: Gregory Etelson Acked-by: Viacheslav Ovsiienko --- drivers/net/mlx5/mlx5_flow_dv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c index 4f638e24ad..ede484d026 100644 --- a/drivers/net/mlx5/mlx5_flow_dv.c +++ b/drivers/net/mlx5/mlx5_flow_dv.c @@ -2375,6 +2375,11 @@ flow_dv_validate_action_mark(struct rte_eth_dev *dev, const struct rte_flow_action_mark *mark = action->conf; int ret; + if (is_tunnel_offload_active(dev)) + return rte_flow_error_set(error, ENOTSUP, + RTE_FLOW_ERROR_TYPE_ACTION, NULL, + "no mark action " + "if tunnel offload active"); /* Fall back if no extended metadata register support. */ if (config->dv_xmeta_en == MLX5_XMETA_MODE_LEGACY) return mlx5_flow_validate_action_mark(action, action_flags, -- 2.29.2
[dpdk-dev] [PATCH 2/2] net/mlx5: fix DROP action in tunnel offload mode
Tunnel offload mode allows application to restore partially offloaded tunneled packets to its original state. The mode was designed to optimize packet recovery. It must not block flow actions that are allowed by MLX5 PMD. The patch allows tunnel offload match rules to use drop flow action. Signed-off-by: Gregory Etelson Acked-by: Viacheslav Ovsiienko --- drivers/net/mlx5/mlx5_flow_dv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c index ede484d026..bb3af246cd 100644 --- a/drivers/net/mlx5/mlx5_flow_dv.c +++ b/drivers/net/mlx5/mlx5_flow_dv.c @@ -6087,8 +6087,11 @@ flow_dv_validate(struct rte_eth_dev *dev, const struct rte_flow_attr *attr, * Validate the drop action mutual exclusion with other actions. * Drop action is mutually-exclusive with any other action, except for * Count action. +* Drop action compatibility with tunnel offload was already validated. */ - if ((action_flags & MLX5_FLOW_ACTION_DROP) && + if (action_flags & (MLX5_FLOW_ACTION_TUNNEL_MATCH | + MLX5_FLOW_ACTION_TUNNEL_MATCH)); + else if ((action_flags & MLX5_FLOW_ACTION_DROP) && (action_flags & ~(MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_COUNT))) return rte_flow_error_set(error, EINVAL, RTE_FLOW_ERROR_TYPE_ACTION, NULL, -- 2.29.2
Re: [dpdk-dev] [PATCH] net/i40e: disable AVX512 for Windows
On Wed, 20 Jan 2021 18:24:43 +, Ferruh Yigit wrote:
> On 1/20/2021 6:21 PM, Dmitry Kozlyuk wrote:
> > On Wed, 20 Jan 2021 17:40:16 +0100, David Marchand wrote:
> >> There is probably better to do rather than disabling AVX512 globally for
> >> Windows but since I saw no patch fixing this, here it is.
> >>
> >> ---
> >> drivers/net/i40e/meson.build | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
> >> index c0acdf4fd4..c9a1a50407 100644
> >> --- a/drivers/net/i40e/meson.build
> >> +++ b/drivers/net/i40e/meson.build
> >> @@ -54,7 +54,7 @@ if arch_subdir == 'x86'
> >>cc.has_argument('-mavx512f') and
> >>cc.has_argument('-mavx512bw'))
> >>
> >> - if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
> >> + if not is_windows and (i40e_avx512_cpu_support == true or
> >> i40e_avx512_cc_support == true)
> >>cflags += ['-DCC_AVX512_SUPPORT']
> >>avx512_args = [cflags, '-mavx512f', '-mavx512bw']
> >>if cc.has_argument('-march=skylake-avx512')
> >
> > Clang doesn't seem to be affected, suggesting a cc.get_id() == 'gcc' check.
> >
> > The error seems related to SEH (structured exception handling). Some MinGW
> > flavours don't use it, which can explain why the bug isn't not 100%
> > reproducible. IMO, just disabling AVX512 for MinGW is enough.
> >
>
> Is there a way to disable it selectively, only for the compiler versions that
> doesn't support it?
It was a guesswork and it proved wrong, setsmp/longjmp flavour [1] with
GCC 8.1.0 also fails. Fedora 32 has GCC 9.2.1 (works), while Fedora 33 has
GCC 10.2.1 (fails). I use a reproducible environment [2] with GCC 9.3.0,
which succeeds. Seems like GCC 9 is the only known version that works, which
is pretty close to "doesn't work with MinGW at all".
[1]:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-win32/sjlj/x86_64-8.1.0-release-win32-sjlj-rt_v6-rev0.7z
[2]: https://github.com/PlushBeaver/nix-shells/tree/master/dpdk
[dpdk-dev] [PATCH 1/1] doc: simplify OS support in features matrix
The networking drivers features matrix had rows to show OS and kernel modules support: - BSD nic_uio - Linux UIO - Linux VFIO - Other kdrv - Windows The kernel modules details are removed to keep only OS support: - FreeBSD - Linux - Windows Signed-off-by: Thomas Monjalon --- doc/guides/nics/features.rst | 36 ++ doc/guides/nics/features/ark.ini | 2 +- doc/guides/nics/features/atlantic.ini | 2 +- doc/guides/nics/features/avp.ini | 2 +- doc/guides/nics/features/axgbe.ini | 2 +- doc/guides/nics/features/bnx2x.ini | 2 +- doc/guides/nics/features/bnxt.ini | 5 ++- doc/guides/nics/features/cxgbe.ini | 5 ++- doc/guides/nics/features/cxgbevf.ini | 3 +- doc/guides/nics/features/default.ini | 6 ++-- doc/guides/nics/features/dpaa2.ini | 2 +- doc/guides/nics/features/e1000.ini | 5 ++- doc/guides/nics/features/ena.ini | 3 +- doc/guides/nics/features/enetc.ini | 2 +- doc/guides/nics/features/enic.ini | 5 ++- doc/guides/nics/features/fm10k.ini | 5 ++- doc/guides/nics/features/fm10k_vf.ini | 5 ++- doc/guides/nics/features/hinic.ini | 3 +- doc/guides/nics/features/hns3.ini | 3 +- doc/guides/nics/features/hns3_vf.ini | 3 +- doc/guides/nics/features/i40e.ini | 5 ++- doc/guides/nics/features/i40e_vf.ini | 5 ++- doc/guides/nics/features/iavf.ini | 5 ++- doc/guides/nics/features/ice.ini | 5 ++- doc/guides/nics/features/ice_dcf.ini | 3 +- doc/guides/nics/features/igb.ini | 5 ++- doc/guides/nics/features/igb_vf.ini| 5 ++- doc/guides/nics/features/igc.ini | 3 +- doc/guides/nics/features/ionic.ini | 3 +- doc/guides/nics/features/ipn3ke.ini| 5 ++- doc/guides/nics/features/ixgbe.ini | 5 ++- doc/guides/nics/features/ixgbe_vf.ini | 5 ++- doc/guides/nics/features/liquidio.ini | 3 +- doc/guides/nics/features/mlx4.ini | 2 +- doc/guides/nics/features/mlx5.ini | 2 +- doc/guides/nics/features/netvsc.ini| 2 +- doc/guides/nics/features/nfb.ini | 2 +- doc/guides/nics/features/nfp.ini | 3 +- doc/guides/nics/features/octeontx.ini | 2 +- doc/guides/nics/features/octeontx2.ini | 2 +- doc/guides/nics/features/octeontx2_vec.ini | 2 +- doc/guides/nics/features/octeontx2_vf.ini | 2 +- doc/guides/nics/features/pfe.ini | 2 +- doc/guides/nics/features/qede.ini | 3 +- doc/guides/nics/features/qede_vf.ini | 3 +- doc/guides/nics/features/sfc_efx.ini | 5 ++- doc/guides/nics/features/szedata2.ini | 2 +- doc/guides/nics/features/tap.ini | 2 +- doc/guides/nics/features/thunderx.ini | 2 +- doc/guides/nics/features/txgbe.ini | 3 +- doc/guides/nics/features/virtio.ini| 5 ++- doc/guides/nics/features/vmxnet3.ini | 3 +- doc/guides/vdpadevs/features/default.ini | 7 ++--- doc/guides/vdpadevs/features/mlx5.ini | 2 +- doc/guides/vdpadevs/features_overview.rst | 11 +++ 55 files changed, 86 insertions(+), 141 deletions(-) diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst index cf82e9d57f..59beb47316 100644 --- a/doc/guides/nics/features.rst +++ b/doc/guides/nics/features.rst @@ -785,38 +785,20 @@ Multiprocess aware Driver can be used for primary-secondary process model. -.. _nic_features_bsd_nic_uio: +.. _nic_features_freebsd: -BSD nic_uio +FreeBSD +--- -BSD ``nic_uio`` module supported. +Supports running on FreeBSD. -.. _nic_features_linux_uio: +.. _nic_features_linux: -Linux UIO -- +Linux +- -Works with ``igb_uio`` kernel module. - -* **[provides] RTE_PMD_REGISTER_KMOD_DEP**: ``igb_uio``. - -.. _nic_features_linux_vfio: - -Linux VFIO --- - -Works with ``vfio-pci`` kernel module. - -* **[provides] RTE_PMD_REGISTER_KMOD_DEP**: ``vfio-pci``. - -.. _nic_features_other_kdrv: - -Other kdrv --- - -Kernel module other than above ones supported. +Supports running on Linux. .. _nic_features_windows: @@ -824,7 +806,7 @@ Kernel module other than above ones supported. Windows --- -Support Windows. +Supports running on Windows. .. _nic_features_armv7: diff --git a/doc/guides/nics/features/ark.ini b/doc/guides/nics/features/ark.ini index ec8a2b9983..5519984e39 100644 --- a/doc/guides/nics/features/ark.ini +++ b/doc/guides/nics/features/ark.ini @@ -10,6 +10,6 @@ Jumbo frame = Y Scattered Rx = Y Basic stats = Y Stats per queue = Y -Linux UIO= Y +Linux= Y x86-64 = Y Usage doc= Y diff --git a/doc/guides/nics/features/atlantic.ini b/doc/guides/nics/features/atlantic.ini index 2bb8ecc017..d2ec33b217 100644 --- a
Re: [dpdk-dev] [PATCH v1] net/e1000: fix the invalid flow control mode setting
> -Original Message-
> From: dev On Behalf Of Guo, Jia
> Sent: Wednesday, January 20, 2021 3:19 PM
> To: Wu, Wenjun1 ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] net/e1000: fix the invalid flow control
> mode
> setting
>
> Acked-by: Jeff Guo
>
> > -Original Message-
> > From: Wu, Wenjun1
> > Sent: Wednesday, January 20, 2021 2:54 PM
> > To: dev@dpdk.org; Guo, Jia
> > Cc: Wu, Wenjun1 ; sta...@dpdk.org
> > Subject: [PATCH v1] net/e1000: fix the invalid flow control mode
> > setting
> >
> > E1000_CTRL register should be updated according to fc_conf->mode's value.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wenjun Wu
Applied to dpdk-next-net-intel.
Thanks
Qi
[dpdk-dev] [PATCH 0/4] ice base code update batch 3
Qi Zhang (4): net/ice/base: fix wrong macro value net/ice/base: add VLAN TPID for VLAN filters net/ice/base: add support for configuring the device in Double VLAN Mode net/ice: add new supported device IDs drivers/net/ice/base/README | 2 +- drivers/net/ice/base/ice_adminq_cmd.h | 38 +++- drivers/net/ice/base/ice_common.c | 2 - drivers/net/ice/base/ice_devids.h | 10 + drivers/net/ice/base/ice_flex_pipe.c | 9 +- drivers/net/ice/base/ice_switch.c | 64 ++ drivers/net/ice/base/ice_switch.h | 14 ++ drivers/net/ice/base/ice_type.h | 2 +- drivers/net/ice/base/ice_vlan_mode.c | 284 -- drivers/net/ice/base/ice_vlan_mode.h | 24 +-- drivers/net/ice/ice_ethdev.c | 5 + 11 files changed, 406 insertions(+), 48 deletions(-) -- 2.26.2
[dpdk-dev] [PATCH 1/4] net/ice/base: fix wrong macro value
Fix the wrong value of ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST
Fixes: 9ea028123a0b ("net/ice/base: align add VSI and update VSI AQ command
buffer")
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 09d0f176c9..74ac76a132 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -500,7 +500,7 @@ struct ice_aqc_vsi_props {
#define ICE_AQ_VSI_OUTER_TAG_VLAN_8100 0x2
#define ICE_AQ_VSI_OUTER_TAG_VLAN_9100 0x3
#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_INSERTBIT(4)
-#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST BIT(4)
+#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST BIT(6)
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_S5
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_M(0x3 <<
ICE_AQ_VSI_OUTER_VLAN_TX_MODE_S)
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_ACCEPTUNTAGGED 0x1
--
2.26.2
[dpdk-dev] [PATCH 2/4] net/ice/base: add VLAN TPID for VLAN filters
Currently VLAN filters via RID4 are only based on VLAN ID. However, with
incoming support for Double VLAN Mode (DVM), the driver needs to be able
to support filtering on VLAN ID + VLAN TPID (i.e. 0x8100, 0x88a8, etc.).
Add support for this by adding two fields to the ice_fltr_info
structure. First, add the tpid_valid field so the code can determine
whether or not to overwrite the default 0x8100 value for programming
packets or use the tpid field.
Signed-off-by: Brett Creeley
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_switch.c | 6 ++
drivers/net/ice/base/ice_switch.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index 692a147e66..277623d2bb 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -14,6 +14,7 @@
#define ICE_PPP_IPV6_PROTO_ID 0x0057
#define ICE_IPV6_ETHER_ID 0x86DD
#define ICE_TCP_PROTO_ID 0x06
+#define ICE_ETH_P_8021Q0x8100
/* Dummy ethernet header needed in the ice_aqc_sw_rules_elem
* struct to configure any switch filter rules.
@@ -3441,6 +3442,7 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
struct ice_aqc_sw_rules_elem *s_rule, enum ice_adminq_opc opc)
{
u16 vlan_id = ICE_MAX_VLAN_ID + 1;
+ u16 vlan_tpid = ICE_ETH_P_8021Q;
void *daddr = NULL;
u16 eth_hdr_sz;
u8 *eth_hdr;
@@ -3513,6 +3515,8 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
break;
case ICE_SW_LKUP_VLAN:
vlan_id = f_info->l_data.vlan.vlan_id;
+ if (f_info->l_data.vlan.tpid_valid)
+ vlan_tpid = f_info->l_data.vlan.tpid;
if (f_info->fltr_act == ICE_FWD_TO_VSI ||
f_info->fltr_act == ICE_FWD_TO_VSI_LIST) {
act |= ICE_SINGLE_ACT_PRUNE;
@@ -3556,6 +3560,8 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
if (!(vlan_id > ICE_MAX_VLAN_ID)) {
off = (_FORCE_ __be16 *)(eth_hdr + ICE_ETH_VLAN_TCI_OFFSET);
*off = CPU_TO_BE16(vlan_id);
+ off = (_FORCE_ __be16 *)(eth_hdr + ICE_ETH_ETHTYPE_OFFSET);
+ *off = CPU_TO_BE16(vlan_tpid);
}
/* Create the switch rule with the final dummy Ethernet header */
diff --git a/drivers/net/ice/base/ice_switch.h
b/drivers/net/ice/base/ice_switch.h
index c11c064725..a0a7a2e533 100644
--- a/drivers/net/ice/base/ice_switch.h
+++ b/drivers/net/ice/base/ice_switch.h
@@ -160,6 +160,8 @@ struct ice_fltr_info {
} mac_vlan;
struct {
u16 vlan_id;
+ u16 tpid;
+ u8 tpid_valid;
} vlan;
/* Set lkup_type as ICE_SW_LKUP_ETHERTYPE
* if just using ethertype as filter. Set lkup_type as
--
2.26.2
[dpdk-dev] [PATCH 3/4] net/ice/base: add support for configuring the device in Double VLAN Mode
In order to support configuring the device in Double VLAN Mode (DVM),
the DDP and FW have to support DVM. If both support DVM, the PF
that downloads the package needs to update the default recipes and set
the VLAN mode. This is done in ice_set_dvm().
In order to support updating the default recipes in DVM add support
for updating an existing switch recipe's lkup_idx and mask.
This is done by first calling the get recipe AQ (0x0292) with the
desired recipe ID. Then, if that is successful update one of the lookup
indices (lkup_idx) and its associated mask if the mask is valid
otherwise the already existing mask will be used.
Signed-off-by: Brett Creeley
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 36
drivers/net/ice/base/ice_common.c | 2 -
drivers/net/ice/base/ice_flex_pipe.c | 9 +-
drivers/net/ice/base/ice_switch.c | 58 ++
drivers/net/ice/base/ice_switch.h | 12 ++
drivers/net/ice/base/ice_type.h | 2 +-
drivers/net/ice/base/ice_vlan_mode.c | 284 --
drivers/net/ice/base/ice_vlan_mode.h | 24 +--
8 files changed, 381 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 74ac76a132..8f72f0db33 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -358,6 +358,40 @@ struct ice_aqc_get_allocd_res_desc {
__le32 addr_low;
};
+/* Request buffer for Set VLAN Mode AQ command (indirect 0x020C) */
+struct ice_aqc_set_vlan_mode {
+ u8 reserved;
+ u8 l2tag_prio_tagging;
+#define ICE_AQ_VLAN_PRIO_TAG_S 0
+#define ICE_AQ_VLAN_PRIO_TAG_M (0x7 << ICE_AQ_VLAN_PRIO_TAG_S)
+#define ICE_AQ_VLAN_PRIO_TAG_NOT_SUPPORTED 0x0
+#define ICE_AQ_VLAN_PRIO_TAG_STAG 0x1
+#define ICE_AQ_VLAN_PRIO_TAG_OUTER_CTAG0x2
+#define ICE_AQ_VLAN_PRIO_TAG_OUTER_VLAN0x3
+#define ICE_AQ_VLAN_PRIO_TAG_INNER_CTAG0x4
+#define ICE_AQ_VLAN_PRIO_TAG_MAX 0x4
+#define ICE_AQ_VLAN_PRIO_TAG_ERROR 0x7
+ u8 l2tag_reserved[64];
+ u8 rdma_packet;
+#define ICE_AQ_VLAN_RDMA_TAG_S 0
+#define ICE_AQ_VLAN_RDMA_TAG_M (0x3F << ICE_AQ_VLAN_RDMA_TAG_S)
+#define ICE_AQ_SVM_VLAN_RDMA_PKT_FLAG_SETTING 0x10
+#define ICE_AQ_DVM_VLAN_RDMA_PKT_FLAG_SETTING 0x1A
+ u8 rdma_reserved[2];
+ u8 mng_vlan_prot_id;
+#define ICE_AQ_VLAN_MNG_PROTOCOL_ID_OUTER 0x10
+#define ICE_AQ_VLAN_MNG_PROTOCOL_ID_INNER 0x11
+ u8 prot_id_reserved[30];
+};
+
+/* Response buffer for Get VLAN Mode AQ command (indirect 0x020D) */
+struct ice_aqc_get_vlan_mode {
+ u8 vlan_mode;
+#define ICE_AQ_VLAN_MODE_DVM_ENA BIT(0)
+ u8 l2tag_prio_tagging;
+ u8 reserved[98];
+};
+
/* Add VSI (indirect 0x0210)
* Update VSI (indirect 0x0211)
* Get VSI (indirect 0x0212)
@@ -2911,6 +2945,8 @@ enum ice_adminq_opc {
ice_aqc_opc_alloc_res = 0x0208,
ice_aqc_opc_free_res= 0x0209,
ice_aqc_opc_get_allocd_res_desc = 0x020A,
+ ice_aqc_opc_set_vlan_mode_parameters= 0x020C,
+ ice_aqc_opc_get_vlan_mode_parameters= 0x020D,
/* VSI commands */
ice_aqc_opc_add_vsi = 0x0210,
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index d3178240b2..bef7c83512 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -836,8 +836,6 @@ enum ice_status ice_init_hw(struct ice_hw *hw)
goto err_unroll_fltr_mgmt_struct;
ice_init_lock(&hw->tnl_lock);
- ice_init_vlan_mode_ops(hw);
-
return ICE_SUCCESS;
err_unroll_fltr_mgmt_struct:
diff --git a/drivers/net/ice/base/ice_flex_pipe.c
b/drivers/net/ice/base/ice_flex_pipe.c
index 31047d1eda..cf470bc4f0 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -1152,6 +1152,7 @@ static enum ice_status
ice_download_pkg(struct ice_hw *hw, struct ice_seg *ice_seg)
{
struct ice_buf_table *ice_buf_tbl;
+ enum ice_status status;
ice_debug(hw, ICE_DBG_TRACE, "%s\n", __func__);
ice_debug(hw, ICE_DBG_PKG, "Segment format version: %d.%d.%d.%d\n",
@@ -1169,8 +1170,12 @@ ice_download_pkg(struct ice_hw *hw, struct ice_seg
*ice_seg)
ice_debug(hw, ICE_DBG_PKG, "Seg buf count: %d\n",
LE32_TO_CPU(ice_buf_tbl->buf_count));
- return ice_dwnld_cfg_bufs(hw, ice_buf_tbl->buf_array,
- LE32_TO_CPU(ice_buf_tbl->buf_count));
+ status = ice_dwnld_cfg_bufs(hw, ice_buf_tbl->buf_array,
+ LE32_TO_CPU(ice_buf_tbl->buf_count));
+
+ ice_cache_vlan_mode(hw);
+
+ return status;
}
/**
diff --git a/drivers/net/ice/base/ice_switch
[dpdk-dev] [PATCH 4/4] net/ice: add new supported device IDs
Add device ID support for family E823C, also update the base code
BSD version.
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/README | 2 +-
drivers/net/ice/base/ice_devids.h | 10 ++
drivers/net/ice/ice_ethdev.c | 5 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/README b/drivers/net/ice/base/README
index bc42736bdd..7d32e58a52 100644
--- a/drivers/net/ice/base/README
+++ b/drivers/net/ice/base/README
@@ -6,7 +6,7 @@ Intel® ICE driver
==
This directory contains source code of FreeBSD ice driver of version
-2021.01.07 released by the team which develops
+2021.01.20 released by the team which develops
basic drivers for any ice NIC. The directory of base/ contains the
original source package.
This driver is valid for the product(s) listed below
diff --git a/drivers/net/ice/base/ice_devids.h
b/drivers/net/ice/base/ice_devids.h
index 93110055e2..b4cdddc8e7 100644
--- a/drivers/net/ice/base/ice_devids.h
+++ b/drivers/net/ice/base/ice_devids.h
@@ -28,6 +28,16 @@
#define ICE_DEV_ID_E810_XXV_QSFP 0x159A
/* Intel(R) Ethernet Controller E810-XXV for SFP */
#define ICE_DEV_ID_E810_XXV_SFP0x159B
+/* Intel(R) Ethernet Connection E823-C for backplane */
+#define ICE_DEV_ID_E823C_BACKPLANE 0x188A
+/* Intel(R) Ethernet Connection E823-C for QSFP */
+#define ICE_DEV_ID_E823C_QSFP 0x188B
+/* Intel(R) Ethernet Connection E823-C for SFP */
+#define ICE_DEV_ID_E823C_SFP 0x188C
+/* Intel(R) Ethernet Connection E823-C/X557-AT 10GBASE-T */
+#define ICE_DEV_ID_E823C_10G_BASE_T0x188D
+/* Intel(R) Ethernet Connection E823-C 1GbE */
+#define ICE_DEV_ID_E823C_SGMII 0x188E
/* Intel(R) Ethernet Connection E822-C for backplane */
#define ICE_DEV_ID_E822C_BACKPLANE 0x1890
/* Intel(R) Ethernet Connection E822-C for QSFP */
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index ec29f0fe40..f33c3cbffe 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -152,6 +152,11 @@ static const struct rte_pci_id pci_id_ice_map[] = {
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_BACKPLANE) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_QSFP) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_SFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_BACKPLANE) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_QSFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_SFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_10G_BASE_T) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_SGMII) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_BACKPLANE) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_QSFP) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_SFP) },
--
2.26.2
[dpdk-dev] [PATCH 0/4] ice base code update batch 3
Qi Zhang (4): net/ice/base: fix wrong macro value net/ice/base: add VLAN TPID for VLAN filters net/ice/base: add support for configuring the device in Double VLAN Mode net/ice: add new supported device IDs drivers/net/ice/base/README | 2 +- drivers/net/ice/base/ice_adminq_cmd.h | 38 +++- drivers/net/ice/base/ice_common.c | 2 - drivers/net/ice/base/ice_devids.h | 10 + drivers/net/ice/base/ice_flex_pipe.c | 9 +- drivers/net/ice/base/ice_switch.c | 64 ++ drivers/net/ice/base/ice_switch.h | 14 ++ drivers/net/ice/base/ice_type.h | 2 +- drivers/net/ice/base/ice_vlan_mode.c | 284 -- drivers/net/ice/base/ice_vlan_mode.h | 24 +-- drivers/net/ice/ice_ethdev.c | 5 + 11 files changed, 406 insertions(+), 48 deletions(-) -- 2.26.2
[dpdk-dev] [PATCH 1/4] net/ice/base: fix wrong macro value
Fix the wrong value of ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST
Fixes: 9ea028123a0b ("net/ice/base: align add VSI and update VSI AQ command
buffer")
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 09d0f176c9..74ac76a132 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -500,7 +500,7 @@ struct ice_aqc_vsi_props {
#define ICE_AQ_VSI_OUTER_TAG_VLAN_8100 0x2
#define ICE_AQ_VSI_OUTER_TAG_VLAN_9100 0x3
#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_INSERTBIT(4)
-#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST BIT(4)
+#define ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST BIT(6)
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_S5
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_M(0x3 <<
ICE_AQ_VSI_OUTER_VLAN_TX_MODE_S)
#define ICE_AQ_VSI_OUTER_VLAN_TX_MODE_ACCEPTUNTAGGED 0x1
--
2.26.2
[dpdk-dev] [PATCH 2/4] net/ice/base: add VLAN TPID for VLAN filters
Currently VLAN filters via RID4 are only based on VLAN ID. However, with
incoming support for Double VLAN Mode (DVM), the driver needs to be able
to support filtering on VLAN ID + VLAN TPID (i.e. 0x8100, 0x88a8, etc.).
Add support for this by adding two fields to the ice_fltr_info
structure. First, add the tpid_valid field so the code can determine
whether or not to overwrite the default 0x8100 value for programming
packets or use the tpid field.
Signed-off-by: Brett Creeley
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_switch.c | 6 ++
drivers/net/ice/base/ice_switch.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index 692a147e66..277623d2bb 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -14,6 +14,7 @@
#define ICE_PPP_IPV6_PROTO_ID 0x0057
#define ICE_IPV6_ETHER_ID 0x86DD
#define ICE_TCP_PROTO_ID 0x06
+#define ICE_ETH_P_8021Q0x8100
/* Dummy ethernet header needed in the ice_aqc_sw_rules_elem
* struct to configure any switch filter rules.
@@ -3441,6 +3442,7 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
struct ice_aqc_sw_rules_elem *s_rule, enum ice_adminq_opc opc)
{
u16 vlan_id = ICE_MAX_VLAN_ID + 1;
+ u16 vlan_tpid = ICE_ETH_P_8021Q;
void *daddr = NULL;
u16 eth_hdr_sz;
u8 *eth_hdr;
@@ -3513,6 +3515,8 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
break;
case ICE_SW_LKUP_VLAN:
vlan_id = f_info->l_data.vlan.vlan_id;
+ if (f_info->l_data.vlan.tpid_valid)
+ vlan_tpid = f_info->l_data.vlan.tpid;
if (f_info->fltr_act == ICE_FWD_TO_VSI ||
f_info->fltr_act == ICE_FWD_TO_VSI_LIST) {
act |= ICE_SINGLE_ACT_PRUNE;
@@ -3556,6 +3560,8 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_info
*f_info,
if (!(vlan_id > ICE_MAX_VLAN_ID)) {
off = (_FORCE_ __be16 *)(eth_hdr + ICE_ETH_VLAN_TCI_OFFSET);
*off = CPU_TO_BE16(vlan_id);
+ off = (_FORCE_ __be16 *)(eth_hdr + ICE_ETH_ETHTYPE_OFFSET);
+ *off = CPU_TO_BE16(vlan_tpid);
}
/* Create the switch rule with the final dummy Ethernet header */
diff --git a/drivers/net/ice/base/ice_switch.h
b/drivers/net/ice/base/ice_switch.h
index c11c064725..a0a7a2e533 100644
--- a/drivers/net/ice/base/ice_switch.h
+++ b/drivers/net/ice/base/ice_switch.h
@@ -160,6 +160,8 @@ struct ice_fltr_info {
} mac_vlan;
struct {
u16 vlan_id;
+ u16 tpid;
+ u8 tpid_valid;
} vlan;
/* Set lkup_type as ICE_SW_LKUP_ETHERTYPE
* if just using ethertype as filter. Set lkup_type as
--
2.26.2
[dpdk-dev] [PATCH 3/4] net/ice/base: add support for configuring the device in Double VLAN Mode
In order to support configuring the device in Double VLAN Mode (DVM),
the DDP and FW have to support DVM. If both support DVM, the PF
that downloads the package needs to update the default recipes and set
the VLAN mode. This is done in ice_set_dvm().
In order to support updating the default recipes in DVM add support
for updating an existing switch recipe's lkup_idx and mask.
This is done by first calling the get recipe AQ (0x0292) with the
desired recipe ID. Then, if that is successful update one of the lookup
indices (lkup_idx) and its associated mask if the mask is valid
otherwise the already existing mask will be used.
Signed-off-by: Brett Creeley
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_adminq_cmd.h | 36
drivers/net/ice/base/ice_common.c | 2 -
drivers/net/ice/base/ice_flex_pipe.c | 9 +-
drivers/net/ice/base/ice_switch.c | 58 ++
drivers/net/ice/base/ice_switch.h | 12 ++
drivers/net/ice/base/ice_type.h | 2 +-
drivers/net/ice/base/ice_vlan_mode.c | 284 --
drivers/net/ice/base/ice_vlan_mode.h | 24 +--
8 files changed, 381 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
b/drivers/net/ice/base/ice_adminq_cmd.h
index 74ac76a132..8f72f0db33 100644
--- a/drivers/net/ice/base/ice_adminq_cmd.h
+++ b/drivers/net/ice/base/ice_adminq_cmd.h
@@ -358,6 +358,40 @@ struct ice_aqc_get_allocd_res_desc {
__le32 addr_low;
};
+/* Request buffer for Set VLAN Mode AQ command (indirect 0x020C) */
+struct ice_aqc_set_vlan_mode {
+ u8 reserved;
+ u8 l2tag_prio_tagging;
+#define ICE_AQ_VLAN_PRIO_TAG_S 0
+#define ICE_AQ_VLAN_PRIO_TAG_M (0x7 << ICE_AQ_VLAN_PRIO_TAG_S)
+#define ICE_AQ_VLAN_PRIO_TAG_NOT_SUPPORTED 0x0
+#define ICE_AQ_VLAN_PRIO_TAG_STAG 0x1
+#define ICE_AQ_VLAN_PRIO_TAG_OUTER_CTAG0x2
+#define ICE_AQ_VLAN_PRIO_TAG_OUTER_VLAN0x3
+#define ICE_AQ_VLAN_PRIO_TAG_INNER_CTAG0x4
+#define ICE_AQ_VLAN_PRIO_TAG_MAX 0x4
+#define ICE_AQ_VLAN_PRIO_TAG_ERROR 0x7
+ u8 l2tag_reserved[64];
+ u8 rdma_packet;
+#define ICE_AQ_VLAN_RDMA_TAG_S 0
+#define ICE_AQ_VLAN_RDMA_TAG_M (0x3F << ICE_AQ_VLAN_RDMA_TAG_S)
+#define ICE_AQ_SVM_VLAN_RDMA_PKT_FLAG_SETTING 0x10
+#define ICE_AQ_DVM_VLAN_RDMA_PKT_FLAG_SETTING 0x1A
+ u8 rdma_reserved[2];
+ u8 mng_vlan_prot_id;
+#define ICE_AQ_VLAN_MNG_PROTOCOL_ID_OUTER 0x10
+#define ICE_AQ_VLAN_MNG_PROTOCOL_ID_INNER 0x11
+ u8 prot_id_reserved[30];
+};
+
+/* Response buffer for Get VLAN Mode AQ command (indirect 0x020D) */
+struct ice_aqc_get_vlan_mode {
+ u8 vlan_mode;
+#define ICE_AQ_VLAN_MODE_DVM_ENA BIT(0)
+ u8 l2tag_prio_tagging;
+ u8 reserved[98];
+};
+
/* Add VSI (indirect 0x0210)
* Update VSI (indirect 0x0211)
* Get VSI (indirect 0x0212)
@@ -2911,6 +2945,8 @@ enum ice_adminq_opc {
ice_aqc_opc_alloc_res = 0x0208,
ice_aqc_opc_free_res= 0x0209,
ice_aqc_opc_get_allocd_res_desc = 0x020A,
+ ice_aqc_opc_set_vlan_mode_parameters= 0x020C,
+ ice_aqc_opc_get_vlan_mode_parameters= 0x020D,
/* VSI commands */
ice_aqc_opc_add_vsi = 0x0210,
diff --git a/drivers/net/ice/base/ice_common.c
b/drivers/net/ice/base/ice_common.c
index d3178240b2..bef7c83512 100644
--- a/drivers/net/ice/base/ice_common.c
+++ b/drivers/net/ice/base/ice_common.c
@@ -836,8 +836,6 @@ enum ice_status ice_init_hw(struct ice_hw *hw)
goto err_unroll_fltr_mgmt_struct;
ice_init_lock(&hw->tnl_lock);
- ice_init_vlan_mode_ops(hw);
-
return ICE_SUCCESS;
err_unroll_fltr_mgmt_struct:
diff --git a/drivers/net/ice/base/ice_flex_pipe.c
b/drivers/net/ice/base/ice_flex_pipe.c
index 31047d1eda..cf470bc4f0 100644
--- a/drivers/net/ice/base/ice_flex_pipe.c
+++ b/drivers/net/ice/base/ice_flex_pipe.c
@@ -1152,6 +1152,7 @@ static enum ice_status
ice_download_pkg(struct ice_hw *hw, struct ice_seg *ice_seg)
{
struct ice_buf_table *ice_buf_tbl;
+ enum ice_status status;
ice_debug(hw, ICE_DBG_TRACE, "%s\n", __func__);
ice_debug(hw, ICE_DBG_PKG, "Segment format version: %d.%d.%d.%d\n",
@@ -1169,8 +1170,12 @@ ice_download_pkg(struct ice_hw *hw, struct ice_seg
*ice_seg)
ice_debug(hw, ICE_DBG_PKG, "Seg buf count: %d\n",
LE32_TO_CPU(ice_buf_tbl->buf_count));
- return ice_dwnld_cfg_bufs(hw, ice_buf_tbl->buf_array,
- LE32_TO_CPU(ice_buf_tbl->buf_count));
+ status = ice_dwnld_cfg_bufs(hw, ice_buf_tbl->buf_array,
+ LE32_TO_CPU(ice_buf_tbl->buf_count));
+
+ ice_cache_vlan_mode(hw);
+
+ return status;
}
/**
diff --git a/drivers/net/ice/base/ice_switch
[dpdk-dev] [PATCH 4/4] net/ice: add new supported device IDs
Add device ID support for family E823C, also update the base code
BSD version.
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/README | 2 +-
drivers/net/ice/base/ice_devids.h | 10 ++
drivers/net/ice/ice_ethdev.c | 5 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ice/base/README b/drivers/net/ice/base/README
index bc42736bdd..7d32e58a52 100644
--- a/drivers/net/ice/base/README
+++ b/drivers/net/ice/base/README
@@ -6,7 +6,7 @@ Intel® ICE driver
==
This directory contains source code of FreeBSD ice driver of version
-2021.01.07 released by the team which develops
+2021.01.20 released by the team which develops
basic drivers for any ice NIC. The directory of base/ contains the
original source package.
This driver is valid for the product(s) listed below
diff --git a/drivers/net/ice/base/ice_devids.h
b/drivers/net/ice/base/ice_devids.h
index 93110055e2..b4cdddc8e7 100644
--- a/drivers/net/ice/base/ice_devids.h
+++ b/drivers/net/ice/base/ice_devids.h
@@ -28,6 +28,16 @@
#define ICE_DEV_ID_E810_XXV_QSFP 0x159A
/* Intel(R) Ethernet Controller E810-XXV for SFP */
#define ICE_DEV_ID_E810_XXV_SFP0x159B
+/* Intel(R) Ethernet Connection E823-C for backplane */
+#define ICE_DEV_ID_E823C_BACKPLANE 0x188A
+/* Intel(R) Ethernet Connection E823-C for QSFP */
+#define ICE_DEV_ID_E823C_QSFP 0x188B
+/* Intel(R) Ethernet Connection E823-C for SFP */
+#define ICE_DEV_ID_E823C_SFP 0x188C
+/* Intel(R) Ethernet Connection E823-C/X557-AT 10GBASE-T */
+#define ICE_DEV_ID_E823C_10G_BASE_T0x188D
+/* Intel(R) Ethernet Connection E823-C 1GbE */
+#define ICE_DEV_ID_E823C_SGMII 0x188E
/* Intel(R) Ethernet Connection E822-C for backplane */
#define ICE_DEV_ID_E822C_BACKPLANE 0x1890
/* Intel(R) Ethernet Connection E822-C for QSFP */
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index ec29f0fe40..f33c3cbffe 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -152,6 +152,11 @@ static const struct rte_pci_id pci_id_ice_map[] = {
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_BACKPLANE) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_QSFP) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810_XXV_SFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_BACKPLANE) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_QSFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_SFP) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_10G_BASE_T) },
+ { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E823C_SGMII) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_BACKPLANE) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_QSFP) },
{ RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E822C_SFP) },
--
2.26.2
Re: [dpdk-dev] [PATCH 0/4] ice base code update batch 3
Acked-by: Qiming Yang > -Original Message- > From: Zhang, Qi Z > Sent: Thursday, January 21, 2021 09:44 > To: Yang, Qiming > Cc: dev@dpdk.org; yigit.fer...@intel.com; Zhang, Qi Z > Subject: [PATCH 0/4] ice base code update batch 3 > > Qi Zhang (4): > net/ice/base: fix wrong macro value > net/ice/base: add VLAN TPID for VLAN filters > net/ice/base: add support for configuring the device in Double VLAN > Mode > net/ice: add new supported device IDs > > drivers/net/ice/base/README | 2 +- > drivers/net/ice/base/ice_adminq_cmd.h | 38 +++- > drivers/net/ice/base/ice_common.c | 2 - > drivers/net/ice/base/ice_devids.h | 10 + > drivers/net/ice/base/ice_flex_pipe.c | 9 +- > drivers/net/ice/base/ice_switch.c | 64 ++ > drivers/net/ice/base/ice_switch.h | 14 ++ > drivers/net/ice/base/ice_type.h | 2 +- > drivers/net/ice/base/ice_vlan_mode.c | 284 -- > drivers/net/ice/base/ice_vlan_mode.h | 24 +-- > drivers/net/ice/ice_ethdev.c | 5 + > 11 files changed, 406 insertions(+), 48 deletions(-) > > -- > 2.26.2
Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor
> dedicated queues(txq, rxq). A SF netdev supports E-Switch representation > offload similar to existing PF and VF representors. A SF shares PCI level > resources with other SFs and/or with its parent PCI function. > > From SmartNIC perspective, when PCI device is shared for multi-host, > representors for host controller and host PF is required. > > This patch set introduces new representor types in addtion to existing VF > representor. Syntax: > > [[c#]pf#]vf#: VF port representor/s from controller/pf > [[c#]pf#]sf#: SF port representor/s from controller/pf > #: VF representor - for backwards compatibility > > "#" is number instance, list or range, valid examples: > 1, [1,3,5], [0-3], [0,2-4,6] > > For backward compatibility, this patch also introduces new netdev capability > to indicate the capability of supportting SF representor. > > Version history: > RFC: > initial version [2] > V2: > - separate patch for represnetor infrastructure, controller, pf and > sf. > - replace representor ID macro with functions: > rte_eth_representor_id_encode() > rte_eth_representor_id_parse() > - new patch to allow devargs with same PCI BDF but different > representors. > - other minor code updates according to comments, thanks Andrew! > - update document > V3: > - improve probing of allowed devargs with same name. > - parse single word of kvargs as key. > - update kvargs test cases. > V4: > - split first representor refactor patch into > 1: add representor type > 2: refector representor list parsing > - push the patch supporting multi-devargs for same device. > V5: > - add comments for parsing functions > - update switch_representation.rst - Thanks Ajit Hi, The series can't recognize i40e device, so testpmd start failed. ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 4-8 -n 6 -a 17:00.0 -- -i --txq=2 --rxq=2 <...> EAL: Probe PCI driver: net_i40e (8086:158b) device: :17:00.0 (socket 0) EAL: No legacy callbacks, legacy socket not created testpmd: No probed ethernet devices Interactive-mode selected Fail: input txq (2) can't be greater than max_tx_queues (0) of port 0 EAL: Error - exiting with code: 1 Cause: txq 2 invalid - must be >= 0 && <= 0 thanks
Re: [dpdk-dev] [PATCH 0/4] ice base code update batch 3
> -Original Message- > From: Yang, Qiming > Sent: Thursday, January 21, 2021 11:04 AM > To: Zhang, Qi Z > Cc: dev@dpdk.org; yigit.fer...@intel.com > Subject: RE: [PATCH 0/4] ice base code update batch 3 > > Acked-by: Qiming Yang > > > -Original Message- > > From: Zhang, Qi Z > > Sent: Thursday, January 21, 2021 09:44 > > To: Yang, Qiming > > Cc: dev@dpdk.org; yigit.fer...@intel.com; Zhang, Qi Z > > > > Subject: [PATCH 0/4] ice base code update batch 3 > > > > Qi Zhang (4): > > net/ice/base: fix wrong macro value > > net/ice/base: add VLAN TPID for VLAN filters > > net/ice/base: add support for configuring the device in Double VLAN > > Mode > > net/ice: add new supported device IDs > > > > drivers/net/ice/base/README | 2 +- > > drivers/net/ice/base/ice_adminq_cmd.h | 38 +++- > > drivers/net/ice/base/ice_common.c | 2 - > > drivers/net/ice/base/ice_devids.h | 10 + > > drivers/net/ice/base/ice_flex_pipe.c | 9 +- > > drivers/net/ice/base/ice_switch.c | 64 ++ > > drivers/net/ice/base/ice_switch.h | 14 ++ > > drivers/net/ice/base/ice_type.h | 2 +- > > drivers/net/ice/base/ice_vlan_mode.c | 284 > > -- drivers/net/ice/base/ice_vlan_mode.h | 24 > +-- > > drivers/net/ice/ice_ethdev.c | 5 + > > 11 files changed, 406 insertions(+), 48 deletions(-) > > > > -- > > 2.26.2 > Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH v5 0/3] support both PIO and MMIO BAR for virtio PMD
On 2021/1/13 1:37, Maxime Coquelin wrote: On 10/22/20 5:51 PM, 谢华伟(此时此刻） wrote: From: "huawei.xhw" Legacy virtio-pci only supports PIO BAR resource. As we need to create lots of virtio devices and PIO resource on x86 is very limited, we expose MMIO BAR. Kernel supports both PIO and MMIO BAR for legacy virtio-pci device. We handles different type of BAR in the similar way. In previous implementation, with igb_uio we get PIO address from igb_uio sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports. For PIO/MMIO RW, there is different path for different drivers and arch. For VFIO, PIO/MMIO RW is through syscall, which has big performance issue. Regarding the performance issue, do you have some numbers to share? AFAICS, it can only have an impact on performance when interrupt mode is used or queue notification is enabled. Does your HW Virtio implementation requires notification? Yes, hardware needs notification to tell which queue has more buffer. vhost backend also needs notification when it is not running in polling mode. It is easy for software backend to sync with frontend whether it needs notification through memory but a big burden for hardware. Anyway, using vfio ioctl isn't needed at all. virtio PMD is only the consumer of pci_vfio_ioport_read. we could consider if we still need pci_vfio_ioport_read related API in future. /huawei Is performance the only issue to have your HW working with Virtio PMD, or is this series also fixing some functionnal issues? Best regards, Maxime
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On 1/20/2021 11:21 PM, Ferruh Yigit wrote: On 1/20/2021 10:05 AM, Ali Alnubani wrote: For info, I don't reproduce the compilation issue on my machine. My build system has been upgraded from fc31 to fc32 so I guess this has something to do with it. I can reproduce with (Fedora MinGW 9.2.1-6.fc32), but not with (Fedora MinGW 10.2.1-2.fc33). First of all, for the patch @Tal provided its link, the windows build and the mingw build errors are different. And the windows build error should be already fixed by a patch that squashed in next-net (https://patches.dpdk.org/patch/86804/). And for the mingw, I have same result with Ali, I can reproduce with (Fedora MinGW 9.2.1-6.fc32). But different from the CI, I am getting the error [1] for all following files: rte_random.c i40e_rxtx_vec_sse.c i40e_rxtx_vec_avx512.c i40e_rxtx_vec_avx2.c rte_ethdev.c [1] Error: invalid register for .seh_savexmm There is a stackoverflow entry for it: https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin If I use '-fno-asynchronous-unwind-tables' as suggested there, the build works fine. So the problem may not be just 'i40e_rxtx_vec_avx512.c'. If I change the machine type from 'native' to 'corei7' [2], the build error reduced to only 'i40e_rxtx_vec_avx512.c', so the problem seems happens when avx512 is supported by CPU, in this case compiler seems has a defect. And since for 'i40e_rxtx_vec_avx512.c' the '-march=skylake-avx512' explicitly set can cause the problem seen in all machines. [2] diff --git a/config/x86/cross-mingw b/config/x86/cross-mingw index 4c15a7fa2e..7cee238add 100644 --- a/config/x86/cross-mingw +++ b/config/x86/cross-mingw @@ -9,5 +9,5 @@ pkgconfig = 'x86_64-w64-mingw32-pkg-config' [host_machine] system = 'windows' cpu_family = 'x86_64' -cpu = 'native' +cpu = 'corei7' endian = 'little' @Ranjit, @Pallavi, Are you building using mingw, and if so are you observing same problem? We usually build using Clang. However, we verify with mingw as well before submitting the patch. As mentioned in the patch [1] comments, we replaced #include x86intrin.h with in the file i40e_rxtx_vec_avx2.c And this helped fixing an error related to conflicting types for '__m_prefethw' with Clang on Windows. I was able to build this patch using Clang as well as mingw. [1] http://patches.dpdk.org/patch/84770/ I verified patch fix submitted by Rong, Leyi, it builds successfully with Clang. However, I am getting same error "Error: invalid register for .seh_savexmm" using mingw for 'i40e_rxtx_vec_avx512.c' file. Thanks, Pallavi
Re: [dpdk-dev] [PATCH 1/1] doc: simplify OS support in features matrix
On Wed, Jan 20, 2021 at 3:04 PM Thomas Monjalon wrote: > > The networking drivers features matrix had rows to show > OS and kernel modules support: > - BSD nic_uio > - Linux UIO > - Linux VFIO > - Other kdrv > - Windows > > The kernel modules details are removed to keep only OS support: > - FreeBSD > - Linux > - Windows > > Signed-off-by: Thomas Monjalon Acked-by: Ajit Khaparde > --- > doc/guides/nics/features.rst | 36 ++ > doc/guides/nics/features/ark.ini | 2 +- > doc/guides/nics/features/atlantic.ini | 2 +- > doc/guides/nics/features/avp.ini | 2 +- > doc/guides/nics/features/axgbe.ini | 2 +- > doc/guides/nics/features/bnx2x.ini | 2 +- > doc/guides/nics/features/bnxt.ini | 5 ++- > doc/guides/nics/features/cxgbe.ini | 5 ++- > doc/guides/nics/features/cxgbevf.ini | 3 +- > doc/guides/nics/features/default.ini | 6 ++-- > doc/guides/nics/features/dpaa2.ini | 2 +- > doc/guides/nics/features/e1000.ini | 5 ++- > doc/guides/nics/features/ena.ini | 3 +- > doc/guides/nics/features/enetc.ini | 2 +- > doc/guides/nics/features/enic.ini | 5 ++- > doc/guides/nics/features/fm10k.ini | 5 ++- > doc/guides/nics/features/fm10k_vf.ini | 5 ++- > doc/guides/nics/features/hinic.ini | 3 +- > doc/guides/nics/features/hns3.ini | 3 +- > doc/guides/nics/features/hns3_vf.ini | 3 +- > doc/guides/nics/features/i40e.ini | 5 ++- > doc/guides/nics/features/i40e_vf.ini | 5 ++- > doc/guides/nics/features/iavf.ini | 5 ++- > doc/guides/nics/features/ice.ini | 5 ++- > doc/guides/nics/features/ice_dcf.ini | 3 +- > doc/guides/nics/features/igb.ini | 5 ++- > doc/guides/nics/features/igb_vf.ini| 5 ++- > doc/guides/nics/features/igc.ini | 3 +- > doc/guides/nics/features/ionic.ini | 3 +- > doc/guides/nics/features/ipn3ke.ini| 5 ++- > doc/guides/nics/features/ixgbe.ini | 5 ++- > doc/guides/nics/features/ixgbe_vf.ini | 5 ++- > doc/guides/nics/features/liquidio.ini | 3 +- > doc/guides/nics/features/mlx4.ini | 2 +- > doc/guides/nics/features/mlx5.ini | 2 +- > doc/guides/nics/features/netvsc.ini| 2 +- > doc/guides/nics/features/nfb.ini | 2 +- > doc/guides/nics/features/nfp.ini | 3 +- > doc/guides/nics/features/octeontx.ini | 2 +- > doc/guides/nics/features/octeontx2.ini | 2 +- > doc/guides/nics/features/octeontx2_vec.ini | 2 +- > doc/guides/nics/features/octeontx2_vf.ini | 2 +- > doc/guides/nics/features/pfe.ini | 2 +- > doc/guides/nics/features/qede.ini | 3 +- > doc/guides/nics/features/qede_vf.ini | 3 +- > doc/guides/nics/features/sfc_efx.ini | 5 ++- > doc/guides/nics/features/szedata2.ini | 2 +- > doc/guides/nics/features/tap.ini | 2 +- > doc/guides/nics/features/thunderx.ini | 2 +- > doc/guides/nics/features/txgbe.ini | 3 +- > doc/guides/nics/features/virtio.ini| 5 ++- > doc/guides/nics/features/vmxnet3.ini | 3 +- > doc/guides/vdpadevs/features/default.ini | 7 ++--- > doc/guides/vdpadevs/features/mlx5.ini | 2 +- > doc/guides/vdpadevs/features_overview.rst | 11 +++ > 55 files changed, 86 insertions(+), 141 deletions(-) > > diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst > index cf82e9d57f..59beb47316 100644 > --- a/doc/guides/nics/features.rst > +++ b/doc/guides/nics/features.rst > @@ -785,38 +785,20 @@ Multiprocess aware > Driver can be used for primary-secondary process model. > > > -.. _nic_features_bsd_nic_uio: > +.. _nic_features_freebsd: > > -BSD nic_uio > > +FreeBSD > +--- > > -BSD ``nic_uio`` module supported. > +Supports running on FreeBSD. > > > -.. _nic_features_linux_uio: > +.. _nic_features_linux: > > -Linux UIO > -- > +Linux > +- > > -Works with ``igb_uio`` kernel module. > - > -* **[provides] RTE_PMD_REGISTER_KMOD_DEP**: ``igb_uio``. > - > -.. _nic_features_linux_vfio: > - > -Linux VFIO > --- > - > -Works with ``vfio-pci`` kernel module. > - > -* **[provides] RTE_PMD_REGISTER_KMOD_DEP**: ``vfio-pci``. > - > -.. _nic_features_other_kdrv: > - > -Other kdrv > --- > - > -Kernel module other than above ones supported. > +Supports running on Linux. > > > .. _nic_features_windows: > @@ -824,7 +806,7 @@ Kernel module other than above ones supported. > Windows > --- > > -Support Windows. > +Supports running on Windows. > > > .. _nic_features_armv7: > diff --git a/doc/guides/nics/features/ark.ini > b/doc/guides/nics/features/ark.ini > index ec8a2b9983..5519984e39 100644 > --- a/doc/guides/nics/features/ark.ini > +++ b/doc/guides/nics/features/ark.ini > @@ -10,6 +10,6 @@ Jumbo f
[dpdk-dev] [PATCH v11 0/4] raw/ifpga: add extra OPAE APIs
Cyborg is part of OpenStack, it needs some OPAE APIs to manage devices with Intel FPGA. The first three patches implement extra APIs to meet Cyborg requirement. The last patch add an example to show how to use these APIs. Main changes from v10: - remove call of rte_eal_init() and rte_eal_cleanup() - rename opae_init_eal() to opae_init() - rename opae_cleanup_eal() to opae_cleanup() Wei Huang (4): raw/ifpga: add fpga rsu function raw/ifpga: add fpga property get function raw/ifpga: add OPAE API for OpenStack Cyborg examples/ifpga: add example for opae ifpga API MAINTAINERS|1 + doc/guides/sample_app_ug/ifpga.rst | 435 + doc/guides/sample_app_ug/index.rst |1 + drivers/raw/ifpga/base/ifpga_api.c | 34 + drivers/raw/ifpga/base/ifpga_defines.h |1 + drivers/raw/ifpga/base/ifpga_feature_dev.c | 21 + drivers/raw/ifpga/base/ifpga_feature_dev.h |1 + drivers/raw/ifpga/base/ifpga_fme.c | 36 +- drivers/raw/ifpga/base/ifpga_fme_rsu.c | 435 + drivers/raw/ifpga/base/ifpga_hw.h |1 + drivers/raw/ifpga/base/ifpga_sec_mgr.c | 639 +++ drivers/raw/ifpga/base/ifpga_sec_mgr.h | 89 + drivers/raw/ifpga/base/meson.build |2 + drivers/raw/ifpga/base/opae_hw_api.c | 77 + drivers/raw/ifpga/base/opae_hw_api.h | 13 + drivers/raw/ifpga/base/opae_ifpga_hw_api.h |1 + drivers/raw/ifpga/base/opae_intel_max10.c | 48 + drivers/raw/ifpga/base/opae_intel_max10.h | 44 + drivers/raw/ifpga/ifpga_opae_api.c | 1793 drivers/raw/ifpga/ifpga_opae_api.h | 248 +++ drivers/raw/ifpga/ifpga_rawdev.c | 352 drivers/raw/ifpga/ifpga_rawdev.h | 50 +- drivers/raw/ifpga/meson.build |4 +- examples/ifpga/Makefile| 45 + examples/ifpga/commands.c | 1321 ++ examples/ifpga/commands.h | 16 + examples/ifpga/main.c | 41 + examples/ifpga/meson.build | 19 + 28 files changed, 5764 insertions(+), 4 deletions(-) create mode 100644 doc/guides/sample_app_ug/ifpga.rst create mode 100644 drivers/raw/ifpga/base/ifpga_fme_rsu.c create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.c create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.h create mode 100644 drivers/raw/ifpga/ifpga_opae_api.c create mode 100644 drivers/raw/ifpga/ifpga_opae_api.h create mode 100644 examples/ifpga/Makefile create mode 100644 examples/ifpga/commands.c create mode 100644 examples/ifpga/commands.h create mode 100644 examples/ifpga/main.c create mode 100644 examples/ifpga/meson.build -- 2.29.2
[dpdk-dev] [PATCH v11 1/4] raw/ifpga: add fpga rsu function
RSU (Remote System Update) depends on secure manager which may be
different on various implementations, so a new secure manager device
is implemented for adapting such difference.
There are three major functions added:
1. ifpga_rawdev_update_flash() updates flash with specific image file.
2. ifpga_rawdev_stop_flash_update() aborts flash update process.
3. ifpga_rawdev_reload() reloads FPGA from updated flash.
Signed-off-by: Wei Huang
Acked-by: Tianfei Zhang
Acked-by: Rosen Xu
---
v2: fix coding style issue in ifpga_fme_rsu.c and ifpga_sec_mgr.c
---
v3: fix compilation issues in ifpga_fme_rsu.c
---
v4: fix compilation issues in opae_intel_max10.c
---
drivers/raw/ifpga/base/ifpga_api.c| 26 +
drivers/raw/ifpga/base/ifpga_fme.c| 8 +
drivers/raw/ifpga/base/ifpga_fme_rsu.c| 435 +++
drivers/raw/ifpga/base/ifpga_hw.h | 1 +
drivers/raw/ifpga/base/ifpga_sec_mgr.c| 639 ++
drivers/raw/ifpga/base/ifpga_sec_mgr.h| 89 +++
drivers/raw/ifpga/base/meson.build| 2 +
drivers/raw/ifpga/base/opae_hw_api.c | 59 ++
drivers/raw/ifpga/base/opae_hw_api.h | 11 +
drivers/raw/ifpga/base/opae_intel_max10.c | 48 ++
drivers/raw/ifpga/base/opae_intel_max10.h | 44 ++
drivers/raw/ifpga/ifpga_rawdev.c | 55 ++
drivers/raw/ifpga/ifpga_rawdev.h | 7 +-
13 files changed, 1423 insertions(+), 1 deletion(-)
create mode 100644 drivers/raw/ifpga/base/ifpga_fme_rsu.c
create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.c
create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.h
diff --git a/drivers/raw/ifpga/base/ifpga_api.c
b/drivers/raw/ifpga/base/ifpga_api.c
index 1ff57fa18..1aedf150b 100644
--- a/drivers/raw/ifpga/base/ifpga_api.c
+++ b/drivers/raw/ifpga/base/ifpga_api.c
@@ -5,6 +5,7 @@
#include "ifpga_api.h"
#include "ifpga_enumerate.h"
#include "ifpga_feature_dev.h"
+#include "ifpga_sec_mgr.h"
#include "opae_hw_api.h"
@@ -228,11 +229,36 @@ static int ifpga_mgr_get_board_info(struct opae_manager
*mgr,
return 0;
}
+static int ifpga_mgr_update_flash(struct opae_manager *mgr, const char *image,
+ u64 *status)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fpga_update_flash(fme, image, status);
+}
+
+static int ifpga_mgr_stop_flash_update(struct opae_manager *mgr, int force)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fpga_stop_flash_update(fme, force);
+}
+
+static int ifpga_mgr_reload(struct opae_manager *mgr, int type, int page)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fpga_reload(fme, type, page);
+}
+
struct opae_manager_ops ifpga_mgr_ops = {
.flash = ifpga_mgr_flash,
.get_eth_group_region_info = ifpga_mgr_get_eth_group_region_info,
.get_sensor_value = ifpga_mgr_get_sensor_value,
.get_board_info = ifpga_mgr_get_board_info,
+ .update_flash = ifpga_mgr_update_flash,
+ .stop_flash_update = ifpga_mgr_stop_flash_update,
+ .reload = ifpga_mgr_reload,
};
static int ifpga_mgr_read_mac_rom(struct opae_manager *mgr, int offset,
diff --git a/drivers/raw/ifpga/base/ifpga_fme.c
b/drivers/raw/ifpga/base/ifpga_fme.c
index f29ff3159..34fd9a818 100644
--- a/drivers/raw/ifpga/base/ifpga_fme.c
+++ b/drivers/raw/ifpga/base/ifpga_fme.c
@@ -7,6 +7,7 @@
#include "opae_intel_max10.h"
#include "opae_i2c.h"
#include "opae_at24_eeprom.h"
+#include "ifpga_sec_mgr.h"
#define PWR_THRESHOLD_MAX 0x7F
@@ -1152,6 +1153,12 @@ static int fme_nios_spi_init(struct ifpga_feature
*feature)
if (spi_self_checking(max10))
goto spi_fail;
+ ret = init_sec_mgr(fme);
+ if (ret) {
+ dev_err(fme, "security manager init fail\n");
+ goto spi_fail;
+ }
+
return ret;
spi_fail:
@@ -1165,6 +1172,7 @@ static void fme_nios_spi_uinit(struct ifpga_feature
*feature)
{
struct ifpga_fme_hw *fme = (struct ifpga_fme_hw *)feature->parent;
+ release_sec_mgr(fme);
if (fme->max10_dev)
intel_max10_device_remove(fme->max10_dev);
}
diff --git a/drivers/raw/ifpga/base/ifpga_fme_rsu.c
b/drivers/raw/ifpga/base/ifpga_fme_rsu.c
new file mode 100644
index 0..fad1ac416
--- /dev/null
+++ b/drivers/raw/ifpga/base/ifpga_fme_rsu.c
@@ -0,0 +1,435 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include "ifpga_sec_mgr.h"
+
+static struct ifpga_sec_mgr *sec_mgr;
+
+static void set_rsu_control(struct ifpga_sec_mgr *smgr, uint32_t ctrl)
+{
+ if (smgr && smgr->rsu_control)
+ *smgr->rsu_control = ctrl;
+}
+
+static uint32_t get_rsu_control(struct ifpga_sec_mgr *smgr)
+{
+ if (smgr && smgr->rsu_control)
+ return *smgr->rsu_control;
+ return 0;
+}
+
+static void set_rsu_status(struct ifpga_sec_mgr *smgr, uint32_t status,
+ uint32_t progress)
+{
+ if (smgr && smgr->rsu_s
[dpdk-dev] [PATCH v11 2/4] raw/ifpga: add fpga property get function
There are three types of property can be got from FPGA, they are
implemented in below functions:
1. ifpga_rawdev_get_fme_property() get property of FME (FPGA
Management Engine).
2. ifpga_rawdev_get_port_property() get property of FPGA port.
3. ifpga_rawdev_get_bmc_property() get property of BMC (Board
Management Controller).
Signed-off-by: Wei Huang
Acked-by: Tianfei Zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga/base/ifpga_api.c | 8 ++
drivers/raw/ifpga/base/ifpga_defines.h | 1 +
drivers/raw/ifpga/base/ifpga_feature_dev.c | 21 +++
drivers/raw/ifpga/base/ifpga_feature_dev.h | 1 +
drivers/raw/ifpga/base/ifpga_fme.c | 28 +++-
drivers/raw/ifpga/base/opae_hw_api.c | 18 +++
drivers/raw/ifpga/base/opae_hw_api.h | 2 +
drivers/raw/ifpga/base/opae_ifpga_hw_api.h | 1 +
drivers/raw/ifpga/ifpga_rawdev.c | 157 +
drivers/raw/ifpga/ifpga_rawdev.h | 28
10 files changed, 263 insertions(+), 2 deletions(-)
diff --git a/drivers/raw/ifpga/base/ifpga_api.c
b/drivers/raw/ifpga/base/ifpga_api.c
index 1aedf150b..4610ef101 100644
--- a/drivers/raw/ifpga/base/ifpga_api.c
+++ b/drivers/raw/ifpga/base/ifpga_api.c
@@ -229,6 +229,13 @@ static int ifpga_mgr_get_board_info(struct opae_manager
*mgr,
return 0;
}
+static int ifpga_mgr_get_uuid(struct opae_manager *mgr, struct uuid *uuid)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fpga_get_pr_uuid(fme, uuid);
+}
+
static int ifpga_mgr_update_flash(struct opae_manager *mgr, const char *image,
u64 *status)
{
@@ -256,6 +263,7 @@ struct opae_manager_ops ifpga_mgr_ops = {
.get_eth_group_region_info = ifpga_mgr_get_eth_group_region_info,
.get_sensor_value = ifpga_mgr_get_sensor_value,
.get_board_info = ifpga_mgr_get_board_info,
+ .get_uuid = ifpga_mgr_get_uuid,
.update_flash = ifpga_mgr_update_flash,
.stop_flash_update = ifpga_mgr_stop_flash_update,
.reload = ifpga_mgr_reload,
diff --git a/drivers/raw/ifpga/base/ifpga_defines.h
b/drivers/raw/ifpga/base/ifpga_defines.h
index 9f0147d1e..dca1518a8 100644
--- a/drivers/raw/ifpga/base/ifpga_defines.h
+++ b/drivers/raw/ifpga/base/ifpga_defines.h
@@ -1727,6 +1727,7 @@ struct opae_board_info {
u8 seu;
u8 ptp;
+ u32 boot_page;
u32 max10_version;
u32 nios_fw_version;
u32 nums_of_retimer;
diff --git a/drivers/raw/ifpga/base/ifpga_feature_dev.c
b/drivers/raw/ifpga/base/ifpga_feature_dev.c
index 0f852a75a..08135137a 100644
--- a/drivers/raw/ifpga/base/ifpga_feature_dev.c
+++ b/drivers/raw/ifpga/base/ifpga_feature_dev.c
@@ -87,6 +87,27 @@ int fpga_get_afu_uuid(struct ifpga_port_hw *port, struct
uuid *uuid)
return 0;
}
+int fpga_get_pr_uuid(struct ifpga_fme_hw *fme, struct uuid *uuid)
+{
+ struct feature_fme_pr *fme_pr;
+ u64 guidl, guidh;
+
+ if (!fme || !uuid)
+ return -EINVAL;
+
+ fme_pr = get_fme_feature_ioaddr_by_index(fme, FME_FEATURE_ID_PR_MGMT);
+
+ spinlock_lock(&fme->lock);
+ guidl = readq(&fme_pr->fme_pr_intfc_id_l);
+ guidh = readq(&fme_pr->fme_pr_intfc_id_h);
+ spinlock_unlock(&fme->lock);
+
+ opae_memcpy(uuid->b, &guidl, sizeof(u64));
+ opae_memcpy(uuid->b + 8, &guidh, sizeof(u64));
+
+ return 0;
+}
+
/* Mask / Unmask Port Errors by the Error Mask register. */
void port_err_mask(struct ifpga_port_hw *port, bool mask)
{
diff --git a/drivers/raw/ifpga/base/ifpga_feature_dev.h
b/drivers/raw/ifpga/base/ifpga_feature_dev.h
index 2b1309b44..b355d22b0 100644
--- a/drivers/raw/ifpga/base/ifpga_feature_dev.h
+++ b/drivers/raw/ifpga/base/ifpga_feature_dev.h
@@ -103,6 +103,7 @@ is_port_feature_present(struct ifpga_port_hw *port, int
index)
}
int fpga_get_afu_uuid(struct ifpga_port_hw *port, struct uuid *uuid);
+int fpga_get_pr_uuid(struct ifpga_fme_hw *fme, struct uuid *uuid);
int __fpga_port_disable(struct ifpga_port_hw *port);
void __fpga_port_enable(struct ifpga_port_hw *port);
diff --git a/drivers/raw/ifpga/base/ifpga_fme.c
b/drivers/raw/ifpga/base/ifpga_fme.c
index 34fd9a818..43c7b9c3d 100644
--- a/drivers/raw/ifpga/base/ifpga_fme.c
+++ b/drivers/raw/ifpga/base/ifpga_fme.c
@@ -101,6 +101,24 @@ static int fme_hdr_get_ports_num(struct ifpga_fme_hw *fme,
u64 *ports_num)
return 0;
}
+static int fme_hdr_get_port_type(struct ifpga_fme_hw *fme, u64 *port_type)
+{
+ struct feature_fme_header *fme_hdr
+ = get_fme_feature_ioaddr_by_index(fme, FME_FEATURE_ID_HEADER);
+ struct feature_fme_port pt;
+ u32 port = (u32)((*port_type >> 32) & 0x);
+
+ pt.csr = readq(&fme_hdr->port[port]);
+ if (!pt.port_implemented)
+ return -ENODEV;
+ if (pt.afu_access_control)
+ *port_type |= 0x1;
+ else
+ *port_type &= ~0x1;
+
+ return 0;
+}
+
static int fme_hdr_get_cache_size(struct ifpga_fme_hw *fme,
[dpdk-dev] [PATCH v11 3/4] raw/ifpga: add OPAE API for OpenStack Cyborg
Cyborg is an OpenStack project that aims to provide a general purpose
management framework for acceleration resources (i.e. various types
of accelerators such as GPU, FPGA, NP, ODP, DPDK/SPDK and so on).
It needs some OPAE type APIs to manage PACs (Programmable Acceleration
Card) with Intel FPGA. Below major functions are added to meets
Cyborg requirements.
1. opae_init() set up OPAE environment.
2. opae_cleanup() clean up OPAE environment.
3. opae_enumerate() searches PAC with specific FPGA.
4. opae_get_property() gets properties of FPGA.
5. opae_partial_reconfigure() perform partial configuration on FPGA.
6. opae_get_image_info() gets information of image file.
7. opae_update_flash() updates FPGA flash with specific image file.
8. opae_cancel_flash_update() cancel process of FPGA flash update.
9. opae_probe_device() manually probe specific FPGA with ifpga driver.
10. opae_remove_device() manually remove specific FPGA from ifpga driver.
11. opae_bind_driver() binds specific FPGA with specified kernel driver.
12. opae_unbind_driver() unbinds specific FPGA from kernel driver.
13. opae_reboot_device() reboots specific FPGA (do reconfiguration).
Signed-off-by: Wei Huang
Acked-by: Tianfei Zhang
Acked-by: Rosen Xu
---
v2: fix typo in commit log and ifpga_opae_api.h
---
v3: fix coding style issue in ifpga_opae_api.c
---
v4: enclose macro PCI_EXT_CAP_ID in parentheses
---
v5: fix icc compiler build error
---
v6: fix compilation issues in ifpga_opae_api.c
---
v7: remove call of rte_eal_init() and rte_eal_cleanup()
---
drivers/raw/ifpga/ifpga_opae_api.c | 1793
drivers/raw/ifpga/ifpga_opae_api.h | 248
drivers/raw/ifpga/ifpga_rawdev.c | 152 ++-
drivers/raw/ifpga/ifpga_rawdev.h | 15 +
drivers/raw/ifpga/meson.build |4 +-
5 files changed, 2205 insertions(+), 7 deletions(-)
create mode 100644 drivers/raw/ifpga/ifpga_opae_api.c
create mode 100644 drivers/raw/ifpga/ifpga_opae_api.h
diff --git a/drivers/raw/ifpga/ifpga_opae_api.c
b/drivers/raw/ifpga/ifpga_opae_api.c
new file mode 100644
index 0..f4475abe3
--- /dev/null
+++ b/drivers/raw/ifpga/ifpga_opae_api.c
@@ -0,0 +1,1793 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "base/opae_hw_api.h"
+#include "base/ifpga_sec_mgr.h"
+#include "ifpga_rawdev.h"
+#include "ifpga_opae_api.h"
+
+
+int opae_log_level;
+FILE *opae_log_file;
+
+static opae_api_version api_ver = {21, 2, 0};
+static int eal_inited;
+static uint32_t dev_aer[2] = {0};
+
+static const char * const log_level_name[] = {"CRITICAL", "ERROR",
+ "WARNING", "INFORMATION", "DEBUG"};
+static const char * const proc_type_name[] = {"NON-DPDK", "PRIMARY",
+ "SECONDARY"};
+static const char * const platform_name[] = {"Vista Creek", "Rush Creek",
+ "Darby Creek", "Lightning Creek"};
+static const char * const release_name[] = {"Pre-Alpha", "Alpha", "Beta",
"PV"};
+static const char * const interface_type[] = {"8x10G", "4x25G", "2x1x25G",
+ "4x25G+2x25G", "2x2x25G", "2x1x25Gx2FVL", "1x2x25G"};
+static const char * const kdrv[] = {OPAE_KDRV_UNKNOWN, OPAE_KDRV_IGB_UIO,
+ OPAE_KDRV_VFIO_PCI, OPAE_KDRV_UIO_PCI};
+
+RTE_INIT(init_api_env)
+{
+ eal_inited = 0;
+ opae_log_level = OPAE_LOG_ERR;
+ opae_log_file = NULL;
+ ifpga_rawdev_logtype = 0;
+
+ opae_log_info("API environment is initialized\n");
+}
+
+RTE_FINI(clean_api_env)
+{
+ if (opae_log_file) {
+ fclose(opae_log_file);
+ opae_log_file = NULL;
+ }
+ opae_log_info("API environment is cleaned\n");
+}
+
+void opae_get_api_version(opae_api_version *version)
+{
+ if (version)
+ memcpy(version, &api_ver, sizeof(opae_api_version));
+ opae_log_info("API version is %u.%u.%u\n",
+ api_ver.major, api_ver.minor, api_ver.micro);
+}
+
+int opae_set_log_level(int level)
+{
+ if ((level >= OPAE_LOG_API) && (level <= OPAE_LOG_DEBUG))
+ opae_log_level = level;
+ opae_log_api("Current log level is %s\n",
+ log_level_name[opae_log_level]);
+ return opae_log_level;
+}
+
+int opae_set_log_file(char *path, int clean)
+{
+ FILE *f = NULL;
+ time_t start;
+ struct tm *lt = NULL;
+
+ if (path) {
+ if (clean)
+ f = fopen(path, "w+");
+ else
+ f = fopen(path, "a+");
+
+ if (f) {
+ if (opae_log_file) {
+ fclose(opae_log_file);
+ opae_log_file = NULL;
+ }
+ time(&start);
+ lt = localtime(&start);
+ if (lt)
+ fprintf(f, "%d-%02d-%02d "
+
[dpdk-dev] [PATCH v11 4/4] examples/ifpga: add example for opae ifpga API
An example application shows how to use opae ifpga APIs.
You can test each API by running corresponding command.
A guide is also added to show how to run the example.
Signed-off-by: Wei Huang
Acked-by: Tianfei Zhang
Acked-by: Rosen Xu
---
v2: fix coding style issue in commands.c
---
v3: add guide for running example
---
v4: fix compilation issue of ifpga.rst
---
v5: add ifpga.rst into sample_app_ug/index.rst
---
MAINTAINERS|1 +
doc/guides/sample_app_ug/ifpga.rst | 435 +
doc/guides/sample_app_ug/index.rst |1 +
examples/ifpga/Makefile| 45 +
examples/ifpga/commands.c | 1321
examples/ifpga/commands.h | 16 +
examples/ifpga/main.c | 41 +
examples/ifpga/meson.build | 19 +
8 files changed, 1879 insertions(+)
create mode 100644 doc/guides/sample_app_ug/ifpga.rst
create mode 100644 examples/ifpga/Makefile
create mode 100644 examples/ifpga/commands.c
create mode 100644 examples/ifpga/commands.h
create mode 100644 examples/ifpga/main.c
create mode 100644 examples/ifpga/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index eafe9f8c4..04a8fdebb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1237,6 +1237,7 @@ M: Tianfei zhang
T: git://dpdk.org/next/dpdk-next-net-intel
F: drivers/raw/ifpga/
F: doc/guides/rawdevs/ifpga.rst
+F: doc/guides/sample_app_ug/ifpga.rst
IOAT Rawdev
M: Bruce Richardson
diff --git a/doc/guides/sample_app_ug/ifpga.rst
b/doc/guides/sample_app_ug/ifpga.rst
new file mode 100644
index 0..c7974c67d
--- /dev/null
+++ b/doc/guides/sample_app_ug/ifpga.rst
@@ -0,0 +1,435 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2020-2021 Intel Corporation.
+
+Intel FPGA Sample Application
+=
+
+The Intel FPGA sample application is an example of how to use OPAE API to
manage
+Intel FPGA.
+
+Overview
+
+
+The Intel FPGA sample application is a simple application that demonstrates
+the use of the OPAE API provided by ifpga driver in the DPDK.
+This application is a readline-like interface that can be used to manage
+Intel FPGA, in a Linux* application environment.
+
+Compiling the Application
+-
+
+To compile the sample application see :doc:`compiling`
+
+The application is located in the ``ifpga`` sub-directory.
+
+Running the Application
+---
+
+To run the application in linux environment, issue the following command:
+
+.. code-block:: console
+
+$ .//examples/dpdk-ifpga --proc-type=auto
+
+Refer to the *DPDK Getting Started Guide* for general information on running
+applications and the Environment Abstraction Layer (EAL) options.
+
+Explanation
+---
+
+The following sections provide some explanation of the code.
+
+EAL Initialization and cmdline Start
+
+
+The first task is the initialization of the Environment Abstraction Layer
(EAL).
+This is achieved as follows:
+
+.. code-block:: c
+
+int main(int argc, char **argv)
+{
+ eal_init_ret = rte_eal_init(argc, argv);
+ret = opae_init(eal_init_ret);
+if (ret < 0)
+rte_panic("Cannot init EAL\n");
+
+Then, a new command line object is created and started to interact with the
user
+through the console:
+
+.. code-block:: c
+
+cl = cmdline_stdin_new(main_ctx, "opae> ");
+if (cl == NULL)
+rte_panic("Cannot create cmdline instance\n");
+cmdline_interact(cl);
+opae_cleanup();
+rte_eal_cleanup();
+cmdline_stdin_exit(cl);
+
+The cmd line_interact() function returns when the user types **Ctrl-d** or
+**quit**. In this case, EAL is cleaned up and the application exits.
+
+Commands Description
+
+
+The following sections provide some explanation of the commands.
+
+help command
+
+
+The application has on-line help for the commands that are available at
runtime.
+
+.. code-block:: console
+
+ opae> help
+get_api_versionget OPAE API version
+get_proc_type get DPDK process type
+get_image_info get information of image file
+get_statusget current status & progress of
FPGA
+get_property <0|1|2|4|8> get property of FPGA
+get_phy_info get information of PHY
+get_parentget parent PCI device of FPGA
+get_child get child PCI device of FPGA
+get_pf1 get physical function 1 device of
FPGA
+set_log_level <0-4>set logging level
+set_log_file set logging file
+set_status <0-4> <0-100> set current status & progress of
FPGA
+enumerateenumerate specified FPGA
+bind bind FPGA with kernel driver
+unbindunbind FPGA
Re: [dpdk-dev] [PATCH v5 2/3] PCI: support MMIO in rte_pci_ioport_map/unap/read/write
On 2021/1/12 16:23, Maxime Coquelin wrote:
Title should be something like:
"bus/pci: support MMIO in PCI ioport accessors
On 10/22/20 5:51 PM, 谢华伟(此时此刻） wrote:
From: "huawei.xhw"
If IO BAR, we get PIO address.
If MMIO BAR, we get mapped virtual address.
We distinguish PIO and MMIO by their address like how kernel does.
ioread/write8/16/32 is provided to access PIO/MMIO.
BTW, for virtio on arch other than x86, BAR flag indicates PIO but is mapped.
No acronym in the commit message.
BTW? fixed. PIO(programmed IO) and MMIO(memory mapped IO) explained.
Also, I am not sure to understand this comment.
Does it means in the case of ARM for example, the IORESOURCE_IO flag is
set but the base address is above PIO_MAX?
ARM doesn't have PIO but only MMIO. The device sets IORESOURCE_IO flag
anyway.
Should i remove this message as it causes confuse?
Signed-off-by: huawei.xhw
As in previous patch, we need your full name for the sign-off.
fixed.
---
drivers/bus/pci/linux/pci.c | 4 --
drivers/bus/pci/linux/pci_uio.c | 123 ++--
2 files changed, 82 insertions(+), 45 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 0f38abf..0dc99e9 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -715,8 +715,6 @@ int rte_pci_write_config(const struct rte_pci_device
*device,
break;
#endif
case RTE_PCI_KDRV_IGB_UIO:
- pci_uio_ioport_read(p, data, len, offset);
- break;
I think this part should be in patch 1.
Patch 1 handles IO port map.
Patch 2 unifies IO/MMIO.
Patch 3 handles vfio.
I feel current split is more clear.
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_read(p, data, len, offset);
break;
@@ -736,8 +734,6 @@ int rte_pci_write_config(const struct rte_pci_device
*device,
break;
#endif
case RTE_PCI_KDRV_IGB_UIO:
- pci_uio_ioport_write(p, data, len, offset);
- break;
Same here.
case RTE_PCI_KDRV_UIO_GENERIC:
pci_uio_ioport_write(p, data, len, offset);
break;
diff --git a/drivers/bus/pci/linux/pci_uio.c b/drivers/bus/pci/linux/pci_uio.c
index 01f2a40..c19382f 100644
--- a/drivers/bus/pci/linux/pci_uio.c
+++ b/drivers/bus/pci/linux/pci_uio.c
@@ -379,14 +379,9 @@
char buf[BUFSIZ];
uint64_t phys_addr, end_addr, flags;
unsigned long base;
+ bool iobar;
int i;
- if (rte_eal_iopl_init() != 0) {
- RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for PCI
device %s\n",
- __func__, dev->name);
- return -1;
- }
-
/* open and read addresses of the corresponding resource in sysfs */
snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
rte_pci_get_sysfs_path(), dev->addr.domain, dev->addr.bus,
@@ -408,15 +403,30 @@
&end_addr, &flags) < 0)
goto error;
- if (!(flags & IORESOURCE_IO)) {
- RTE_LOG(ERR, EAL, "%s(): bar resource other than IO is not
supported\n", __func__);
+ if (flags & IORESOURCE_IO) {
+ iobar = 1;
+ base = (unsigned long)phys_addr;
+ RTE_LOG(INFO, EAL, "%s(): PIO BAR %08lx detected\n", __func__,
base);
+ } else if (flags & IORESOURCE_MEM) {
+ iobar = 0;
+ base = (unsigned long)dev->mem_resource[bar].addr;
+ RTE_LOG(INFO, EAL, "%s(): MMIO BAR %08lx detected\n", __func__,
base);
+ } else {
+ RTE_LOG(ERR, EAL, "%s(): unknown BAR type\n", __func__);
+ goto error;
+ }
+
+
+ if (iobar && rte_eal_iopl_init() != 0) {
+ RTE_LOG(ERR, EAL, "%s(): insufficient ioport permissions for PCI
device %s\n",
+ __func__, dev->name);
goto error;
}
- base = (unsigned long)phys_addr;
- RTE_LOG(INFO, EAL, "%s(): PIO BAR %08lx detected\n", __func__, base);
- if (base > UINT16_MAX)
+ if (iobar && (base > UINT16_MAX)) {
+ RTE_LOG(ERR, EAL, "%s(): %08lx too large PIO resource\n",
__func__, base);
goto error;
+ }
It looks like above check could be moved directly to (flags &
IORESOURCE_IO) case, so iobar boolean is not needed.
yes, code is more clear with your suggestion.
Re: [dpdk-dev] [PATCH v2 19/44] net/virtio: move features definition to generic header
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, January 20, 2021 5:25 AM
> To: dev@dpdk.org; Xia, Chenbo ; olivier.m...@6wind.com;
> amore...@redhat.com; david.march...@redhat.com
> Cc: Maxime Coquelin
> Subject: [PATCH v2 19/44] net/virtio: move features definition to generic
> header
>
> This patch moves all the Virtio definition to the generic
> header. It also renames some helpers to no more reference
> PCI.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/virtio/meson.build| 3 +-
> drivers/net/virtio/virtio.c | 22
> drivers/net/virtio/virtio.h | 94 +++
> drivers/net/virtio/virtio_ethdev.c| 114 +-
> drivers/net/virtio/virtio_pci.c | 21 +---
> drivers/net/virtio/virtio_pci.h | 90 --
> drivers/net/virtio/virtio_ring.h | 2 +-
> drivers/net/virtio/virtio_rxtx.c | 38 +++---
> drivers/net/virtio/virtio_rxtx_packed.h | 6 +-
> .../net/virtio/virtio_user/vhost_kernel_tap.c | 2 +-
> drivers/net/virtio/virtio_user_ethdev.c | 6 +-
> drivers/net/virtio/virtqueue.c| 4 +-
> drivers/net/virtio/virtqueue.h| 8 +-
> 13 files changed, 211 insertions(+), 199 deletions(-)
> create mode 100644 drivers/net/virtio/virtio.c
>
> diff --git a/drivers/net/virtio/meson.build b/drivers/net/virtio/meson.build
> index f2873d6180..d595cfdcab 100644
> --- a/drivers/net/virtio/meson.build
> +++ b/drivers/net/virtio/meson.build
>
> - if (vtpci_with_feature(hw, VIRTIO_F_RING_PACKED)) {
> + if (virtio_with_feature(hw, VIRTIO_F_RING_PACKED)) {
As discussed before, let's also replace here with virtio_with_packed_queue 😊
Thanks
Chenbo
> /*
>* Bit[0:15]: vq queue index
>* Bit[16:30]: avail index
> @@ -618,21 +618,6 @@ vtpci_write_dev_config(struct virtio_hw *hw, size_t
> offset,
> VIRTIO_OPS(hw)->write_dev_cfg(hw, offset, src, length);
> }
>
> -uint64_t
> -vtpci_negotiate_features(struct virtio_hw *hw, uint64_t host_features)
> -{
> - uint64_t features;
> -
> - /*
> - * Limit negotiated features to what the driver, virtqueue, and
> - * host all support.
> - */
> - features = host_features & hw->guest_features;
> - VIRTIO_OPS(hw)->set_features(hw, features);
> -
> - return features;
> -}
> -
> void
> vtpci_reset(struct virtio_hw *hw)
> {
> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
> index f7f51fba79..3d93e74f36 100644
> --- a/drivers/net/virtio/virtio_pci.h
> +++ b/drivers/net/virtio/virtio_pci.h
> @@ -79,83 +79,6 @@ struct virtnet_ctl;
> */
> #define VIRTIO_MAX_INDIRECT ((int) (PAGE_SIZE / 16))
>
> -/* The feature bitmap for virtio net */
> -#define VIRTIO_NET_F_CSUM0 /* Host handles pkts w/ partial csum */
> -#define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ partial
> csum */
> -#define VIRTIO_NET_F_MTU 3 /* Initial MTU advice. */
> -#define VIRTIO_NET_F_MAC 5 /* Host has given MAC address. */
> -#define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 in. */
> -#define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 in. */
> -#define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] w/
> ECN in.
> */
> -#define VIRTIO_NET_F_GUEST_UFO 10 /* Guest can handle UFO in. */
> -#define VIRTIO_NET_F_HOST_TSO4 11 /* Host can handle TSOv4 in. */
> -#define VIRTIO_NET_F_HOST_TSO6 12 /* Host can handle TSOv6 in. */
> -#define VIRTIO_NET_F_HOST_ECN13 /* Host can handle TSO[6] w/
> ECN in.
> */
> -#define VIRTIO_NET_F_HOST_UFO14 /* Host can handle UFO in. */
> -#define VIRTIO_NET_F_MRG_RXBUF 15 /* Host can merge receive
> buffers.
> */
> -#define VIRTIO_NET_F_STATUS 16 /* virtio_net_config.status available */
> -#define VIRTIO_NET_F_CTRL_VQ 17 /* Control channel available */
> -#define VIRTIO_NET_F_CTRL_RX 18 /* Control channel RX mode support */
> -#define VIRTIO_NET_F_CTRL_VLAN 19 /* Control channel VLAN
> filtering */
> -#define VIRTIO_NET_F_CTRL_RX_EXTRA 20/* Extra RX mode control
> support */
> -#define VIRTIO_NET_F_GUEST_ANNOUNCE 21 /* Guest can announce device on
> the
> - * network */
> -#define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> - * Steering */
> -#define VIRTIO_NET_F_CTRL_MAC_ADDR 23/* Set MAC address */
> -
> -/* Do we get callbacks when the ring is completely used, even if we've
> - * suppressed them? */
> -#define VIRTIO_F_NOTIFY_ON_EMPTY 24
> -
> -/* Can the device handle any descriptor layout? */
> -#define VIRTIO_F_ANY_LAYOUT 27
> -
> -/* We support indirect buffer descriptors *
Re: [dpdk-dev] [PATCH v11 0/4] raw/ifpga: add extra OPAE APIs
> -Original Message- > From: Huang, Wei > Sent: Thursday, January 21, 2021 2:04 PM > To: dev@dpdk.org; Xu, Rosen ; Zhang, Qi Z > > Cc: sta...@dpdk.org; Zhang, Tianfei ; Huang, Wei > > Subject: [PATCH v11 0/4] raw/ifpga: add extra OPAE APIs > > Cyborg is part of OpenStack, it needs some OPAE APIs to manage devices with > Intel FPGA. The first three patches implement extra APIs to meet Cyborg > requirement. The last patch add an example to show how to use these APIs. > > Main changes from v10: > - remove call of rte_eal_init() and rte_eal_cleanup() > - rename opae_init_eal() to opae_init() > - rename opae_cleanup_eal() to opae_cleanup() > > Wei Huang (4): > raw/ifpga: add fpga rsu function > raw/ifpga: add fpga property get function > raw/ifpga: add OPAE API for OpenStack Cyborg > examples/ifpga: add example for opae ifpga API > > MAINTAINERS|1 + > doc/guides/sample_app_ug/ifpga.rst | 435 + > doc/guides/sample_app_ug/index.rst |1 + > drivers/raw/ifpga/base/ifpga_api.c | 34 + > drivers/raw/ifpga/base/ifpga_defines.h |1 + > drivers/raw/ifpga/base/ifpga_feature_dev.c | 21 + > drivers/raw/ifpga/base/ifpga_feature_dev.h |1 + > drivers/raw/ifpga/base/ifpga_fme.c | 36 +- > drivers/raw/ifpga/base/ifpga_fme_rsu.c | 435 + > drivers/raw/ifpga/base/ifpga_hw.h |1 + > drivers/raw/ifpga/base/ifpga_sec_mgr.c | 639 +++ > drivers/raw/ifpga/base/ifpga_sec_mgr.h | 89 + > drivers/raw/ifpga/base/meson.build |2 + > drivers/raw/ifpga/base/opae_hw_api.c | 77 + > drivers/raw/ifpga/base/opae_hw_api.h | 13 + > drivers/raw/ifpga/base/opae_ifpga_hw_api.h |1 + > drivers/raw/ifpga/base/opae_intel_max10.c | 48 + > drivers/raw/ifpga/base/opae_intel_max10.h | 44 + > drivers/raw/ifpga/ifpga_opae_api.c | 1793 > drivers/raw/ifpga/ifpga_opae_api.h | 248 +++ > drivers/raw/ifpga/ifpga_rawdev.c | 352 > drivers/raw/ifpga/ifpga_rawdev.h | 50 +- > drivers/raw/ifpga/meson.build |4 +- > examples/ifpga/Makefile| 45 + > examples/ifpga/commands.c | 1321 ++ > examples/ifpga/commands.h | 16 + > examples/ifpga/main.c | 41 + > examples/ifpga/meson.build | 19 + > 28 files changed, 5764 insertions(+), 4 deletions(-) create mode 100644 > doc/guides/sample_app_ug/ifpga.rst > create mode 100644 drivers/raw/ifpga/base/ifpga_fme_rsu.c > create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.c > create mode 100644 drivers/raw/ifpga/base/ifpga_sec_mgr.h > create mode 100644 drivers/raw/ifpga/ifpga_opae_api.c > create mode 100644 drivers/raw/ifpga/ifpga_opae_api.h > create mode 100644 examples/ifpga/Makefile create mode 100644 > examples/ifpga/commands.c create mode 100644 > examples/ifpga/commands.h create mode 100644 examples/ifpga/main.c > create mode 100644 examples/ifpga/meson.build > > -- > 2.29.2 Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH v2 09/44] net/virtio: move MSIX detection to PCI ethdev
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, January 20, 2021 5:25 AM
> To: dev@dpdk.org; Xia, Chenbo ; olivier.m...@6wind.com;
> amore...@redhat.com; david.march...@redhat.com
> Cc: Maxime Coquelin
> Subject: [PATCH v2 09/44] net/virtio: move MSIX detection to PCI ethdev
>
> This patch introduces a new callback to notify the bus
> driver some interrupt related operation was done.
>
> This is used by Virtio PCI driver to check msix status.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/virtio/virtio_ethdev.c | 12 +--
> drivers/net/virtio/virtio_pci.c| 120 ++---
> drivers/net/virtio/virtio_pci.h| 6 +-
> drivers/net/virtio/virtio_pci_ethdev.c | 2 +
> 4 files changed, 82 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index a3e81f336d..13d5a76376 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1287,8 +1287,8 @@ virtio_intr_unmask(struct rte_eth_dev *dev)
> if (rte_intr_ack(dev->intr_handle) < 0)
> return -1;
>
> - if (hw->bus_type == VIRTIO_BUS_PCI_LEGACY || hw->bus_type ==
> VIRTIO_BUS_PCI_MODERN)
> - hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
> + if (VTPCI_OPS(hw)->intr_event)
Emmm.. why is callback called intr_event? The callback detects/checks msix and
lsc.
IMHO, maybe intr_detect? Or another similar verb you like 😊
> + VTPCI_OPS(hw)->intr_event(hw);
>
> return 0;
>
> +msix_detect:
> + hw->use_msix = vtpci_msix_detect(dev);
> +
Just use use the callback introduced? Should also work later when intr_lsc is
added.
Thanks,
Chenbo
> return 0;
> }
>
> -enum virtio_msix_status
> -vtpci_msix_detect(struct rte_pci_device *dev)
> -{
> - uint8_t pos;
> - int ret;
> -
> - ret = rte_pci_read_config(dev, &pos, 1, PCI_CAPABILITY_LIST);
> - if (ret != 1) {
> - PMD_INIT_LOG(DEBUG,
> - "failed to read pci capability list, ret %d", ret);
> - return VIRTIO_MSIX_NONE;
> - }
> -
> - while (pos) {
> - uint8_t cap[2];
> -
> - ret = rte_pci_read_config(dev, cap, sizeof(cap), pos);
> - if (ret != sizeof(cap)) {
> - PMD_INIT_LOG(DEBUG,
> - "failed to read pci cap at pos: %x ret %d",
> - pos, ret);
> - break;
> - }
> -
> - if (cap[0] == PCI_CAP_ID_MSIX) {
> - uint16_t flags;
> -
> - ret = rte_pci_read_config(dev, &flags, sizeof(flags),
> - pos + sizeof(cap));
> - if (ret != sizeof(flags)) {
> - PMD_INIT_LOG(DEBUG,
> - "failed to read pci cap at pos:"
> - " %x ret %d", pos + 2, ret);
> - break;
> - }
> -
> - if (flags & PCI_MSIX_ENABLE)
> - return VIRTIO_MSIX_ENABLED;
> - else
> - return VIRTIO_MSIX_DISABLED;
> - }
> -
> - pos = cap[1];
> - }
> -
> - return VIRTIO_MSIX_NONE;
> -}
> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
> index 59f6688218..6f5c53c4b7 100644
> --- a/drivers/net/virtio/virtio_pci.h
> +++ b/drivers/net/virtio/virtio_pci.h
> @@ -239,6 +239,7 @@ struct virtio_pci_ops {
> int (*setup_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> void (*del_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> void (*notify_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> + void (*intr_event)(struct virtio_hw *hw);
> };
>
> struct virtio_net_config;
> @@ -303,10 +304,13 @@ struct virtio_pci_dev {
> struct virtio_hw_internal {
> const struct virtio_pci_ops *vtpci_ops;
> struct rte_pci_ioport io;
> + struct rte_pci_device *dev;
> };
>
> #define VTPCI_OPS(hw)(virtio_hw_internal[(hw)->port_id].vtpci_ops)
> #define VTPCI_IO(hw) (&virtio_hw_internal[(hw)->port_id].io)
> +#define VTPCI_DEV(hw)(virtio_hw_internal[(hw)->port_id].dev)
> +
>
> extern struct virtio_hw_internal virtio_hw_internal[RTE_MAX_ETHPORTS];
>
> @@ -383,8 +387,6 @@ void vtpci_read_dev_config(struct virtio_hw *, size_t,
> void *, int);
>
> uint8_t vtpci_isr(struct virtio_hw *);
>
> -enum virtio_msix_status vtpci_msix_detect(struct rte_pci_device *dev);
> -
> extern const struct virtio_pci_ops legacy_ops;
> extern const struct virtio_pci_ops modern_ops;
> extern const struct virtio_pci_ops virtio_user_ops;
> diff --git a/drivers/net/virtio/virtio_pci_ethdev.c
> b/drivers/net/virtio/virtio_pci_ethdev.c
> index 6a0ef6edc3..045b13
Re: [dpdk-dev] [PATCH v2 03/44] net/virtio: fix getting old status on reconnect
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, January 20, 2021 5:24 AM
> To: dev@dpdk.org; Xia, Chenbo ; olivier.m...@6wind.com;
> amore...@redhat.com; david.march...@redhat.com
> Cc: Maxime Coquelin ; sta...@dpdk.org
> Subject: [PATCH v2 03/44] net/virtio: fix getting old status on reconnect
>
> This patch fixes getting reset status from the restarted
> vhost-user backend in case of reconnection, instead of the
> status at the time of the disconnection.
>
> This issue was not spotted earlier because Vhost-user
> protocol status feature was disabled in server mode.
>
> Fixes: 47235f16505f ("net/virtio-user: set status on socket reconnect")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/virtio/virtio_user_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_user_ethdev.c
> b/drivers/net/virtio/virtio_user_ethdev.c
> index 241808cd8f..7abba1f1ee 100644
> --- a/drivers/net/virtio/virtio_user_ethdev.c
> +++ b/drivers/net/virtio/virtio_user_ethdev.c
> @@ -77,7 +77,7 @@ virtio_user_server_reconnect(struct virtio_user_dev *dev)
> return -1;
>
> dev->vhostfd = connectfd;
> - old_status = vtpci_get_status(hw);
> + old_status = dev->status;
>
> vtpci_reset(hw);
>
> --
> 2.29.2
Reviewed-by: Chenbo Xia
[dpdk-dev] [PATCH v3] net/bnxt: code refactoring changes
From: Somnath Kotur
Move all the individual driver fields allocation routines to one
routine - bnxt_drv_init(). This houses all such routines where
memory needs to be allocated once during the driver's lifetime
and does not need to be torn down during error recovery.
Rename some function names in accordance with their functionality.
bnxt_init_board() is doing nothing more than mapping the PCI bars,
so rename it as such.
Given that there is a bnxt_shutdown_nic that is called in dev_stop_op,
rename it's counterpart - bnxt_init_chip() that is called in dev_start_op,
to bnxt_start_nic. Also helps avoid confusion with some of the other
bnxt_init_xxx routines.
Rename bnxt_init_fw() to bnxt_get_config() as that is what that routine
is doing mostly functionality wise.
Cc: sta...@dpdk.org
Signed-off-by: Somnath Kotur
Reviewed-by: Ajit Khaparde
---
v1->v2: rebased against latest dpdk-next-net.
v2->v3: rebased against latest dpdk-next-net.
---
drivers/net/bnxt/bnxt_ethdev.c | 150 +++--
1 file changed, 88 insertions(+), 62 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 74b0f3d1d..f439aeee4 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -679,7 +679,7 @@ static int bnxt_update_phy_setting(struct bnxt *bp)
return rc;
}
-static int bnxt_init_chip(struct bnxt *bp)
+static int bnxt_start_nic(struct bnxt *bp)
{
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(bp->eth_dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
@@ -1417,7 +1417,7 @@ static int bnxt_dev_start_op(struct rte_eth_dev *eth_dev)
bnxt_enable_int(bp);
- rc = bnxt_init_chip(bp);
+ rc = bnxt_start_nic(bp);
if (rc)
goto error;
@@ -1464,6 +1464,27 @@ bnxt_uninit_locks(struct bnxt *bp)
}
}
+static void bnxt_drv_uninit(struct bnxt *bp)
+{
+ bnxt_free_switch_domain(bp);
+ bnxt_free_leds_info(bp);
+ bnxt_free_cos_queues(bp);
+ bnxt_free_link_info(bp);
+ bnxt_free_pf_info(bp);
+ bnxt_free_parent_info(bp);
+ bnxt_uninit_locks(bp);
+
+ rte_memzone_free((const struct rte_memzone *)bp->tx_mem_zone);
+ bp->tx_mem_zone = NULL;
+ rte_memzone_free((const struct rte_memzone *)bp->rx_mem_zone);
+ bp->rx_mem_zone = NULL;
+
+ bnxt_hwrm_free_vf_info(bp);
+
+ rte_free(bp->grp_info);
+ bp->grp_info = NULL;
+}
+
static int bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
{
struct bnxt *bp = eth_dev->data->dev_private;
@@ -1488,26 +1509,9 @@ static int bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
if (eth_dev->data->dev_started)
ret = bnxt_dev_stop(eth_dev);
- bnxt_free_switch_domain(bp);
-
bnxt_uninit_resources(bp, false);
- bnxt_free_leds_info(bp);
- bnxt_free_cos_queues(bp);
- bnxt_free_link_info(bp);
- bnxt_free_pf_info(bp);
- bnxt_free_parent_info(bp);
- bnxt_uninit_locks(bp);
-
- rte_memzone_free((const struct rte_memzone *)bp->tx_mem_zone);
- bp->tx_mem_zone = NULL;
- rte_memzone_free((const struct rte_memzone *)bp->rx_mem_zone);
- bp->rx_mem_zone = NULL;
-
- bnxt_hwrm_free_vf_info(bp);
-
- rte_free(bp->grp_info);
- bp->grp_info = NULL;
+ bnxt_drv_uninit(bp);
return ret;
}
@@ -4086,7 +4090,7 @@ bool bnxt_stratus_device(struct bnxt *bp)
}
}
-static int bnxt_init_board(struct rte_eth_dev *eth_dev)
+static int bnxt_map_pci_bars(struct rte_eth_dev *eth_dev)
{
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct bnxt *bp = eth_dev->data->dev_private;
@@ -4723,7 +4727,11 @@ static int bnxt_map_hcomm_fw_status_reg(struct bnxt *bp)
return 0;
}
-static int bnxt_init_fw(struct bnxt *bp)
+/* This function gets the FW version along with the
+ * capabilities(MAX and current) of the function, vnic,
+ * error recovery, phy and other chip related info
+ */
+static int bnxt_get_config(struct bnxt *bp)
{
uint16_t mtu;
int rc = 0;
@@ -4819,7 +4827,7 @@ static int bnxt_init_resources(struct bnxt *bp, bool
reconfig_dev)
{
int rc = 0;
- rc = bnxt_init_fw(bp);
+ rc = bnxt_get_config(bp);
if (rc)
return rc;
@@ -5266,38 +5274,14 @@ static int bnxt_alloc_switch_domain(struct bnxt *bp)
return rc;
}
-static int
-bnxt_dev_init(struct rte_eth_dev *eth_dev, void *params __rte_unused)
+/* Allocate and initialize various fields in bnxt struct that
+ * need to be allocated/destroyed only once in the lifetime of the driver
+ */
+static int bnxt_drv_init(struct rte_eth_dev *eth_dev)
{
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
- static int version_printed;
- struct bnxt *bp;
- int rc;
-
- if (version_printed++ == 0)
- PMD_DRV_LOG(INFO, "%s\n", bnxt_version);
-
-
[dpdk-dev] [PATCH v3] net/bnxt: fix lock handling in stop and close
From: Somnath Kotur
err_recovery_lock needs to be released before returning in
stop and close_op if FW_RESET flag is set.
Fixes: dd3613560573 ("net/bnxt: check chip reset in dev stop and close")
Signed-off-by: Somnath Kotur
Reviewed-by: Ajit Khaparde
---
v1->v2: rebased to latest dpdk-next-net and updated commit log.
v2->v3: rebased to latest dpdk-next-net.
---
drivers/net/bnxt/bnxt_ethdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index f439aeee4..89e42ef14 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1374,6 +1374,7 @@ static int bnxt_dev_stop_op(struct rte_eth_dev *eth_dev)
if (bp->flags & BNXT_FLAG_FW_RESET) {
PMD_DRV_LOG(ERR,
"Adapter recovering from error..Please retry\n");
+ pthread_mutex_unlock(&bp->err_recovery_lock);
return -EAGAIN;
}
pthread_mutex_unlock(&bp->err_recovery_lock);
@@ -1497,6 +1498,7 @@ static int bnxt_dev_close_op(struct rte_eth_dev *eth_dev)
if (bp->flags & BNXT_FLAG_FW_RESET) {
PMD_DRV_LOG(ERR,
"Adapter recovering from error...Please retry\n");
+ pthread_mutex_unlock(&bp->err_recovery_lock);
return -EAGAIN;
}
pthread_mutex_unlock(&bp->err_recovery_lock);
--
2.21.1 (Apple Git-122.3)
Re: [dpdk-dev] [PATCH 0/2] support SSL/TLS way of cipher-auth operations
Hi Akhil, I'm planning to add device feature flag(RTE_CRYPTODEV_FF_SSL_ORDER) along with SSL test cases movement to chain array in v2. Would that be fine? Feature flag is needed to skip SSL test cases if device doesn't support them. Thanks Tejasree > -Original Message- > From: Tejasree Kondoj > Sent: Friday, December 18, 2020 7:40 PM > To: Akhil Goyal ; Radu Nicolau > > Cc: Tejasree Kondoj ; Anoob Joseph > ; Ankur Dwivedi ; > dev@dpdk.org > Subject: [PATCH 0/2] support SSL/TLS way of cipher-auth operations > > This series adds SSL/TLS way of cipher-auth operations support i.e. auth > generation followed by encryption and decryption followed by auth verify in > OCTEON TX, OCTEON TX2 PMDs and sample unit test application. > > Tejasree Kondoj (2): > common/cpt: support SSL/TLS way of cipher-auth operations > test/crypto: support SSL/TLS way of cipher-auth operations > > app/test/test_cryptodev_aes_test_vectors.h| 576 ++ > app/test/test_cryptodev_blockcipher.c | 98 ++- > app/test/test_cryptodev_blockcipher.h | 9 + > doc/guides/rel_notes/release_21_02.rst| 12 + > drivers/common/cpt/cpt_mcode_defines.h| 7 +- > drivers/common/cpt/cpt_ucode.h| 42 +- > drivers/crypto/octeontx/otx_cryptodev_ops.c | 8 +- > drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 8 +- > 8 files changed, 736 insertions(+), 24 deletions(-) > > -- > 2.27.0
[dpdk-dev] [PATCH] net/ice: fix symmetric rule creating
Only allow to create symmetric rule for L3/L4.
Fixes: 38d632cbdc88("net/ice: refactor PF RSS")
Cc: sta...@dpdk.org
Signed-off-by: Xuan Ding
---
drivers/net/ice/ice_hash.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index 2d23c8dd50..aee4761625 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -868,6 +868,13 @@ ice_any_invalid_rss_type(enum rte_eth_hash_function
rss_func,
if (rss_type & (ETH_RSS_L3_SRC_ONLY | ETH_RSS_L3_DST_ONLY |
ETH_RSS_L4_SRC_ONLY | ETH_RSS_L4_DST_ONLY))
return true;
+
+ if (!(rss_type &
+ (ETH_RSS_IPV4 | ETH_RSS_IPV6 |
+ ETH_RSS_NONFRAG_IPV4_UDP | ETH_RSS_NONFRAG_IPV6_UDP |
+ ETH_RSS_NONFRAG_IPV4_TCP | ETH_RSS_NONFRAG_IPV6_TCP |
+ ETH_RSS_NONFRAG_IPV4_SCTP | ETH_RSS_NONFRAG_IPV6_SCTP)))
+ return true;
}
/* check invalid combination */
--
2.17.1
[dpdk-dev] [PATCH v2 2/2] net/mlx4: fix PCI probe error flow
In mlx4 PCI probing, there are some validations for the Ethernet device
configuration.
>From each PCI device the function creates one or two Ethernet devices.
When one of validations fails during the creation of the second device,
the first device is not freed what caused a memory leak.
Free it.
Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx4/mlx4.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 7460afa..495b4fc 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -766,6 +766,7 @@ struct mlx4_conf {
struct ibv_context *attr_ctx = NULL;
struct ibv_device_attr device_attr;
struct ibv_device_attr_ex device_attr_ex;
+ struct rte_eth_dev *prev_dev = NULL;
struct mlx4_conf conf = {
.ports.present = 0,
.mr_ext_memseg_en = 1,
@@ -880,7 +881,7 @@ struct mlx4_conf {
ERROR("can not attach rte ethdev");
rte_errno = ENOMEM;
err = rte_errno;
- goto error;
+ goto err_secondary;
}
priv = eth_dev->data->dev_private;
if (!priv->verbs_alloc_ctx.enabled) {
@@ -889,24 +890,24 @@ struct mlx4_conf {
" from Verbs");
rte_errno = ENOTSUP;
err = rte_errno;
- goto error;
+ goto err_secondary;
}
eth_dev->device = &pci_dev->device;
eth_dev->dev_ops = &mlx4_dev_sec_ops;
err = mlx4_proc_priv_init(eth_dev);
if (err)
- goto error;
+ goto err_secondary;
/* Receive command fd from primary process. */
err = mlx4_mp_req_verbs_cmd_fd(eth_dev);
if (err < 0) {
err = rte_errno;
- goto error;
+ goto err_secondary;
}
/* Remap UAR for Tx queues. */
err = mlx4_tx_uar_init_secondary(eth_dev, err);
if (err) {
err = rte_errno;
- goto error;
+ goto err_secondary;
}
/*
* Ethdev pointer is still required as input since
@@ -918,7 +919,14 @@ struct mlx4_conf {
claim_zero(mlx4_glue->close_device(ctx));
rte_eth_copy_pci_info(eth_dev, pci_dev);
rte_eth_dev_probing_finish(eth_dev);
+ prev_dev = eth_dev;
continue;
+err_secondary:
+ claim_zero(mlx4_glue->close_device(ctx));
+ rte_eth_dev_release_port(eth_dev);
+ if (prev_dev)
+ rte_eth_dev_release_port(prev_dev);
+ break;
}
/* Check port status. */
err = mlx4_glue->query_port(ctx, port, &port_attr);
@@ -1093,6 +1101,7 @@ struct mlx4_conf {
priv, mem_event_cb);
rte_rwlock_write_unlock(&mlx4_shared_data->mem_event_rwlock);
rte_eth_dev_probing_finish(eth_dev);
+ prev_dev = eth_dev;
continue;
port_error:
rte_free(priv);
@@ -1107,14 +1116,10 @@ struct mlx4_conf {
eth_dev->data->mac_addrs = NULL;
rte_eth_dev_release_port(eth_dev);
}
+ if (prev_dev)
+ mlx4_dev_close(prev_dev);
break;
}
- /*
-* XXX if something went wrong in the loop above, there is a resource
-* leak (ctx, pd, priv, dpdk ethdev) but we can do nothing about it as
-* long as the dpdk does not provide a way to deallocate a ethdev and a
-* way to enumerate the registered ethdevs to free the previous ones.
-*/
error:
if (attr_ctx)
claim_zero(mlx4_glue->close_device(attr_ctx));
--
1.8.3.1
[dpdk-dev] [PATCH v2 0/2] net/mlx4: fix PCI probe and remove functions
A couple of bug fixes in probing and removing a PCI device. v1: Initial version. v2: Fix coverity issue. Michael Baum (2): net/mlx4: fix device detach net/mlx4: fix PCI probe error flow drivers/net/mlx4/mlx4.c | 62 +++-- 1 file changed, 50 insertions(+), 12 deletions(-) -- 1.8.3.1
[dpdk-dev] [PATCH v2 1/2] net/mlx4: fix device detach
When mlx4 device is probed, 2 different ethdev ports may be created for
the 2 physical ports of the device.
Wrongly, when the device is removed, the created ports are not released.
Close and release the ethdev ports in remove process.
Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
Cc: sta...@dpdk.org
Reported-by: David Marchand
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx4/mlx4.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index d5d8c96..7460afa 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -375,8 +375,10 @@ struct mlx4_conf {
struct mlx4_priv *priv = dev->data->dev_private;
unsigned int i;
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
+ rte_eth_dev_release_port(dev);
return 0;
+ }
DEBUG("%p: closing device \"%s\"",
(void *)dev,
((priv->ctx != NULL) ? priv->ctx->device->name : ""));
@@ -1123,6 +1125,36 @@ struct mlx4_conf {
return -err;
}
+/**
+ * DPDK callback to remove a PCI device.
+ *
+ * This function removes all Ethernet devices belong to a given PCI device.
+ *
+ * @param[in] pci_dev
+ * Pointer to the PCI device.
+ *
+ * @return
+ * 0 on success, the function cannot fail.
+ */
+static int
+mlx4_pci_remove(struct rte_pci_device *pci_dev)
+{
+ uint16_t port_id;
+ int ret = 0;
+
+ RTE_ETH_FOREACH_DEV_OF(port_id, &pci_dev->device) {
+ /*
+* mlx4_dev_close() is not registered to secondary process,
+* call the close function explicitly for secondary process.
+*/
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+ ret |= mlx4_dev_close(&rte_eth_devices[port_id]);
+ else
+ ret |= rte_eth_dev_close(port_id);
+ }
+ return ret == 0 ? 0 : -EIO;
+}
+
static const struct rte_pci_id mlx4_pci_id_map[] = {
{
RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
@@ -1147,6 +1179,7 @@ struct mlx4_conf {
},
.id_table = mlx4_pci_id_map,
.probe = mlx4_pci_probe,
+ .remove = mlx4_pci_remove,
.drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV,
};
--
1.8.3.1
Re: [dpdk-dev] [PATCH v4 1/3] build: add aarch64 clang to meson cross-compile
> -Original Message- > From: Thomas Monjalon > Sent: Tuesday, January 19, 2021 5:08 PM > To: Juraj Linkeš > Cc: david.march...@redhat.com; acon...@redhat.com; > maicolgabr...@hotmail.com; jerinjac...@gmail.com; ferruh.yi...@intel.com; > ruifeng.w...@arm.com; dev@dpdk.org; bruce.richard...@intel.com > Subject: Re: [dpdk-dev] [PATCH v4 1/3] build: add aarch64 clang to meson > cross- > compile > > 19/01/2021 09:33, Juraj Linkeš: > > Create meson cross-file arm64_armv8_linux_clang_ubuntu1804. > > Why is it specific to Ubuntu 18.04? > I don't want to add specifc cross files per distributions. > > > Use clang/LLVM toolchain with sysroot pointing to gcc cross stdlib. > > > > The sysroot path must be in the cross-file so that Clang can find the > > proper headers: > > * setting CFLAGS, LDFLAGS or -Dc_args, -Dc_link_args doesn't affect > > cross builds (only native builds). Support added in 0.51.0. > > * setting pkg-config vars only affects lib searching, not includes > > * splitting the cross-file into two (one with clang info, one with > > paths) doesn't work. Support added in 0.52.0. > > I don't understand the explanations above. > Please explain what is the bug and how it is fixed. > I guess the missing piece is that the sysroot path is the ubuntu specific part. The explanations illustrate why we can't have a generic cross file with the current meson version - there's no way to pass the paths to cross builds. Now that I think about it, the commit message needs a rewrite - I should've mentioned that clang/llvm doesn't provide it's own standard c lib, so that has to come from elsewhere (such as gcc) and thus we have to provide the paths. > [...] > > +c_args = ['-target', 'aarch64-linux-gnu', '--sysroot', > > +'/usr/aarch64-linux-gnu'] c_link_args = ['-target', > > +'aarch64-linux-gnu', '-fuse-ld=lld', '--gcc-toolchain=/usr'] > > >
[dpdk-dev] [Bug 616] [mlx5] packet does not match a corresponding rte_flow rule due to inner ether_type spec validation
https://bugs.dpdk.org/show_bug.cgi?id=616 Asaf Penso (as...@nvidia.com) changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||as...@nvidia.com Resolution|--- |WONTFIX --- Comment #2 from Asaf Penso (as...@nvidia.com) --- Appears also in the previous 18.11 LTS versions and there were no issues from users. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 617] [mlx5] packet does not match a corresponding rte_flow rule due to vxlan vni spec validation
https://bugs.dpdk.org/show_bug.cgi?id=617 Asaf Penso (as...@nvidia.com) changed: What|Removed |Added CC||as...@nvidia.com Resolution|--- |WONTFIX Status|CONFIRMED |RESOLVED --- Comment #2 from Asaf Penso (as...@nvidia.com) --- Appears also in the previous 18.11 LTS versions and there were no issues from users. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On Wed, Jan 20, 2021 at 7:26 AM Tal Shnaiderman wrote:
> > The patch "add AVX512 vector path" also caused a build failure when cross
> > compiling on Linux using mingw, and it's still reproducing in next-net
> > (517969c95).
> >
> > ```
> > $ meson --werror --buildtype=debugoptimized --cross-file config/x86/cross-
> > mingw -Dexamples=helloworld build && ninja-build -C build -j32
> >
> > [221/232] Generating symbol file lib/librte_mbuf-21.dll.p/librte_mbuf-
> > 21.dll.symbols
> > [222/232] Generating symbol file lib/librte_hash-21.dll.p/librte_hash-
> > 21.dll.symbols
> > [223/232] Linking target lib/librte_net-21.dll [224/232] Compiling C object
> > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > FAILED: drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > ...
> > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj.d -o
> > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -c
> > ../../root/dpdk/drivers/net/i40e/i40e_rxtx_vec_avx512.c
> > {standard input}: Assembler messages:
> > {standard input}:112: Error: invalid register for .seh_savexmm {standard
> > input}:114: Error: invalid register for .seh_savexmm ...
> > ...
> > {standard input}:25351: Error: invalid register for .seh_savexmm {standard
> > input}:25352: Error: invalid register for .seh_savexmm [225/232] Generating
> > symbol file lib/librte_net-21.dll.p/librte_net-21.dll.symbols
> > ninja: build stopped: subcommand failed.
> > ```
> >
> > OS: Fedora 32
> > Meson: 0.55.3
> > MinGW: Fedora MinGW 9.2.1-6.fc32
> >
> > - Ali
>
> Those errors were detected in the CI tests for this patch [1], we should pay
> more attention to those now that 2 PMDs are supported on Windows.
>
> [1]: https://lab.dpdk.org/results/dashboard/patchsets/15164/
I won't grmbl about how CI reports are not being looked at (or maybe I
just did :)).
This simple patch seems to work for me:
diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
index c0acdf4fd4..c9a1a50407 100644
--- a/drivers/net/i40e/meson.build
+++ b/drivers/net/i40e/meson.build
@@ -54,7 +54,7 @@ if arch_subdir == 'x86'
cc.has_argument('-mavx512f') and
cc.has_argument('-mavx512bw'))
- if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
+ if not is_windows and (i40e_avx512_cpu_support == true or
i40e_avx512_cc_support == true)
cflags += ['-DCC_AVX512_SUPPORT']
avx512_args = [cflags, '-mavx512f', '-mavx512bw']
if cc.has_argument('-march=skylake-avx512')
If nobody has a better fix, I'll send it later.
--
David Marchand
Re: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
> -Original Message-
> From: Honnappa Nagarahalli
> Sent: Wednesday, January 20, 2021 3:20 AM
> To: tho...@monjalon.net; Bruce Richardson ;
> Juraj Linkeš
> Cc: Ruifeng Wang ; Phil Yang
> ; vcchu...@amazon.com; Dharmik Thakkar
> ; jerinjac...@gmail.com;
> hemant.agra...@nxp.com; Ajit Khaparde (ajit.khapa...@broadcom.com)
> ; ferruh.yi...@intel.com; abo...@pensando.io;
> dev@dpdk.org; nd ; Honnappa Nagarahalli
> ; nd
> Subject: RE: [dpdk-dev] [PATCH v15 11/12] build: add Arm SoC meson option
>
>
> >
> > 20/01/2021 02:04, Honnappa Nagarahalli:
> > > > On Tue, Jan 19, 2021 at 04:52:19PM +0100, Thomas Monjalon wrote:
> > > > > 19/01/2021 15:56, Juraj Linkeš:
> > > > > > From: Thomas Monjalon
> > > > > > > 15/01/2021 14:26, Juraj Linkeš:
> > > > > > > > --- a/meson_options.txt
> > > > > > > > +++ b/meson_options.txt
> > > > > > > > +option('arm_soc', type: 'string', value: '',
> > > > > > > > + description: 'Specify if you want to build for a
> > > > > > > > +particular
> > > > > > > > +aarch64 Arm SoC when building on an aarch64 machine.')
> > > > > > >
> > > > > > > Why the option is named "arm_soc" and not just "soc"?
> > > > > > > The same option could be used by other archs, isn't it?
> > > > > >
> > > > > > Agree that a more generic name would be better.
> > > > > > I'll change it to "soc" if there are no other suggestions.
> > > > >
> > > > > Another name could be "machine".
> > > > > Should it be the same mechanism as compiling for a specific x86
> > > > > CPU from an x86 machine?
> > > > >
> > > > I'd rather not re-use the term "machine", for a new use, better to
> > > > use a new term IMHO.
> > > +1, agree. 'soc' sounds good to me.
> >
> > Another possible word is "platform",
> > as in http://doc.dpdk.org/guides/platform/index.html
> I am fine with 'platform' too.
>
'platform' is likely the best and actually works nicely with
http://patches.dpdk.org/patch/85956/. Taken together, 'platform' could be
either 'native', 'generic' or an soc, which is, I believe, exactly what we want.
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On 1/20/2021 8:36 AM, David Marchand wrote:
On Wed, Jan 20, 2021 at 7:26 AM Tal Shnaiderman wrote:
The patch "add AVX512 vector path" also caused a build failure when cross
compiling on Linux using mingw, and it's still reproducing in next-net
(517969c95).
```
$ meson --werror --buildtype=debugoptimized --cross-file config/x86/cross-
mingw -Dexamples=helloworld build && ninja-build -C build -j32
[221/232] Generating symbol file lib/librte_mbuf-21.dll.p/librte_mbuf-
21.dll.symbols
[222/232] Generating symbol file lib/librte_hash-21.dll.p/librte_hash-
21.dll.symbols
[223/232] Linking target lib/librte_net-21.dll [224/232] Compiling C object
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
FAILED: drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
...
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj.d -o
drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -c
../../root/dpdk/drivers/net/i40e/i40e_rxtx_vec_avx512.c
{standard input}: Assembler messages:
{standard input}:112: Error: invalid register for .seh_savexmm {standard
input}:114: Error: invalid register for .seh_savexmm ...
...
{standard input}:25351: Error: invalid register for .seh_savexmm {standard
input}:25352: Error: invalid register for .seh_savexmm [225/232] Generating
symbol file lib/librte_net-21.dll.p/librte_net-21.dll.symbols
ninja: build stopped: subcommand failed.
```
OS: Fedora 32
Meson: 0.55.3
MinGW: Fedora MinGW 9.2.1-6.fc32
- Ali
Those errors were detected in the CI tests for this patch [1], we should pay
more attention to those now that 2 PMDs are supported on Windows.
[1]: https://lab.dpdk.org/results/dashboard/patchsets/15164/
I won't grmbl about how CI reports are not being looked at (or maybe I
just did :)).
Noted and agreed, I will be more careful next time for next-net.
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
20/01/2021 09:36, David Marchand:
> On Wed, Jan 20, 2021 at 7:26 AM Tal Shnaiderman wrote:
> > > The patch "add AVX512 vector path" also caused a build failure when cross
> > > compiling on Linux using mingw, and it's still reproducing in next-net
> > > (517969c95).
> > >
> > > ```
> > > $ meson --werror --buildtype=debugoptimized --cross-file config/x86/cross-
> > > mingw -Dexamples=helloworld build && ninja-build -C build -j32
> > >
> > > [221/232] Generating symbol file lib/librte_mbuf-21.dll.p/librte_mbuf-
> > > 21.dll.symbols
> > > [222/232] Generating symbol file lib/librte_hash-21.dll.p/librte_hash-
> > > 21.dll.symbols
> > > [223/232] Linking target lib/librte_net-21.dll [224/232] Compiling C
> > > object
> > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > > FAILED: drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > > ...
> > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj.d -o
> > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -c
> > > ../../root/dpdk/drivers/net/i40e/i40e_rxtx_vec_avx512.c
> > > {standard input}: Assembler messages:
> > > {standard input}:112: Error: invalid register for .seh_savexmm {standard
> > > input}:114: Error: invalid register for .seh_savexmm ...
> > > ...
> > > {standard input}:25351: Error: invalid register for .seh_savexmm {standard
> > > input}:25352: Error: invalid register for .seh_savexmm [225/232]
> > > Generating
> > > symbol file lib/librte_net-21.dll.p/librte_net-21.dll.symbols
> > > ninja: build stopped: subcommand failed.
> > > ```
> > >
> > > OS: Fedora 32
> > > Meson: 0.55.3
> > > MinGW: Fedora MinGW 9.2.1-6.fc32
> > >
> > > - Ali
> >
> > Those errors were detected in the CI tests for this patch [1], we should
> > pay more attention to those now that 2 PMDs are supported on Windows.
> >
> > [1]: https://lab.dpdk.org/results/dashboard/patchsets/15164/
>
> I won't grmbl about how CI reports are not being looked at (or maybe I
> just did :)).
>
> This simple patch seems to work for me:
>
> diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
> index c0acdf4fd4..c9a1a50407 100644
> --- a/drivers/net/i40e/meson.build
> +++ b/drivers/net/i40e/meson.build
> @@ -54,7 +54,7 @@ if arch_subdir == 'x86'
> cc.has_argument('-mavx512f') and
> cc.has_argument('-mavx512bw'))
>
> - if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
> + if not is_windows and (i40e_avx512_cpu_support == true or
> i40e_avx512_cc_support == true)
> cflags += ['-DCC_AVX512_SUPPORT']
> avx512_args = [cflags, '-mavx512f', '-mavx512bw']
> if cc.has_argument('-march=skylake-avx512')
>
>
> If nobody has a better fix, I'll send it later.
For info, I don't reproduce the compilation issue on my machine.
[dpdk-dev] [PATCH] net/ixgbe: disable NFS filtering
From: Dapeng Yu
Disable NFS header filtering whether NFS packets coalescing are
required or not.
This behavior is aligned with ixgbe kernel driver.
Fixes: b826efba6de4 ("net/ixgbe: align register setting when RSC is disabled")
Cc: sta...@dpdk.org
Signed-off-by: Dapeng Yu
---
drivers/net/ixgbe/ixgbe_rxtx.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index cc8f70e6d..3fb55c675 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -4923,15 +4923,11 @@ ixgbe_set_rsc(struct rte_eth_dev *dev)
/* RFCTL configuration */
rfctl = IXGBE_READ_REG(hw, IXGBE_RFCTL);
if ((rsc_capable) && (rx_conf->offloads & DEV_RX_OFFLOAD_TCP_LRO))
- /*
-* Since NFS packets coalescing is not supported - clear
-* RFCTL.NFSW_DIS and RFCTL.NFSR_DIS when RSC is
-* enabled.
-*/
- rfctl &= ~(IXGBE_RFCTL_RSC_DIS | IXGBE_RFCTL_NFSW_DIS |
- IXGBE_RFCTL_NFSR_DIS);
+ rfctl &= ~IXGBE_RFCTL_RSC_DIS;
else
rfctl |= IXGBE_RFCTL_RSC_DIS;
+ /* disable NFS filtering */
+ rfctl |= (IXGBE_RFCTL_NFSW_DIS | IXGBE_RFCTL_NFSR_DIS);
IXGBE_WRITE_REG(hw, IXGBE_RFCTL, rfctl);
/* If LRO hasn't been requested - we are done here. */
--
2.27.0
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
On Wed, Jan 20, 2021 at 10:23 AM Thomas Monjalon wrote:
>
> 20/01/2021 09:36, David Marchand:
> > On Wed, Jan 20, 2021 at 7:26 AM Tal Shnaiderman wrote:
> > > > The patch "add AVX512 vector path" also caused a build failure when
> > > > cross
> > > > compiling on Linux using mingw, and it's still reproducing in next-net
> > > > (517969c95).
> > > >
> > > > ```
> > > > $ meson --werror --buildtype=debugoptimized --cross-file
> > > > config/x86/cross-
> > > > mingw -Dexamples=helloworld build && ninja-build -C build -j32
> > > >
> > > > [221/232] Generating symbol file lib/librte_mbuf-21.dll.p/librte_mbuf-
> > > > 21.dll.symbols
> > > > [222/232] Generating symbol file lib/librte_hash-21.dll.p/librte_hash-
> > > > 21.dll.symbols
> > > > [223/232] Linking target lib/librte_net-21.dll [224/232] Compiling C
> > > > object
> > > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > > > FAILED:
> > > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj
> > > > ...
> > > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj.d -o
> > > > drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.obj -c
> > > > ../../root/dpdk/drivers/net/i40e/i40e_rxtx_vec_avx512.c
> > > > {standard input}: Assembler messages:
> > > > {standard input}:112: Error: invalid register for .seh_savexmm {standard
> > > > input}:114: Error: invalid register for .seh_savexmm ...
> > > > ...
> > > > {standard input}:25351: Error: invalid register for .seh_savexmm
> > > > {standard
> > > > input}:25352: Error: invalid register for .seh_savexmm [225/232]
> > > > Generating
> > > > symbol file lib/librte_net-21.dll.p/librte_net-21.dll.symbols
> > > > ninja: build stopped: subcommand failed.
> > > > ```
> > > >
> > > > OS: Fedora 32
> > > > Meson: 0.55.3
> > > > MinGW: Fedora MinGW 9.2.1-6.fc32
> > > >
> > > > - Ali
> > >
> > > Those errors were detected in the CI tests for this patch [1], we should
> > > pay more attention to those now that 2 PMDs are supported on Windows.
> > >
> > > [1]: https://lab.dpdk.org/results/dashboard/patchsets/15164/
> >
> > I won't grmbl about how CI reports are not being looked at (or maybe I
> > just did :)).
> >
> > This simple patch seems to work for me:
> >
> > diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
> > index c0acdf4fd4..c9a1a50407 100644
> > --- a/drivers/net/i40e/meson.build
> > +++ b/drivers/net/i40e/meson.build
> > @@ -54,7 +54,7 @@ if arch_subdir == 'x86'
> > cc.has_argument('-mavx512f') and
> > cc.has_argument('-mavx512bw'))
> >
> > - if i40e_avx512_cpu_support == true or i40e_avx512_cc_support == true
> > + if not is_windows and (i40e_avx512_cpu_support == true or
> > i40e_avx512_cc_support == true)
> > cflags += ['-DCC_AVX512_SUPPORT']
> > avx512_args = [cflags, '-mavx512f', '-mavx512bw']
> > if cc.has_argument('-march=skylake-avx512')
> >
> >
> > If nobody has a better fix, I'll send it later.
>
>
> For info, I don't reproduce the compilation issue on my machine.
My build system has been upgraded from fc31 to fc32 so I guess this
has something to do with it.
--
David Marchand
Re: [dpdk-dev] [PATCH v3 0/3] AVX512 vPMD on i40e
> > For info, I don't reproduce the compilation issue on my machine. > > My build system has been upgraded from fc31 to fc32 so I guess this has > something to do with it. > I can reproduce with (Fedora MinGW 9.2.1-6.fc32), but not with (Fedora MinGW 10.2.1-2.fc33). - Ali
Re: [dpdk-dev] [PATCH] build: remove compatibility build defines
On Wed, Jan 20, 2021 at 01:44:47AM +0100, Thomas Monjalon wrote: > 09/12/2020 18:14, Bruce Richardson: > > As announced in the deprecation note, remove all compatibility build > > defines from previous make/meson versions and use only the standardized > > ones - RTE_LIB_ for libraries, and RTE__ for drivers. > > > > Signed-off-by: Bruce Richardson > > Applied with a note in the API release notes: > > * config: Removed the old macros, included in ``rte_config.h``, > to indicate which DPDK libraries and drivers are built. > The new macros are generated by meson in a standardized format: > ``RTE_LIB_`` and ``RTE__``, where ``NAME`` is > the upper-case component name, e.g. ``EAL``, ``ETHDEV``, ``VIRTIO``, > and ``CLASS`` is the upper-case driver class, e.g. ``NET``, ``CRYPTO``. > Thanks, Thomas.
Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
> -Original Message- > From: Guo, Jia > Sent: Tuesday, January 19, 2021 12:19 PM > To: Zhang, Qi Z ; tho...@monjalon.net; Yigit, Ferruh > ; andrew.rybche...@oktetlabs.ru; Iremonger, Bernard > ; Lu, Wenzhuo ; Xing, > Beilei > Cc: Wu, Jingjing ; Yang, Qiming > ; Wang, Haiyue ; > dev@dpdk.org; Guo, Jia ; Su, Simei ; > or...@nvidia.com; getel...@nvidia.com; maxime.coque...@redhat.com; > jer...@marvell.com; ajit.khapa...@broadcom.com; bi...@nvidia.com; Kinsella, > Ray ; do...@redhat.com; david.march...@redhat.com > Subject: [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf > > Add eCPRI tunnel port add and rm ops to configure eCPRI UDP tunnel port in > dcf. > > Signed-off-by: Jeff Guo > --- > v5: > rebase patch > > v4: > add doc > --- > doc/guides/rel_notes/release_21_02.rst | 12 + > drivers/net/ice/ice_dcf_ethdev.c | 67 ++ > 2 files changed, 79 insertions(+) > > diff --git a/doc/guides/rel_notes/release_21_02.rst > b/doc/guides/rel_notes/release_21_02.rst > index 78ec2758e2..6b7870779f 100644 > --- a/doc/guides/rel_notes/release_21_02.rst > +++ b/doc/guides/rel_notes/release_21_02.rst > @@ -106,6 +106,18 @@ New Features > >* Added Double VLAN support for DCF switch QinQ filtering. > > +* **Updated the Intel ice driver.** > + > + Updated the Intel ice driver with new features and improvements, including: > + > + * Added support for UDP dynamic port assignment for eCPRI protocol > feature. Need to claim this is a feature for ice DCF, reword to Added support for UDP dynamic port assignment for eCPRI tunnel in DCF. Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH v3 0/2] iavf: update the VLAN offload message
> -Original Message- > From: Xing, Beilei > Sent: Wednesday, January 20, 2021 1:46 PM > To: Wang, Haiyue ; dev@dpdk.org > Cc: Yang, Qiming ; Zhang, Qi Z ; > Fu, Qi ; Wang, Haiyue > Subject: RE: [dpdk-dev] [PATCH v3 0/2] iavf: update the VLAN offload message > > > > > -Original Message- > > From: dev On Behalf Of Haiyue Wang > > Sent: Wednesday, January 20, 2021 12:18 PM > > To: dev@dpdk.org > > Cc: Yang, Qiming ; Zhang, Qi Z > > ; Fu, Qi ; Wang, Haiyue > > > > Subject: [dpdk-dev] [PATCH v3 0/2] iavf: update the VLAN offload > > message > > > > Haiyue Wang (2): > > common/iavf: support VLAN filtering > > net/iavf: align to the new VLAN offload name > > > > drivers/common/iavf/virtchnl.h | 67 > > -- > > drivers/net/iavf/iavf_vchnl.c | 20 +- > > 2 files changed, 66 insertions(+), 21 deletions(-) > > > > -- > > 2.30.0 > > Acked-by: Beilei Xing > Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
20/01/2021 11:14, Zhang, Qi Z: > From: Guo, Jia > > + * Added support for UDP dynamic port assignment for eCPRI protocol > > feature. > > Need to claim this is a feature for ice DCF What is DCF?
Re: [dpdk-dev] [PATCH v2] doc: update release notes for iavf
> -Original Message-
> From: Zhang, Yuying
> Sent: Wednesday, January 20, 2021 10:07 AM
> To: dev@dpdk.org; Zhang, Qi Z ; Wu, Jingjing
>
> Cc: Zhang, Yuying
> Subject: [PATCH v2] doc: update release notes for iavf
>
> Add iavf PMD new feature in release notes.
>
> Fixes: 61abc5f611a0 ("net/iavf: support TCP/UDP flow item without input set")
>
> Signed-off-by: Yuying Zhang
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH v4 1/3] build: add aarch64 clang to meson cross-compile
20/01/2021 09:24, Juraj Linkeš: > From: Thomas Monjalon > > 19/01/2021 09:33, Juraj Linkeš: > > > Create meson cross-file arm64_armv8_linux_clang_ubuntu1804. > > > > Why is it specific to Ubuntu 18.04? > > I don't want to add specifc cross files per distributions. > > > > > Use clang/LLVM toolchain with sysroot pointing to gcc cross stdlib. > > > > > > The sysroot path must be in the cross-file so that Clang can find the > > > proper headers: > > > * setting CFLAGS, LDFLAGS or -Dc_args, -Dc_link_args doesn't affect > > > cross builds (only native builds). Support added in 0.51.0. > > > * setting pkg-config vars only affects lib searching, not includes > > > * splitting the cross-file into two (one with clang info, one with > > > paths) doesn't work. Support added in 0.52.0. > > > > I don't understand the explanations above. > > Please explain what is the bug and how it is fixed. > > > > I guess the missing piece is that the sysroot path is the ubuntu specific > part. The explanations illustrate why we can't have a generic cross file with > the current meson version - there's no way to pass the paths to cross builds. > Now that I think about it, the commit message needs a rewrite - I should've > mentioned that clang/llvm doesn't provide it's own standard c lib, so that > has to come from elsewhere (such as gcc) and thus we have to provide the > paths. Can it be done with the option -Dc_args? > > [...] > > > +c_args = ['-target', 'aarch64-linux-gnu', '--sysroot', > > > +'/usr/aarch64-linux-gnu'] c_link_args = ['-target', > > > +'aarch64-linux-gnu', '-fuse-ld=lld', '--gcc-toolchain=/usr']
Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, January 20, 2021 6:20 PM > To: Guo, Jia ; Yigit, Ferruh ; Lu, > Wenzhuo ; Xing, Beilei ; Zhang, > Qi Z > Cc: andrew.rybche...@oktetlabs.ru; Iremonger, Bernard > ; Wu, Jingjing ; Yang, > Qiming ; Wang, Haiyue ; > dev@dpdk.org; Su, Simei ; or...@nvidia.com; > getel...@nvidia.com; maxime.coque...@redhat.com; jer...@marvell.com; > ajit.khapa...@broadcom.com; bi...@nvidia.com; Kinsella, Ray > ; do...@redhat.com; david.march...@redhat.com > Subject: Re: [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf > > 20/01/2021 11:14, Zhang, Qi Z: > > From: Guo, Jia > > > + * Added support for UDP dynamic port assignment for eCPRI protocol > > > feature. > > > > Need to claim this is a feature for ice DCF > > What is DCF? > > Its "Device Config Function" (DCF), please check ice.rst for detail. Regards Qi
Re: [dpdk-dev] [PATCH v8 2/3] build: use Python pmdinfogen
20/01/2021 08:23, Dmitry Kozlyuk:
> On Wed, 20 Jan 2021 01:05:59 +0100, Thomas Monjalon wrote:
> > This is now the right timeframe to introduce this change
> > with the new Python module dependency.
> > Unfortunately, the ABI check is returning an issue:
> >
> > 'const char mlx5_common_pci_pmd_info[62]' was changed
> > to 'const char mlx5_common_pci_pmd_info[60]' at rte_common_mlx5.pmd.c
>
> Will investigate and fix ASAP.
>
> > Few more comments below:
> >
> > 20/10/2020 19:44, Dmitry Kozlyuk:
> > > --- a/buildtools/meson.build
> > > +++ b/buildtools/meson.build
> > > +if host_machine.system() != 'windows'
> >
> > You can use "is_windows".
>
> It's defined by config/meson.build, which is processed after
> buidtools/meson.build, because of the dependency, if swapped:
>
> config/x86/meson.build:6:1: ERROR: Unknown variable
> "binutils_avx512_check".
OK
> > > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > > +* ``pyelftools`` (version 0.22+)
> >
> > This requirement is missing in doc/guides/freebsd_gsg/build_dpdk.rst
>
> OK.
>
> > > --- a/meson.build
> > > +++ b/meson.build
> > > -subdir('buildtools/pmdinfogen')
> >
> > This could be in patch 3 (removing the code).
>
> It would redefine "pmdinfogen" variable to old pmdinfogen.
> Besides, why build what's not used at this patch already?
Just trying to find the best patch split.
If needed, OK to keep as is.
Re: [dpdk-dev] [PATCH v4 1/3] build: add aarch64 clang to meson cross-compile
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, January 20, 2021 11:22 AM > To: Juraj Linkeš > Cc: david.march...@redhat.com; acon...@redhat.com; > maicolgabr...@hotmail.com; jerinjac...@gmail.com; ferruh.yi...@intel.com; > ruifeng.w...@arm.com; dev@dpdk.org; bruce.richard...@intel.com > Subject: Re: [dpdk-dev] [PATCH v4 1/3] build: add aarch64 clang to meson > cross- > compile > > 20/01/2021 09:24, Juraj Linkeš: > > From: Thomas Monjalon > > > 19/01/2021 09:33, Juraj Linkeš: > > > > Create meson cross-file arm64_armv8_linux_clang_ubuntu1804. > > > > > > Why is it specific to Ubuntu 18.04? > > > I don't want to add specifc cross files per distributions. > > > > > > > Use clang/LLVM toolchain with sysroot pointing to gcc cross stdlib. > > > > > > > > The sysroot path must be in the cross-file so that Clang can find > > > > the proper headers: > > > > * setting CFLAGS, LDFLAGS or -Dc_args, -Dc_link_args doesn't > > > > affect cross builds (only native builds). Support added in 0.51.0. > > > > * setting pkg-config vars only affects lib searching, not includes > > > > * splitting the cross-file into two (one with clang info, one with > > > > paths) doesn't work. Support added in 0.52.0. > > > > > > I don't understand the explanations above. > > > Please explain what is the bug and how it is fixed. > > > > > > > I guess the missing piece is that the sysroot path is the ubuntu specific > > part. > The explanations illustrate why we can't have a generic cross file with the > current meson version - there's no way to pass the paths to cross builds. Now > that I think about it, the commit message needs a rewrite - I should've > mentioned that clang/llvm doesn't provide it's own standard c lib, so that > has to > come from elsewhere (such as gcc) and thus we have to provide the paths. > > Can it be done with the option -Dc_args? > Not in Meson 0.47.1, it's explained in the commit msg: * setting CFLAGS, LDFLAGS or -Dc_args, -Dc_link_args doesn't affect cross builds (only native builds). Support added in 0.51.0. > > > > [...] > > > > +c_args = ['-target', 'aarch64-linux-gnu', '--sysroot', > > > > +'/usr/aarch64-linux-gnu'] c_link_args = ['-target', > > > > +'aarch64-linux-gnu', '-fuse-ld=lld', '--gcc-toolchain=/usr'] > > >
Re: [dpdk-dev] [dpdk-dev v5] net/ice: enable eCPRI tunnel port configure in dcf
20/01/2021 11:23, Zhang, Qi Z: > From: Thomas Monjalon > > What is DCF? > > > > > Its "Device Config Function" (DCF), please check ice.rst for detail. Thank you. As you know, I am interested in the privileged rights. This is what I found in ice.rst: A DCF PMD bounds to the device's trusted VF with ID 0 [...] #. Enable the VF0 trust on:: ip link set dev enp24s0f0 vf 0 trust on Does it mean only VF 0 can be trusted?
