Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table
Hi,
I'm sorry, but quota character in "Fixes" tags is still wrong, causing the
checking script errors.
It should be " (0x22 ASCII), not ' (0x27 ASCII).
Beside this:
Acked-by: Viacheslav Ovsiienko
> -Original Message-
> From: Dey, Souvik
> Sent: Tuesday, February 2, 2021 19:49
> To: Raslan Darawsheh ; Slava Ovsiienko
> ; Matan Azrad ; Shahaf
> Shuler
> Cc: dev@dpdk.org; sta...@dpdk.org; Souvik Dey
> Subject: [PATCH v3] common/mlx5: fix storing the synched MAC to internal
> table
>
> From: Souvik Dey
>
> As the internal MAC table is divided into Unicast and Multicast address
> sections, we should check the type of synched MAC address before storing it
> to the internal table. Currently the check is not done, and the synched MAC of
> 33:33:00:00:00:01 gets stored in the unicast section (mostly index 1) causing
> all subsequent mlx5_set_mc_addr_list() to fail with error -EADDRINUSE, as the
> mac_list contains the MAC 33:33:00:00:00:01. This denies adding of any new
> multicast address to the internal list and also fails to add the MAC address
> to
> the device in case of SR-IOV VF.
>
> Fixes: f22442cb5d42 ('net/mlx5: reduce Netlink commands dependencies')
> Fixes: ccdcba53a3f4 ('net/mlx5: use Netlink to add/remove MAC addresses')
> Cc: sta...@dpdk.org
>
> Signed-off-by: Souvik Dey
> ---
> v2:
> * net/ -> common/
> * space after mlx5:
> * synched -> synched
> * section -> sections
> * rewording which causes -> causing
> * typo: case (to remove)
> * added Fixes for LTS ML
> ---
> v3:
> * Changed the "" in Fixes tags to ''.
> ---
> drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/common/mlx5/linux/mlx5_nl.c
> b/drivers/common/mlx5/linux/mlx5_nl.c
> index 40d8620..ef7a521 100644
> --- a/drivers/common/mlx5/linux/mlx5_nl.c
> +++ b/drivers/common/mlx5/linux/mlx5_nl.c
> @@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned int
> iface_idx,
> break;
> if (j != n)
> continue;
> - /* Find the first entry available. */
> - for (j = 0; j != n; ++j) {
> - if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> - mac_addrs[j] = macs[i];
> - break;
> + if (rte_is_multicast_ether_addr(&macs[i])) {
> + /* Find the first entry available. */
> + for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
> + }
> + } else {
> + /* Find the first entry available. */
> + for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
> }
> }
> }
> --
> 2.9.3.windows.1
>
>
> Notice: This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure,
> reliance or distribution by others or forwarding without express permission is
> strictly prohibited. If you are not the intended recipient, please notify the
> sender immediately and then delete all copies, including any attachments.
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix UDP zero checksum error
> -Original Message-
> From: Wang, Haiyue
> Sent: Wednesday, February 3, 2021 10:19 AM
> To: dev@dpdk.org
> Cc: pvale...@redhat.com; acon...@redhat.com;
> david.march...@redhat.com; Zhang, Qi Z ; Rong, Leyi
> ; Tu, Lijuan ;
> ruifeng.w...@arm.com; feifei.wa...@arm.com; Wang, Haiyue
> ; sta...@dpdk.org; Guo, Jia ;
> Richardson, Bruce ; Ananyev, Konstantin
>
> Subject: [PATCH v2] net/ixgbe: fix UDP zero checksum error
>
> There is an 82599 errata that UDP frames with a zero checksum are incorrectly
> marked as checksum invalid by the hardware. This was leading to misleading
> PKT_RX_L4_CKSUM_BAD flag.
>
> This patch changes the bad UDP checksum to PKT_RX_L4_CKSUM_UNKNOWN,
> so the software application will then have to recompute the checksum itself if
> needed.
>
> Bugzilla ID: 629
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Reported-by: Paolo Valerio
> Signed-off-by: Haiyue Wang
Applied to dpdk-next-net-intel.
Thanks
Qi
[dpdk-dev] [PATCH] net/mlx5: fix E-Switch egress mirror flow validation
The stored metadata in all registers C were lost in E-Switch egress
mirroring flows due to HW limitation. The register C0 keeps the
source vport index that also was used as one of the flow matcher.
While sample action and jump action (jump to table X) was in the
E-Switch egress flow, the flow in the next table X wasn't hit since
source vport value lost.
The modify actions after sample action should be applied to the packet
on normal path, not to the sampled packet. In order to support this
mlx5 PMD splits the flow into sub flows and jump action is engaged
implicitly, causing malfunction due to registers corruption.
This patch adds the validation the for E-Switch mirroring jump egress
flow, and checks for this hidden jump as well and reject the flows with
modify actions after sampling.
Fixes: 6a951567c159 ("net/mlx5: support E-Switch mirroring and jump in one
flow")
Cc: sta...@dpdk.org
Signed-off-by: Jiawei Wang
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_dv.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 8c11ac3..ee1c4f4 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5081,6 +5081,8 @@ struct mlx5_hlist_entry *
* Pointer to the RSS action.
* @param[out] sample_rss
* Pointer to the RSS action in sample action list.
+ * @param[out] fdb_mirror_limit
+ * Pointer to the FDB mirror limitation flag.
* @param[out] error
* Pointer to error structure.
*
@@ -5095,6 +5097,7 @@ struct mlx5_hlist_entry *
uint64_t item_flags,
const struct rte_flow_action_rss *rss,
const struct rte_flow_action_rss **sample_rss,
+ int *fdb_mirror_limit,
struct rte_flow_error *error)
{
struct mlx5_priv *priv = dev->data->dev_private;
@@ -5269,6 +5272,9 @@ struct mlx5_hlist_entry *
NULL,
"E-Switch must has a dest "
"port for mirroring");
+ if (!priv->config.hca_attr.reg_c_preserve &&
+priv->representor_id != -1)
+ *fdb_mirror_limit = 1;
}
/* Continue validation for Xcap actions.*/
if ((sub_action_flags & MLX5_FLOW_XCAP_ACTIONS) &&
@@ -6010,6 +6016,8 @@ struct mlx5_hlist_entry *
uint16_t ether_type = 0;
int actions_n = 0;
uint8_t item_ipv6_proto = 0;
+ int fdb_mirror_limit = 0;
+ int modify_after_mirror = 0;
const struct rte_flow_item *geneve_item = NULL;
const struct rte_flow_item *gre_item = NULL;
const struct rte_flow_item *gtp_item = NULL;
@@ -6429,6 +6437,9 @@ struct mlx5_hlist_entry *
++actions_n;
action_flags |= MLX5_FLOW_ACTION_FLAG |
MLX5_FLOW_ACTION_MARK_EXT;
+ if (action_flags & MLX5_FLOW_ACTION_SAMPLE)
+ modify_after_mirror = 1;
+
} else {
action_flags |= MLX5_FLOW_ACTION_FLAG;
++actions_n;
@@ -6448,6 +6459,8 @@ struct mlx5_hlist_entry *
++actions_n;
action_flags |= MLX5_FLOW_ACTION_MARK |
MLX5_FLOW_ACTION_MARK_EXT;
+ if (action_flags & MLX5_FLOW_ACTION_SAMPLE)
+ modify_after_mirror = 1;
} else {
action_flags |= MLX5_FLOW_ACTION_MARK;
++actions_n;
@@ -6463,6 +6476,8 @@ struct mlx5_hlist_entry *
/* Count all modify-header actions as one action. */
if (!(action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS))
++actions_n;
+ if (action_flags & MLX5_FLOW_ACTION_SAMPLE)
+ modify_after_mirror = 1;
action_flags |= MLX5_FLOW_ACTION_SET_META;
rw_act_num += MLX5_ACT_NUM_SET_META;
break;
@@ -6475,6 +6490,8 @@ struct mlx5_hlist_entry *
/* Count all modify-header actions as one action. */
if (!(action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS))
++actions_n;
+ if (action_flags & MLX5_FLOW_ACTION_SAMPLE)
+ modify_after_mirror = 1;
action_flags |= MLX5_FLOW_ACTION_SET_TAG;
rw_act_num += MLX5_ACT_N
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix UDP zero checksum error
On Wed, Feb 3, 2021 at 9:07 AM Zhang, Qi Z wrote:
> > -Original Message-
> > From: Wang, Haiyue
> > Sent: Wednesday, February 3, 2021 10:19 AM
> > To: dev@dpdk.org
> > Cc: pvale...@redhat.com; acon...@redhat.com;
> > david.march...@redhat.com; Zhang, Qi Z ; Rong, Leyi
> > ; Tu, Lijuan ;
> > ruifeng.w...@arm.com; feifei.wa...@arm.com; Wang, Haiyue
> > ; sta...@dpdk.org; Guo, Jia ;
> > Richardson, Bruce ; Ananyev, Konstantin
> >
> > Subject: [PATCH v2] net/ixgbe: fix UDP zero checksum error
> >
> > There is an 82599 errata that UDP frames with a zero checksum are
> > incorrectly
> > marked as checksum invalid by the hardware. This was leading to misleading
> > PKT_RX_L4_CKSUM_BAD flag.
> >
> > This patch changes the bad UDP checksum to PKT_RX_L4_CKSUM_UNKNOWN,
> > so the software application will then have to recompute the checksum itself
> > if
> > needed.
> >
> > Bugzilla ID: 629
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Paolo Valerio
> > Signed-off-by: Haiyue Wang
>
> Applied to dpdk-next-net-intel.
Why the rush for applying?
The ARM part is not done, Paolo said he would test the patch and I am
pretty sure a review can't hurt.
--
David Marchand
[dpdk-dev] [PATCH] mempool: fix invalid panic on dump or audit
When doing a mempool dump or an audit, the application can panic because
the length of the cache is greater than the flush threshold, which is
seen as a fatal error. But this can temporarily happen when the mempool
is in use.
Fix the panic condition to abort only when the cache length is greater
than the array.
Fixes: ea5dd2744b90 ("mempool: cache optimisations")
Cc: sta...@dpdk.org
Signed-off-by: Olivier Matz
---
lib/librte_mempool/rte_mempool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index b9f3fbd614..afb1239c8d 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -1167,7 +1167,7 @@ mempool_audit_cache(const struct rte_mempool *mp)
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
const struct rte_mempool_cache *cache;
cache = &mp->local_cache[lcore_id];
- if (cache->len > cache->flushthresh) {
+ if (cache->len > RTE_DIM(cache->objs)) {
RTE_LOG(CRIT, MEMPOOL, "badness on cache[%u]\n",
lcore_id);
rte_panic("MEMPOOL: invalid cache len\n");
--
2.29.2
Re: [dpdk-dev] [PATCH 1/2] doc: more info of rte flow shared action
Hi Jack, >-Original Message- >From: dev On Behalf Of Ori Kam >Sent: Wednesday, February 3, 2021 9:51 AM >To: Jack Min >Cc: dev@dpdk.org >Subject: Re: [dpdk-dev] [PATCH 1/2] doc: more info of rte flow shared action > >Hi Jack, > >> -Original Message- >> From: Jack Min >> Subject: [PATCH 1/2] doc: more info of rte flow shared action >> >> Added more information of shared action on how to update, query, and >> the benefits. >> >> Signed-off-by: Xiaoyu Min >> --- >> doc/guides/prog_guide/rte_flow.rst | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/doc/guides/prog_guide/rte_flow.rst >> b/doc/guides/prog_guide/rte_flow.rst >> index 0b8c243fe1..62a57919eb 100644 >> --- a/doc/guides/prog_guide/rte_flow.rst >> +++ b/doc/guides/prog_guide/rte_flow.rst >> @@ -2756,6 +2756,13 @@ Flow utilize shared action by handle as >> returned from The behaviour of the shared action defined by >> ``action`` argument of type ``struct rte_flow_action`` passed to >> ``rte_flow_shared_action_create()``. >> >> +Multiple flows can use the same shared action. >> +The shared action can be in-place updated by >> ``rte_flow_shared_action_update()`` >> +without destroying flow and creating flow again. >> + >> +The shared action specified data (e.g. counter) can be queried by >> +``rte_flow_shared_action_query()``. >> + >> .. _table_rte_flow_shared_action: >> >> .. table:: SHARED >> -- >> 2.30.0 > >Acked-by: Ori Kam >Best, >Ori Reviewed-by: Asaf Penso
Re: [dpdk-dev] [PATCH 2/2] doc: group mlx5 shared actions
Hi Jack, Regards, Asaf Penso >-Original Message- >From: dev On Behalf Of Jack Min >Sent: Tuesday, February 2, 2021 2:24 PM >To: Matan Azrad ; Shahaf Shuler >; Slava Ovsiienko >Cc: dev@dpdk.org >Subject: [dpdk-dev] [PATCH 2/2] doc: group mlx5 shared actions > >Put all supported shared actions in one new table > >Signed-off-by: Xiaoyu Min >--- > doc/guides/nics/mlx5.rst | 30 +- > 1 file changed, 21 insertions(+), 9 deletions(-) > >diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index >e99fea4342..dbd7ae1bb9 100644 >--- a/doc/guides/nics/mlx5.rst >+++ b/doc/guides/nics/mlx5.rst >@@ -1497,10 +1497,10 @@ Supported hardware offloads >| | | | | rdma-core 23 | >| | | | | ConnectX-4| >+---+-+-+ >- | RSS shared action | | | | DPDK 20.11| >- | | | N/A | | OFED 5.2 | >- | | | | | rdma-core 33 | >- | | | | | ConnectX-5| >+ | Shared action | | | | | >+ | | | :numref:`sact`| | :numref:`sact`| >+ | | | | | | >+ | | | | | | >+---+-+-+ >| | VLAN| | DPDK 19.11| | DPDK 19.11| >| | (of_pop_vlan / | | OFED 4.7-1| | OFED 4.7-1| >@@ -1580,11 +1580,6 @@ Supported hardware offloads >| | | rdma-core 32 | | N/A | >| | | ConnectX-5 | | ConnectX-5| >+---+-+-+ >- | Age shared action | | DPDK 20.11 | | DPDK 20.11| >- | | | OFED 5.2 | | OFED 5.2 | >- | | | rdma-core 32 | | rdma-core 32 | >- | | | ConnectX-6 Dx| | ConnectX-6 Dx | >- +---+-+-+ >| Encapsulation | | DPDK 21.02 | | DPDK 21.02| >| GTP PSC | | OFED 5.2 | | OFED 5.2 | >| | | rdma-core 35 | | rdma-core 35 | >@@ -1601,6 +1596,23 @@ Supported hardware offloads >| | | ConnectX-5| | ConnectX-5| >+---+-+-+ > >+.. table:: Minimal SW/HW versions for shared action offload >+ :name: sact >+ >+ +---+-+-+ >+ | Shared Action | with E-Switch | with NIC| >+ >+===+=+ >=+ >+ | RSS | | | | DPDK 20.11| >+ | | | N/A | | OFED 5.2 | >+ | | | | | rdma-core 33 | >+ | | | | | ConnectX-5| >+ +---+-+-+ >+ | Age | | DPDK 20.11 | | DPDK 20.11| >+ | | | OFED 5.2 | | OFED 5.2 | >+ | | | rdma-core 32 | | rdma-core 32 | >+ | | | ConnectX-6 Dx| | ConnectX-6 Dx | >+ +---+-+-+ >+ > Notes for metadata > -- > >-- >2.30.0 Reviewed-by: Asaf Penso
Re: [dpdk-dev] [PATCH 00/17] bugfixes and small functionality for hns3
On 2/3/2021 7:46 AM, Lijun Ou wrote: This patch series add some bugfixes and some small functions. In order to fix some bugfixes, we had to do some code rework, for example patch[13/17]. Chengchang Tang (6): net/hns3: support module EEPROM dump net/hns3: add more registers to dump net/hns3: fix stats flip overflow net/hns3: replace all atomic type with C11 atomic builtins net/hns3: fix cmdq cleared during firmware process net/hns3: fix VF reset after MBX failed Chengwen Feng (4): net/hns3: implement cleanup for Tx done net/hns3: constraint TM peak rate net/hns3: remove MPLS type from supported flow items net/hns3: fix FD rule residue in hardware when malloc fail Huisong Li (5): net/hns3: fix query order of link status and link info net/hns3: fix link status change from firmware net/hns3: encapsulate a port shaping interface net/hns3: support PF on electrical net device net/hns3: add check for max pkt length of Rx Lijun Ou (1): net/hns3: fix RSS indirection table size Min Hu (Connor) (1): net/hns3: add enhance stats function Hi Lijun, Is this for next release or current release? We are a day away from the -rc3 and a week (almost) away from the actual release, it is safer to limit the patches to fixes at this stage. If above set is for this release, can you please make a new version to have only fixes, and leave the new supports and refactoring and not important fixes to next release? Thanks, ferruh
Re: [dpdk-dev] [PATCH v6 0/2] support both PIO and MMIO BAR for legacy device in virtio PMD
Hi Huawei, On 2/1/21 8:43 AM, 谢华伟(此时此刻） wrote: > > On 2021/1/29 11:25, chris wrote: >> Hi ferruh and maxime: >> >> v6 changes: >> >> send v6. Let us discuss if merge in this or early next release. > > Ping. The -rc2 was released on the 29th, so I think it is too late for this release. As Ferruh suggested, he can pick it early for next release, so doing that we'll be sure to have a wider testing. Apart from that, I am fine with the series. Thanks, Maxime > >> >> Sorry that forget to reply to previous message id. >> >>> - change to DEBUG level for IO bar detection in pci_uio_ioport_map >>> - rework the code in iobar branch >>> - fixes commit message format issue >>> - temporarily remove the 3rd patch for vfio path, leave it for >>> future discusssion >>> - rework against virtio_pmd_rework_v2 >>> >>> >>> huawei.xhw (2): >>> bus/pci: use PCI standard sysfs entry to get PIO address >>> bus/pci: support MMIO in PCI ioport accessors >>> >>> drivers/bus/pci/linux/pci.c | 81 --- >>> drivers/bus/pci/linux/pci_uio.c | 170 >>> >>> 2 files changed, 118 insertions(+), 133 deletions(-) >>> >
Re: [dpdk-dev] [PATCH v6 1/2] bus/pci: use PCI standard sysfs entry to get PIO address
On 1/29/21 4:18 AM, 谢华伟(此时此刻） wrote: > From: "huawei.xhw" > > Currently virtio PMD asssumes legacy device uses PIO bar. > There are three ways to get PIO(PortIO) address for virtio legacy device. > under igb_uio, get pio address from uio/uio# sysfs attribute > under uio_pci_generic: > for X86, get PIO address from /proc/ioport > for other ARCH, get PIO address from standard PCI sysfs attribute > > Actually, igb_uio sysfs attribute exports exactly the same thing as standard > PCI sysfs, i.e, > pci_dev->resource[] > > This patch fixes these messy things, and uses standard PCI sysfs attribute. > > Signed-off-by: huawei xie > Reviewed-by: Maxime Coquelin > --- > drivers/bus/pci/linux/pci.c | 77 > - > drivers/bus/pci/linux/pci_uio.c | 64 -- > 2 files changed, 46 insertions(+), 95 deletions(-) > Reviewed-by: Maxime Coquelin
Re: [dpdk-dev] [PATCH v6 2/2] bus/pci: support MMIO in PCI ioport accessors
On 1/29/21 4:18 AM, 谢华伟(此时此刻） wrote: > |From: "huawei.xhw" With IO BAR, we get > PIO(programmed IO) address. With MMIO BAR, we get mapped virtual > address. We distinguish PIO(Programmed IO) and MMIO(memory mapped IO) by > their address like how kernel does. ioread/write8/16/32 is provided to > access PIO/MMIO. By the way, for virtio on arch other than x86, BAR flag > indicates PIO but is mapped. Signed-off-by: huawei xie > Reviewed-by: Maxime Coquelin > --- drivers/bus/pci/linux/pci.c | 4 -- > drivers/bus/pci/linux/pci_uio.c | 124 > ++-- 2 files changed, 81 > insertions(+), 47 deletions(-)| Reviewed-by: Maxime Coquelin Thanks, Maxime
Re: [dpdk-dev] [PATCH v3 0/3] update doc for hns3
On 1/29/2021 11:57 AM, Ferruh Yigit wrote: On 1/29/2021 9:22 AM, Lijun Ou wrote: Here series add some updates for hns3 rst and TM feature note for hns3 as well as FEC feature notes. v3: 1. merge patch[2/3] into patch[1] base on v2 2. fix some format errors v2: 1. fix a meson build warning for patch[4/5] 2. add a new patch for update hns3.ini and cxgbe.ini 3. add Fixes for all patches. Lijun Ou (2): doc: update release notes for hns3 doc: fix hns3 rst Min Hu (Connor) (1): doc: add FEC in NIC features For series, Reviewed-by: Ferruh Yigit Series applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH] examples/vhost: add error propagation in ioat ops
On 1/31/21 1:36 PM, Cheng Jiang wrote:
> It makes more sense to add error propagation for rte_ioat_completed_ops.
>
> Signed-off-by: Cheng Jiang
> ---
> examples/vhost/ioat.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
> index dbad28d43..60b73be93 100644
> --- a/examples/vhost/ioat.c
> +++ b/examples/vhost/ioat.c
> @@ -22,7 +22,6 @@ struct packet_tracker {
>
> struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
>
> -
> int
> open_ioat(const char *value)
> {
> @@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
> struct rte_vhost_async_status *opaque_data, uint16_t count)
> {
> uint32_t i_desc;
> - int dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
This change from uint16_t to int does not seem related to the purpose of
this patch. Is it?
> struct rte_vhost_iov_iter *src = NULL;
> struct rte_vhost_iov_iter *dst = NULL;
> unsigned long i_seg;
> @@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid, uint16_t
> queue_id,
> unsigned short mask = MAX_ENQUEUED_SIZE - 1;
> unsigned short i;
>
> - int dev_id = dma_bind[vid].dmas[queue_id * 2
> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
> + VIRTIO_RXQ].dev_id;
> n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
> - if (n_seg <= 0)
> + if (n_seg < 0) {
> + RTE_LOG(ERR,
> + VHOST_DATA,
> + "fail to poll completed buf on IOAT device %u",
> + dev_id);
> + return 0;
> + }
> + if (n_seg == 0)
> return 0;
>
> cb_tracker[dev_id].ioat_space += n_seg;
>
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
On 2/2/21 7:17 AM, Cheng Jiang wrote:
> Remove async inflight packet counter since there is no need to keep
> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment number
> tracking ring from being exhausted.
Is that an optimization or a fix?
If the former, let's move it to v21.05.
>
> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>
> Signed-off-by: Cheng Jiang
> ---
> v3: fixed fixes commit id in git log
>
> v2: fixed a typo
>
> examples/vhost/ioat.h | 2 +-
> examples/vhost/main.c | 10 +-
> examples/vhost/main.h | 1 -
> 3 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h
> index 0a1dbb811..1aa28ed6a 100644
> --- a/examples/vhost/ioat.h
> +++ b/examples/vhost/ioat.h
> @@ -11,7 +11,7 @@
>
> #define MAX_VHOST_DEVICE 1024
> #define IOAT_RING_SIZE 4096
> -#define MAX_ENQUEUED_SIZE 512
> +#define MAX_ENQUEUED_SIZE 4096
Basically, this the size of the ring size, correct?
It might be further simplified then.
>
> struct dma_info {
> struct rte_pci_addr addr;
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index e74fc8750..ca73e7086 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev)
>
> complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
> VIRTIO_RXQ, p_cpl, MAX_PKT_BURST);
> - if (complete_count) {
> - __atomic_sub_fetch(&vdev->nr_async_pkts, complete_count,
> - __ATOMIC_SEQ_CST);
> + if (complete_count)
> free_pkts(p_cpl, complete_count);
> - }
> }
>
> static __rte_always_inline void
> @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
> complete_async_pkts(vdev);
> ret = rte_vhost_submit_enqueue_burst(vdev->vid, VIRTIO_RXQ,
> m, nr_xmit, m_cpu_cpl, &cpu_cpl_nr);
> - __atomic_add_fetch(&vdev->nr_async_pkts, ret - cpu_cpl_nr,
> - __ATOMIC_SEQ_CST);
>
> if (cpu_cpl_nr)
> free_pkts(m_cpu_cpl, cpu_cpl_nr);
> @@ -1210,9 +1205,6 @@ drain_eth_rx(struct vhost_dev *vdev)
> enqueue_count = rte_vhost_submit_enqueue_burst(vdev->vid,
> VIRTIO_RXQ, pkts, rx_count,
> m_cpu_cpl, &cpu_cpl_nr);
> - __atomic_add_fetch(&vdev->nr_async_pkts,
> - enqueue_count - cpu_cpl_nr,
> - __ATOMIC_SEQ_CST);
> if (cpu_cpl_nr)
> free_pkts(m_cpu_cpl, cpu_cpl_nr);
>
> diff --git a/examples/vhost/main.h b/examples/vhost/main.h
> index 2d6c05fd7..0ccdce4b4 100644
> --- a/examples/vhost/main.h
> +++ b/examples/vhost/main.h
> @@ -51,7 +51,6 @@ struct vhost_dev {
> uint64_t features;
> size_t hdr_len;
> uint16_t nr_vrings;
> - uint64_t nr_async_pkts;
> struct rte_vhost_memory *mem;
> struct device_statistics stats;
> TAILQ_ENTRY(vhost_dev) global_vdev_entry;
> --
> 2.29.2
>
Re: [dpdk-dev] [PATCH v2] examples/vhost: fix potentially overflowing expression
On 2/2/21 8:24 AM, Cheng Jiang wrote:
> Change the type of buff_idx from uint64_t to uint32_t to fix coverity
> issue.
>
> Coverity issue: 366264
> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>
> Signed-off-by: Cheng Jiang
> ---
> v2: fixed the format of git log
>
> examples/vhost/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index 233a2dc6e..e74fc8750 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -864,7 +864,7 @@ static __rte_always_inline void
> drain_vhost(struct vhost_dev *vdev)
> {
> uint16_t ret;
> - uint64_t buff_idx = rte_lcore_id() * MAX_VHOST_DEVICE + vdev->vid;
> + uint32_t buff_idx = rte_lcore_id() * MAX_VHOST_DEVICE + vdev->vid;
> uint16_t nr_xmit = vhost_txbuff[buff_idx]->len;
> struct rte_mbuf **m = vhost_txbuff[buff_idx]->m_table;
>
> --
> 2.29.2
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH] maintainers: update for nfp
On 2/1/2021 7:56 PM, Ferruh Yigit wrote: On 1/31/2021 10:36 AM, Heinrich Kuhn wrote: Release-on-close has been implemented for the NFP PMD. Remove the UNMAINTAINED flag. Signed-off-by: Heinrich Kuhn --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 77a2273c1..68c5ce6e5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -815,7 +815,7 @@ F: drivers/net/nfb/ F: doc/guides/nics/nfb.rst F: doc/guides/nics/features/nfb.ini -Netronome nfp - UNMAINTAINED +Netronome nfp M: Heinrich Kuhn F: drivers/net/nfp/ F: doc/guides/nics/nfp.rst Acked-by: Ferruh Yigit Applied to dpdk-next-net/main, thanks.
[dpdk-dev] [PATCH] net/mlx5: fix check of shared RSS capability
Existing code to create shared RSS action doesn't fully check
driver capabilities.
Using older driver, if DevX capabilities are insufficient,
the IBV operations are used.
In this case the ind_table_modify operation is not supported, and
shared RSS action can't be modified after creation.
This patch adds check of driver capability, and fails the validation
for shared RSS action in case it is insufficient.
Fixes: d2046c09aa64 ("net/mlx5: support shared action for RSS")
Cc: sta...@dpdk.org
Signed-off-by: Dekel Peled
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_flow_dv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index e0874e3f5f..c14298306c 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -12920,6 +12920,10 @@ __flow_dv_action_rss_update(struct rte_eth_dev *dev,
uint32_t idx,
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, NULL,
"invalid shared action to update");
+ if (priv->obj_ops.ind_table_modify == NULL)
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ACTION, NULL,
+ "cannot modify indirection table");
queue = mlx5_malloc(MLX5_MEM_ZERO,
RTE_ALIGN_CEIL(queue_size, sizeof(void *)),
0, SOCKET_ID_ANY);
@@ -13802,6 +13806,20 @@ flow_dv_action_validate(struct rte_eth_dev *dev,
RTE_SET_USED(conf);
switch (action->type) {
case RTE_FLOW_ACTION_TYPE_RSS:
+ /*
+* priv->obj_ops is set according to driver capabilities.
+* When DevX capabilities are
+* sufficient, it is set to devx_obj_ops.
+* Otherwise, it is set to ibv_obj_ops.
+* ibv_obj_ops doesn't support ind_table_modify operation.
+* In this case the shared RSS action can't be used.
+*/
+ if (priv->obj_ops.ind_table_modify == NULL)
+ return rte_flow_error_set
+ (err, ENOTSUP,
+RTE_FLOW_ERROR_TYPE_ACTION,
+NULL,
+"shared RSS action not supported");
return mlx5_validate_action_rss(dev, action, err);
case RTE_FLOW_ACTION_TYPE_AGE:
if (!priv->sh->aso_age_mng)
--
2.25.1
[dpdk-dev] [PATCH] net/mlx5: fix validation of hash Rx queue pointer
Implementation of mlx5_hrxq_get() tries to get pointer to a hrxq
object, by reusing an existing hrxq, or creating a new one.
There is no check of the obtained pointer, so using it might result
in error.
This patch adds check of the pointer before using it, and return 0
if the pointer is NULL to indicate error.
Fixes: e1592b6c4dea ("net/mlx5: make Rx queue thread safe")
Cc: sta...@dpdk.org
Signed-off-by: Dekel Peled
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_rxq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 92e3a792e1..8f9ee97f7a 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -2353,7 +2353,9 @@ uint32_t mlx5_hrxq_get(struct rte_eth_dev *dev,
return 0;
hrxq = container_of(entry, typeof(*hrxq), entry);
}
- return hrxq->idx;
+ if (hrxq)
+ return hrxq->idx;
+ return 0;
}
/**
--
2.25.1
Re: [dpdk-dev] [PATCH v5 1/1] doc: add release milestones definition
On Wed, Feb 3, 2021 at 8:58 AM Thomas Monjalon wrote: > > From: Asaf Penso > > Adding more information about the release milestones. > This includes the scope of change, expectations, etc. > > Signed-off-by: Asaf Penso > Signed-off-by: Thomas Monjalon > Acked-by: John McNamara > --- > v2: fix styling format and add content in the commit message > v3: change punctuation and avoid plural form when unneeded > v4: avoid abbreviations, "Priority" in -rc, and reword as John suggests > v5: note that release candidates may vary > --- > doc/guides/contributing/patches.rst | 74 + > 1 file changed, 74 insertions(+) > > diff --git a/doc/guides/contributing/patches.rst > b/doc/guides/contributing/patches.rst > index 6dbbd5f8d1..650ae7ef9b 100644 > --- a/doc/guides/contributing/patches.rst > +++ b/doc/guides/contributing/patches.rst > @@ -660,3 +660,77 @@ patch accepted. The general cycle for patch review and > acceptance is: > than rework of the original. > * Trivial patches may be merged sooner than described above at the tree > committer's > discretion. > + > + > +Milestones definition > +- > + > +Each DPDK release has milestones that help everyone to converge to the > release date. > +The following is a list of these milestones > +together with concrete definitions and expectations, > +for a typical release cycle. > +The number and expectations of release candidates might vary slightly. You can still mention that a typical release has 4 rc, since they are described below. Maybe add a link to https://core.dpdk.org/roadmap/#dates. > + > +Roadmap > +~~~ > + > +* Content: new features in libraries, drivers, applications, and examples. > +* Timeframe: to be published before the first day of the release cycle. On the form, roadmap announcements can be either a simple mail or a patch against dpdk-web. > + > +RFC > +~~~ > + > +* Content: public design review for the feature, explaining the need and the > design. > +* Should include the API changes, in libraries and applications. > +* RFC is not mandatory but strongly advised to start early discussion. > +* Nice to have: driver implementation (full or draft), example code, and > documentation. RFC mails/patches can be sent at any time. I would not list this as a release milestone. This part details what should be in a RFC patch for a feature to be considered for the Proposal deadline. How about merging this with the milestone below? On the other hand, those details apply to any RFC, so another option is to put those details earlier in the doc where RFC patches are described. > + > +Proposal Deadline > +~ > + > +* Content: either an RFC as stated above or a v1 patch. > +* Nice to have: code complete for libraries. > + > +rc1 > +~~~ > + > +* Priority: new or updated API. > +* New API should be defined and implemented in libraries. > +* The API should include Doxygen documentation > + and be part of the relevant .rst files (library, release notes). > +* Code and related documentation must be updated atomically in the same > patch. > +* API should be used in a test application (``/app``). > +* At least one PMD should implement the API. > + It can be a draft but must be sent as a separate series. > +* The above should be sent to the mailing list at least 2 weeks before -rc1. > +* Nice to have: example code (``/examples``) This list has items not really specific to rc1, like documentation is mandatory, doc and code updates must be atomic... Can this be moved in a common section? > + > +rc2 > +~~~ > + > +* Priority: drivers. > +* New features should be implemented in drivers. > +* A driver change should include documentation > + in the relevant .rst files (driver, release notes). > +* Code and related documentation must be updated atomically in the same > patch. > +* The above should be sent to the mailing list at least 2 weeks before -rc2. > + > +rc3 > +~~~ > + > +* Priority: applications. > +* New functionality that does not depend on libs update > + can be integrated as part of -rc3. > +* The app should include documentation in the relevant .rst files > + (app, release notes if significant). > +* Code and related documentation must be updated atomically in the same > patch. > +* Last opportunity for miscellaneous changes. > +* Libs and drivers cleanup. > +* Small driver reworks. > +* Critical and minor bug fixes. > + > +rc4 > +~~~ > + > +* Documentation updates. > +* Critical bug fixes. > -- > 2.30.0 > -- David Marchand
Re: [dpdk-dev] [PATCH v3] doc: update i40e PMD to support on windows
On 2/2/2021 7:09 PM, Pallavi Kadam wrote: Add documentation to support i40e PMD on Windows. Update the release notes and features list for the same. v3 changes: - Replaced the commit link with netuio README.rst documentation link v2 changes: - updated doc/guides/nics/features/i40e.ini file - Replaced the name UIO with NetUIO Signed-off-by: Pallavi Kadam Reviewed-by: Ranjit Menon Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v5 1/1] doc: add release milestones definition
03/02/2021 11:14, David Marchand: > On Wed, Feb 3, 2021 at 8:58 AM Thomas Monjalon wrote: > > +Roadmap > > +~~~ > > + > > +* Content: new features in libraries, drivers, applications, and examples. > > +* Timeframe: to be published before the first day of the release cycle. > > On the form, roadmap announcements can be either a simple mail or a > patch against dpdk-web. I prefer having a mail on dpdk-dev first, because: - it is inviting for discussions - it can explain briefly the changes Opinions?
Re: [dpdk-dev] [PATCH v2 1/3] doc: update release notes for crypto perf script
> -Original Message- > From: Power, Ciara > Sent: Tuesday, 2 February, 2021 17:58 > To: dev@dpdk.org > Cc: akhil.go...@nxp.com; Doherty, Declan ; > Dybkowski, AdamX ; Power, Ciara > > Subject: [PATCH v2 1/3] doc: update release notes for crypto perf script > > Add release note for the new crypto perf graphing script. > > Signed-off-by: Ciara Power Acked-by: Adam Dybkowski
Re: [dpdk-dev] [PATCH v2 2/3] doc: fix crypto perf script guide
> -Original Message-
> From: Power, Ciara
> Sent: Tuesday, 2 February, 2021 17:58
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; Doherty, Declan ;
> Dybkowski, AdamX ; Power, Ciara
>
> Subject: [PATCH v2 2/3] doc: fix crypto perf script guide
>
> The guide for using the crypto perf graphing script had some incorrect
> indentation, unnecessary blank lines, and a missing argument in one of the
> usage examples. These are corrected in this patch.
>
> Fixes: f400e0b82bf1 ("app/crypto-perf: add script to graph perf results")
>
> Signed-off-by: Ciara Power
Acked-by: Adam Dybkowski
Re: [dpdk-dev] [PATCH v2 3/3] test/cryptodev: fix handling for config parameters
> -Original Message-
> From: Power, Ciara
> Sent: Tuesday, 2 February, 2021 17:58
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; Doherty, Declan ;
> Dybkowski, AdamX ; Power, Ciara
>
> Subject: [PATCH v2 3/3] test/cryptodev: fix handling for config parameters
>
> The crypto perf graphing script did not handle parsing parameters from the
> JSON
> config files correctly.
> A common parsing function is used for both EAL and app parameters, to ensure
> they are handled the same way and to reduce code duplication.
> Short parameters are now passed with the value being a second argument,
> rather than as one argument with dividing space.
> Long parameters with no expected value are supported for EAL now also.
> e.g. "--no-huge" can be added to config as "no-huge": true
>
> Fixes: f400e0b82bf1 ("app/crypto-perf: add script to graph perf results")
>
> Signed-off-by: Ciara Power
Acked-by: Adam Dybkowski
[dpdk-dev] [PATCH 1/1] doc: explain steps for improved code spell checking
The script build-dict.sh was added in DPDK 20.08. It generates a better dictionary for spell checking done via checkpatch. Signed-off-by: Thomas Monjalon --- doc/guides/contributing/patches.rst | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index a7346b4cb1..a27e5731a6 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -431,11 +431,15 @@ updating the Linux kernel sources. The path to the original Linux script must be set in the environment variable ``DPDK_CHECKPATCH_PATH``. Spell checking of commonly misspelled words -can be enabled by downloading the codespell dictionary:: +can be enabled with the codespell library:: - https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt + git clone https://github.com/codespell-project/codespell.git -The path to the downloaded ``dictionary.txt`` must be set +There is a DPDK script to build an adjusted dictionary:: + + devtools/build-dict.sh codespell/ > codespell-dpdk.txt + +The path to the dictionary must be set in the environment variable ``DPDK_CHECKPATCH_CODESPELL``. Environment variables required by the development tools, -- 2.30.0
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/sfc: add 8000-series EF10 hardware TSO bug workaround
On 2/2/2021 3:23 PM, Ivan Malov wrote:
Innermost IP length and outer UDP datagram length must be
greater than or equal to the corresponding values derived
from the MSS; otherwise, the checksum offloads will break.
Fixes: c1ce2ba218f8 ("net/sfc: support tunnel TSO on EF10 native Tx datapath")
Fixes: 6bc985e41155 ("net/sfc: support TSO in EF10 Tx datapath")
Fixes: fec33d5bb3eb ("net/sfc: support firmware-assisted TSO")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v3] doc: update i40e PMD to support on windows
On 2/3/2021 10:22 AM, Ferruh Yigit wrote: On 2/2/2021 7:09 PM, Pallavi Kadam wrote: Add documentation to support i40e PMD on Windows. Update the release notes and features list for the same. v3 changes: - Replaced the commit link with netuio README.rst documentation link v2 changes: - updated doc/guides/nics/features/i40e.ini file - Replaced the name UIO with NetUIO Signed-off-by: Pallavi Kadam Reviewed-by: Ranjit Menon Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH 00/17] bugfixes and small functionality for hns3
在 2021/2/3 17:24, Ferruh Yigit 写道: On 2/3/2021 7:46 AM, Lijun Ou wrote: This patch series add some bugfixes and some small functions. In order to fix some bugfixes, we had to do some code rework, for example patch[13/17]. Chengchang Tang (6): net/hns3: support module EEPROM dump net/hns3: add more registers to dump net/hns3: fix stats flip overflow net/hns3: replace all atomic type with C11 atomic builtins net/hns3: fix cmdq cleared during firmware process net/hns3: fix VF reset after MBX failed Chengwen Feng (4): net/hns3: implement cleanup for Tx done net/hns3: constraint TM peak rate net/hns3: remove MPLS type from supported flow items net/hns3: fix FD rule residue in hardware when malloc fail Huisong Li (5): net/hns3: fix query order of link status and link info net/hns3: fix link status change from firmware net/hns3: encapsulate a port shaping interface net/hns3: support PF on electrical net device net/hns3: add check for max pkt length of Rx Lijun Ou (1): net/hns3: fix RSS indirection table size Min Hu (Connor) (1): net/hns3: add enhance stats function Hi Lijun, Is this for next release or current release? We are a day away from the -rc3 and a week (almost) away from the actual release, it is safer to limit the patches to fixes at this stage. If above set is for this release, can you please make a new version to have only fixes, and leave the new supports and refactoring and not important fixes to next release? Yes, I've been aware of our expectations and requirements of each rc. Therefore, we have selected some new support items that have been developed and tested in the roadmap and hope to integrate them in the rc3. Some key bug fixes are expected to be fixed in the current version as soon as possible. Thanks, ferruh .
Re: [dpdk-dev] [PATCH] net/mlx5: check FW miniCQE format capabilities
Hi,
> -Original Message-
> From: Alexander Kozyrev
> Sent: Tuesday, February 2, 2021 4:08 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Raslan Darawsheh ; Slava
> Ovsiienko ; Matan Azrad
> Subject: [PATCH] net/mlx5: check FW miniCQE format capabilities
>
> miniCQE formats for Flow Tag and L3/L4 Header compression are only
> supported by Mellanox FW starting version 16.29.392. There is no
> point to allow user to enable these formats if FW cannot provide them.
> Check FW capabilities and deny user requests if the selected miniCQE
> format is not supported by an underlying NIC.
>
> Cc: sta...@dpdk.org
> Fixes: 54c2d46b16 ("net/mlx5: support flow tag and packet header
> miniCQEs")
>
> Signed-off-by: Alexander Kozyrev
> ---
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH] net/mlx5: fix miniCQE configuration for Verbs
Hi,
> -Original Message-
> From: Alexander Kozyrev
> Sent: Monday, February 1, 2021 7:17 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Raslan Darawsheh ; Slava
> Ovsiienko ; Matan Azrad
> Subject: [PATCH] net/mlx5: fix miniCQE configuration for Verbs
>
> Verbs cannot be used to configure newly introduced miniCQE formats for
> Flow Tag and L3/L4 Header compression. Support for these formats has
> been added to the DevX configuration only. And the RX queue descriptor
> has been updated with the CQE compression format information only as
> well. But the datapath relies on this info no matter which method is
> used for Rx queues configuration. Set proper CQE compression format
> information in the Verbs configuration to fix the miniCQE parsing logic.
>
> Cc: sta...@dpdk.org
> Fixes: 54c2d46b16 ("net/mlx5: support flow tag and packet header
> miniCQEs")
>
> Signed-off-by: Alexander Kozyrev
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH 00/17] bugfixes and small functionality for hns3
On 2/3/2021 11:05 AM, oulijun wrote: 在 2021/2/3 17:24, Ferruh Yigit 写道: On 2/3/2021 7:46 AM, Lijun Ou wrote: This patch series add some bugfixes and some small functions. In order to fix some bugfixes, we had to do some code rework, for example patch[13/17]. Chengchang Tang (6): net/hns3: support module EEPROM dump net/hns3: add more registers to dump net/hns3: fix stats flip overflow net/hns3: replace all atomic type with C11 atomic builtins net/hns3: fix cmdq cleared during firmware process net/hns3: fix VF reset after MBX failed Chengwen Feng (4): net/hns3: implement cleanup for Tx done net/hns3: constraint TM peak rate net/hns3: remove MPLS type from supported flow items net/hns3: fix FD rule residue in hardware when malloc fail Huisong Li (5): net/hns3: fix query order of link status and link info net/hns3: fix link status change from firmware net/hns3: encapsulate a port shaping interface net/hns3: support PF on electrical net device net/hns3: add check for max pkt length of Rx Lijun Ou (1): net/hns3: fix RSS indirection table size Min Hu (Connor) (1): net/hns3: add enhance stats function Hi Lijun, Is this for next release or current release? We are a day away from the -rc3 and a week (almost) away from the actual release, it is safer to limit the patches to fixes at this stage. If above set is for this release, can you please make a new version to have only fixes, and leave the new supports and refactoring and not important fixes to next release? Yes, I've been aware of our expectations and requirements of each rc. Therefore, we have selected some new support items that have been developed and tested in the roadmap and hope to integrate them in the rc3. Some key bug fixes are expected to be fixed in the current version as soon as possible. Still not sure about getting new small functionality in the last day of the -rc3, what do you think get the fixes and push the new functionality to next release? Technically new features should be sent _before_ the proposal deadline, December 20, and we are more flexible for the drivers but there should be a deadline eventually.
Re: [dpdk-dev] [PATCH] examples/vhost: add error propagation in ioat ops
Hi,
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 5:49 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH] examples/vhost: add error propagation in ioat ops
>
>
>
> On 1/31/21 1:36 PM, Cheng Jiang wrote:
> > It makes more sense to add error propagation for rte_ioat_completed_ops.
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > examples/vhost/ioat.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c index
> > dbad28d43..60b73be93 100644
> > --- a/examples/vhost/ioat.c
> > +++ b/examples/vhost/ioat.c
> > @@ -22,7 +22,6 @@ struct packet_tracker {
> >
> > struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
> >
> > -
> > int
> > open_ioat(const char *value)
> > {
> > @@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
> > struct rte_vhost_async_status *opaque_data, uint16_t count)
> {
> > uint32_t i_desc;
> > - int dev_id = dma_bind[vid].dmas[queue_id * 2 +
> VIRTIO_RXQ].dev_id;
> > + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 +
> > +VIRTIO_RXQ].dev_id;
>
> This change from uint16_t to int does not seem related to the purpose of this
> patch. Is it?
Yes, this change has nothing to do with adding the log, I just noticed uint16_t
is more appropriate and changed here.
I can only add the log if you think change the type of dev_id here is not ok.
Thanks.
Cheng
>
> > struct rte_vhost_iov_iter *src = NULL;
> > struct rte_vhost_iov_iter *dst = NULL;
> > unsigned long i_seg;
> > @@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid,
> uint16_t queue_id,
> > unsigned short mask = MAX_ENQUEUED_SIZE - 1;
> > unsigned short i;
> >
> > - int dev_id = dma_bind[vid].dmas[queue_id * 2
> > + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
> > + VIRTIO_RXQ].dev_id;
> > n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
> > - if (n_seg <= 0)
> > + if (n_seg < 0) {
> > + RTE_LOG(ERR,
> > + VHOST_DATA,
> > + "fail to poll completed buf on IOAT
> device %u",
> > + dev_id);
> > + return 0;
> > + }
> > + if (n_seg == 0)
> > return 0;
> >
> > cb_tracker[dev_id].ioat_space += n_seg;
> >
Re: [dpdk-dev] [PATCH 1/2] doc: more info of rte flow shared action
On 2/3/2021 9:02 AM, Asaf Penso wrote: Hi Jack, -Original Message- From: dev On Behalf Of Ori Kam Sent: Wednesday, February 3, 2021 9:51 AM To: Jack Min Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/2] doc: more info of rte flow shared action Hi Jack, -Original Message- From: Jack Min Subject: [PATCH 1/2] doc: more info of rte flow shared action Added more information of shared action on how to update, query, and the benefits. Signed-off-by: Xiaoyu Min Acked-by: Ori Kam Best, Ori Reviewed-by: Asaf Penso Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH 0/2] doc update for rte flow shared action
On 2/2/2021 12:23 PM, Jack Min wrote: This series update documents as following: 1. Add more information about shared action in rte_flow.rst. 2. Group all supported shared actions in mlx5.rst Xiaoyu Min (2): doc: more info of rte flow shared action doc: group mlx5 shared actions Series applied to dpdk-next-net/main, thanks.
Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table
Hi Slava,
Initially v2 of the patch has " instead of ' in the Fixes tags, but it
gave some warnings as wrong quota. So thought of changing it to '. I can change
it back again, do you suggest me to submit v4 with with corrected quota
character or its ok to have the v3 of the patch itself as you have already
acked ?
--
Regards,
Souvik
-Original Message-
From: dev On Behalf Of Slava Ovsiienko
Sent: Wednesday, February 3, 2021 3:04 AM
To: Dey, Souvik ; Raslan Darawsheh ; Matan
Azrad
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to
internal table
NOTICE: This email was received from an EXTERNAL sender.
Hi,
I'm sorry, but quota character in "Fixes" tags is still wrong, causing the
checking script errors.
It should be " (0x22 ASCII), not ' (0x27 ASCII).
Beside this:
Acked-by: Viacheslav Ovsiienko
> -Original Message-
> From: Dey, Souvik
> Sent: Tuesday, February 2, 2021 19:49
> To: Raslan Darawsheh ; Slava Ovsiienko
> ; Matan Azrad ; Shahaf
> Shuler
> Cc: dev@dpdk.org; sta...@dpdk.org; Souvik Dey
> Subject: [PATCH v3] common/mlx5: fix storing the synched MAC to
> internal table
>
> From: Souvik Dey
>
> As the internal MAC table is divided into Unicast and Multicast
> address sections, we should check the type of synched MAC address
> before storing it to the internal table. Currently the check is not
> done, and the synched MAC of
> 33:33:00:00:00:01 gets stored in the unicast section (mostly index 1)
> causing all subsequent mlx5_set_mc_addr_list() to fail with error
> -EADDRINUSE, as the mac_list contains the MAC 33:33:00:00:00:01. This
> denies adding of any new multicast address to the internal list and
> also fails to add the MAC address to the device in case of SR-IOV VF.
>
> Fixes: f22442cb5d42 ('net/mlx5: reduce Netlink commands dependencies')
> Fixes: ccdcba53a3f4 ('net/mlx5: use Netlink to add/remove MAC
> addresses')
> Cc: sta...@dpdk.org
>
> Signed-off-by: Souvik Dey
> ---
> v2:
> * net/ -> common/
> * space after mlx5:
> * synched -> synched
> * section -> sections
> * rewording which causes -> causing
> * typo: case (to remove)
> * added Fixes for LTS ML
> ---
> v3:
> * Changed the "" in Fixes tags to ''.
> ---
> drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/common/mlx5/linux/mlx5_nl.c
> b/drivers/common/mlx5/linux/mlx5_nl.c
> index 40d8620..ef7a521 100644
> --- a/drivers/common/mlx5/linux/mlx5_nl.c
> +++ b/drivers/common/mlx5/linux/mlx5_nl.c
> @@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned int
> iface_idx,
> break;
> if (j != n)
> continue;
> - /* Find the first entry available. */
> - for (j = 0; j != n; ++j) {
> - if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> - mac_addrs[j] = macs[i];
> - break;
> + if (rte_is_multicast_ether_addr(&macs[i])) {
> + /* Find the first entry available. */
> + for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
> + }
> + } else {
> + /* Find the first entry available. */
> + for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j)
> {
> + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> + mac_addrs[j] = macs[i];
> + break;
> + }
> }
> }
> }
> --
> 2.9.3.windows.1
>
>
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
Hi,
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 5:52 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
> counter
>
>
>
> On 2/2/21 7:17 AM, Cheng Jiang wrote:
> > Remove async inflight packet counter since there is no need to keep
> > tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment
> > number tracking ring from being exhausted.
>
> Is that an optimization or a fix?
>
> If the former, let's move it to v21.05.
>
I think it's a fix since there is no need to keep the inflight packet counter,
sorry I forget adding the fixes, I can submit a v4 to fix it.
> >
> > Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > v3: fixed fixes commit id in git log
> >
> > v2: fixed a typo
> >
> > examples/vhost/ioat.h | 2 +-
> > examples/vhost/main.c | 10 +- examples/vhost/main.h | 1 -
> > 3 files changed, 2 insertions(+), 11 deletions(-)
> >
> > diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index
> > 0a1dbb811..1aa28ed6a 100644
> > --- a/examples/vhost/ioat.h
> > +++ b/examples/vhost/ioat.h
> > @@ -11,7 +11,7 @@
> >
> > #define MAX_VHOST_DEVICE 1024
> > #define IOAT_RING_SIZE 4096
> > -#define MAX_ENQUEUED_SIZE 512
> > +#define MAX_ENQUEUED_SIZE 4096
>
> Basically, this the size of the ring size, correct?
> It might be further simplified then.
>
Yes, it's a the size of packet tracking ring, and it should be no less then
IOAT_RING_SIZE for some corner cases.
I'm not sure I understand what you mean by saying It might be further
simplified then.
Thanks,
Cheng
> >
> > struct dma_info {
> > struct rte_pci_addr addr;
> > diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
> > e74fc8750..ca73e7086 100644
> > --- a/examples/vhost/main.c
> > +++ b/examples/vhost/main.c
> > @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev)
> >
> > complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
> > VIRTIO_RXQ, p_cpl,
> MAX_PKT_BURST);
> > - if (complete_count) {
> > - __atomic_sub_fetch(&vdev->nr_async_pkts,
> complete_count,
> > - __ATOMIC_SEQ_CST);
> > + if (complete_count)
> > free_pkts(p_cpl, complete_count);
> > - }
> > }
> >
> > static __rte_always_inline void
> > @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
> > complete_async_pkts(vdev);
> > ret = rte_vhost_submit_enqueue_burst(vdev->vid,
> VIRTIO_RXQ,
> > m, nr_xmit, m_cpu_cpl,
> &cpu_cpl_nr);
> > - __atomic_add_fetch(&vdev->nr_async_pkts, ret -
> cpu_cpl_nr,
> > - __ATOMIC_SEQ_CST);
> >
> > if (cpu_cpl_nr)
> > free_pkts(m_cpu_cpl, cpu_cpl_nr);
> > @@ -1210,9 +1205,6 @@ drain_eth_rx(struct vhost_dev *vdev)
> > enqueue_count = rte_vhost_submit_enqueue_burst(vdev-
> >vid,
> > VIRTIO_RXQ, pkts, rx_count,
> > m_cpu_cpl, &cpu_cpl_nr);
> > - __atomic_add_fetch(&vdev->nr_async_pkts,
> > - enqueue_count - cpu_cpl_nr,
> > - __ATOMIC_SEQ_CST);
> > if (cpu_cpl_nr)
> > free_pkts(m_cpu_cpl, cpu_cpl_nr);
> >
> > diff --git a/examples/vhost/main.h b/examples/vhost/main.h index
> > 2d6c05fd7..0ccdce4b4 100644
> > --- a/examples/vhost/main.h
> > +++ b/examples/vhost/main.h
> > @@ -51,7 +51,6 @@ struct vhost_dev {
> > uint64_t features;
> > size_t hdr_len;
> > uint16_t nr_vrings;
> > - uint64_t nr_async_pkts;
> > struct rte_vhost_memory *mem;
> > struct device_statistics stats;
> > TAILQ_ENTRY(vhost_dev) global_vdev_entry;
> > --
> > 2.29.2
> >
Re: [dpdk-dev] [PATCH 1/1] doc: explain steps for improved code spell checking
On Wed, Feb 03, 2021 at 11:30:57AM +0100, Thomas Monjalon wrote: > The script build-dict.sh was added in DPDK 20.08. > It generates a better dictionary for spell checking > done via checkpatch. > > Signed-off-by: Thomas Monjalon > --- > doc/guides/contributing/patches.rst | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/doc/guides/contributing/patches.rst > b/doc/guides/contributing/patches.rst > index a7346b4cb1..a27e5731a6 100644 > --- a/doc/guides/contributing/patches.rst > +++ b/doc/guides/contributing/patches.rst > @@ -431,11 +431,15 @@ updating the Linux kernel sources. > The path to the original Linux script must be set in the environment > variable ``DPDK_CHECKPATCH_PATH``. > > Spell checking of commonly misspelled words > -can be enabled by downloading the codespell dictionary:: > +can be enabled with the codespell library:: > > - > https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt > + git clone https://github.com/codespell-project/codespell.git > Does installing via apt or dnf work as well? If we do install from package do we still need to specify the path to codespell as script parameter? > -The path to the downloaded ``dictionary.txt`` must be set > +There is a DPDK script to build an adjusted dictionary:: > + > + devtools/build-dict.sh codespell/ > codespell-dpdk.txt > + Do we always need to have people build this themselves? Can we create a .codespell-dpdk.txt file in the repo and have that as the default value for the path if the environment variable is not set? > +The path to the dictionary must be set > in the environment variable ``DPDK_CHECKPATCH_CODESPELL``. > > Environment variables required by the development tools, > -- > 2.30.0 >
Re: [dpdk-dev] [PATCH 00/17] bugfixes and small functionality for hns3
在 2021/2/3 19:46, Ferruh Yigit 写道: On 2/3/2021 11:05 AM, oulijun wrote: 在 2021/2/3 17:24, Ferruh Yigit 写道: On 2/3/2021 7:46 AM, Lijun Ou wrote: This patch series add some bugfixes and some small functions. In order to fix some bugfixes, we had to do some code rework, for example patch[13/17]. Chengchang Tang (6): net/hns3: support module EEPROM dump net/hns3: add more registers to dump net/hns3: fix stats flip overflow net/hns3: replace all atomic type with C11 atomic builtins net/hns3: fix cmdq cleared during firmware process net/hns3: fix VF reset after MBX failed Chengwen Feng (4): net/hns3: implement cleanup for Tx done net/hns3: constraint TM peak rate net/hns3: remove MPLS type from supported flow items net/hns3: fix FD rule residue in hardware when malloc fail Huisong Li (5): net/hns3: fix query order of link status and link info net/hns3: fix link status change from firmware net/hns3: encapsulate a port shaping interface net/hns3: support PF on electrical net device net/hns3: add check for max pkt length of Rx Lijun Ou (1): net/hns3: fix RSS indirection table size Min Hu (Connor) (1): net/hns3: add enhance stats function Hi Lijun, Is this for next release or current release? We are a day away from the -rc3 and a week (almost) away from the actual release, it is safer to limit the patches to fixes at this stage. If above set is for this release, can you please make a new version to have only fixes, and leave the new supports and refactoring and not important fixes to next release? Yes, I've been aware of our expectations and requirements of each rc. Therefore, we have selected some new support items that have been developed and tested in the roadmap and hope to integrate them in the rc3. Some key bug fixes are expected to be fixed in the current version as soon as possible. Still not sure about getting new small functionality in the last day of the -rc3, what do you think get the fixes and push the new functionality to next release? Thanks， I see. Technically new features should be sent _before_ the proposal deadline, December 20, and we are more flexible for the drivers but there should be a deadline eventually. .
[dpdk-dev] [PATCH 01/11] net/hns3: fix query order of link status and link info
From: Huisong Li
When link information is updated in the firmware, the link information
is updated first and then the link status is updated. In a 1s periodic
task, PF driver queries the link information and then obtains link status.
It may lead to a 1s time difference for obtaining valid link information
when the port is up. Therefore, the query order of driver should be
reversed to the order of firmware.
Fixes: 109e4dd1bd7a ("net/hns3: get link state change through mailbox")
Fixes: 59fad0f32135 ("net/hns3: support link update operation")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_ethdev.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 221e008..8c57b63 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -93,7 +93,7 @@ static enum hns3_reset_level hns3_get_reset_level(struct
hns3_adapter *hns,
static int hns3_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int hns3_vlan_pvid_configure(struct hns3_adapter *hns, uint16_t pvid,
int on);
-static int hns3_update_speed_duplex(struct rte_eth_dev *eth_dev);
+static int hns3_update_link_info(struct rte_eth_dev *eth_dev);
static bool hns3_update_link_status(struct hns3_hw *hw);
static int hns3_add_mc_addr(struct hns3_hw *hw,
@@ -2642,8 +2642,8 @@ hns3_dev_link_update(struct rte_eth_dev *eth_dev,
struct rte_eth_link new_link;
if (!hns3_is_reset_pending(hns)) {
- hns3_update_speed_duplex(eth_dev);
hns3_update_link_status(hw);
+ hns3_update_link_info(eth_dev);
}
memset(&new_link, 0, sizeof(new_link));
@@ -4368,11 +4368,9 @@ hns3_cfg_mac_speed_dup(struct hns3_hw *hw, uint32_t
speed, uint8_t duplex)
}
static int
-hns3_update_speed_duplex(struct rte_eth_dev *eth_dev)
+hns3_update_fiber_link_info(struct hns3_hw *hw)
{
- struct hns3_adapter *hns = eth_dev->data->dev_private;
- struct hns3_hw *hw = &hns->hw;
- struct hns3_pf *pf = &hns->pf;
+ struct hns3_pf *pf = HNS3_DEV_HW_TO_PF(hw);
uint32_t speed;
int ret;
@@ -4395,6 +4393,21 @@ hns3_update_speed_duplex(struct rte_eth_dev *eth_dev)
}
static int
+hns3_update_link_info(struct rte_eth_dev *eth_dev)
+{
+ struct hns3_adapter *hns = eth_dev->data->dev_private;
+ struct hns3_hw *hw = &hns->hw;
+ int ret = 0;
+
+ if (hw->mac.media_type == HNS3_MEDIA_TYPE_COPPER)
+ return 0;
+ else if (hw->mac.media_type == HNS3_MEDIA_TYPE_FIBER)
+ ret = hns3_update_fiber_link_info(hw);
+
+ return ret;
+}
+
+static int
hns3_cfg_mac_mode(struct hns3_hw *hw, bool enable)
{
struct hns3_config_mac_mode_cmd *req;
@@ -4509,8 +4522,8 @@ hns3_service_handler(void *param)
struct hns3_hw *hw = &hns->hw;
if (!hns3_is_reset_pending(hns)) {
- hns3_update_speed_duplex(eth_dev);
hns3_update_link_status_and_event(hw);
+ hns3_update_link_info(eth_dev);
} else {
hns3_warn(hw, "Cancel the query when reset is pending");
}
--
2.7.4
[dpdk-dev] [PATCH 00/11] critical bugfixes for hns3
Based on some suggestions, we reorganize the fixes and resend the only fixes. Chengchang Tang (4): net/hns3: fix stats flip overflow net/hns3: replace all atomic type with C11 atomic builtins net/hns3: fix cmdq cleared during firmware process net/hns3: fix VF reset after MBX failed Chengwen Feng (3): net/hns3: constraint TM peak rate net/hns3: remove MPLS type from supported flow items net/hns3: fix FD rule residue in hardware when malloc fail Huisong Li (3): net/hns3: fix query order of link status and link info net/hns3: fix link status change from firmware net/hns3: add check for max pkt length of Rx Lijun Ou (1): net/hns3: fix RSS indirection table size drivers/net/hns3/hns3_cmd.c | 36 ++-- drivers/net/hns3/hns3_cmd.h | 18 +- drivers/net/hns3/hns3_dcb.c | 2 +- drivers/net/hns3/hns3_ethdev.c| 116 ++ drivers/net/hns3/hns3_ethdev.h| 4 +- drivers/net/hns3/hns3_ethdev_vf.c | 62 ++-- drivers/net/hns3/hns3_flow.c | 36 ++-- drivers/net/hns3/hns3_intr.c | 22 +--- drivers/net/hns3/hns3_mbx.c | 4 +- drivers/net/hns3/hns3_rss.c | 28 - drivers/net/hns3/hns3_rss.h | 5 +- drivers/net/hns3/hns3_stats.c | 21 +-- drivers/net/hns3/hns3_tm.c| 6 ++ 13 files changed, 258 insertions(+), 102 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH 03/11] net/hns3: fix RSS indirection table size
the driver should not use the fixed value as the validity check of
RSS indirection table size with HW supported. As a result, it will
cause misjudgment when the RSS reta size with HW supported have
changed.
Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_cmd.c | 11 +++
drivers/net/hns3/hns3_cmd.h | 7 ++-
drivers/net/hns3/hns3_dcb.c | 2 +-
drivers/net/hns3/hns3_ethdev.c| 18 --
drivers/net/hns3/hns3_ethdev_vf.c | 18 --
drivers/net/hns3/hns3_flow.c | 6 +++---
drivers/net/hns3/hns3_rss.c | 28 ++--
drivers/net/hns3/hns3_rss.h | 5 ++---
8 files changed, 69 insertions(+), 26 deletions(-)
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 9ed8161..b750022 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -430,6 +430,16 @@ static void hns3_parse_capability(struct hns3_hw *hw,
hns3_set_bit(hw->capability, HNS3_DEV_SUPPORT_STASH_B, 1);
}
+static uint32_t
+hns3_build_api_caps(void)
+{
+ uint32_t api_caps = 0;
+
+ hns3_set_bit(api_caps, HNS3_API_CAP_FLEX_RSS_TBL_B, 1);
+
+ return rte_cpu_to_le_32(api_caps);
+}
+
static enum hns3_cmd_status
hns3_cmd_query_firmware_version_and_capability(struct hns3_hw *hw)
{
@@ -439,6 +449,7 @@ hns3_cmd_query_firmware_version_and_capability(struct
hns3_hw *hw)
hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_QUERY_FW_VER, 1);
resp = (struct hns3_query_version_cmd *)desc.data;
+ resp->api_caps = hns3_build_api_caps();
/* Initialize the cmd function */
ret = hns3_cmd_send(hw, &desc, 1);
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index ad5e188..5640fe4 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -295,11 +295,16 @@ enum HNS3_CAPS_BITS {
HNS3_CAPS_HW_PAD_B,
HNS3_CAPS_STASH_B,
};
+
+enum HNS3_API_CAP_BITS {
+ HNS3_API_CAP_FLEX_RSS_TBL_B,
+};
+
#define HNS3_QUERY_CAP_LENGTH 3
struct hns3_query_version_cmd {
uint32_t firmware;
uint32_t hardware;
- uint32_t rsv;
+ uint32_t api_caps;
uint32_t caps[HNS3_QUERY_CAP_LENGTH]; /* capabilities of device */
};
diff --git a/drivers/net/hns3/hns3_dcb.c b/drivers/net/hns3/hns3_dcb.c
index 5aa374c..7fc6ac9 100644
--- a/drivers/net/hns3/hns3_dcb.c
+++ b/drivers/net/hns3/hns3_dcb.c
@@ -644,7 +644,7 @@ hns3_set_rss_size(struct hns3_hw *hw, uint16_t nb_rx_q)
* stage of the reset process.
*/
if (__atomic_load_n(&hw->reset.resetting, __ATOMIC_RELAXED) == 0) {
- for (i = 0; i < HNS3_RSS_IND_TBL_SIZE; i++)
+ for (i = 0; i < hw->rss_ind_tbl_size; i++)
rss_cfg->rss_indirection_tbl[i] =
i % hw->alloc_rss_size;
}
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index f93870d..c0ab3fc 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2593,7 +2593,7 @@ hns3_dev_infos_get(struct rte_eth_dev *eth_dev, struct
rte_eth_dev_info *info)
info->vmdq_queue_num = 0;
- info->reta_size = HNS3_RSS_IND_TBL_SIZE;
+ info->reta_size = hw->rss_ind_tbl_size;
info->hash_key_size = HNS3_RSS_KEY_SIZE;
info->flow_type_rss_offloads = HNS3_ETH_RSS_SUPPORT;
@@ -2984,6 +2984,20 @@ hns3_parse_dev_specifications(struct hns3_hw *hw, struct
hns3_cmd_desc *desc)
}
static int
+hns3_check_dev_specifications(struct hns3_hw *hw)
+{
+ if (hw->rss_ind_tbl_size == 0 ||
+ hw->rss_ind_tbl_size > HNS3_RSS_IND_TBL_SIZE_MAX) {
+ hns3_err(hw, "the size of hash lookup table configured (%u)"
+ " exceeds the maximum(%u)", hw->rss_ind_tbl_size,
+ HNS3_RSS_IND_TBL_SIZE_MAX);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
hns3_query_dev_specifications(struct hns3_hw *hw)
{
struct hns3_cmd_desc desc[HNS3_QUERY_DEV_SPECS_BD_NUM];
@@ -3003,7 +3017,7 @@ hns3_query_dev_specifications(struct hns3_hw *hw)
hns3_parse_dev_specifications(hw, desc);
- return 0;
+ return hns3_check_dev_specifications(hw);
}
static int
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index faf7e01..2446574 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1016,7 +1016,7 @@ hns3vf_dev_infos_get(struct rte_eth_dev *eth_dev, struct
rte_eth_dev_info *info)
info->vmdq_queue_num = 0;
- info->reta_size = HNS3_RSS_IND_TBL_SIZE;
+ info->reta_size = hw->rss_ind_tbl_size;
info->hash_key_size = HNS3_RSS_KEY_SIZE;
info->flow_type_rss_offloads = HNS3_ETH_RSS_SUPPORT;
info->default_rxportconf.ri
[dpdk-dev] [PATCH 02/11] net/hns3: fix link status change from firmware
From: Huisong Li
When the hardware link status changes, the firmware proactively
reports the link status change message, and then driver update
link status. This feature is lack of a switch to control in pf
driver. Otherwise, this feature does not take effect when the
kernel PF driver that supports the feature is not loaded.
Fixes: 109e4dd1bd7a ("net/hns3: get link state change through mailbox")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_cmd.h| 10 ++
drivers/net/hns3/hns3_ethdev.c | 31 +++
2 files changed, 41 insertions(+)
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index dc97a1a..ad5e188 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -206,6 +206,9 @@ enum hns3_opcode_type {
/* Clear hardware state command */
HNS3_OPC_CLEAR_HW_STATE = 0x700B,
+ /* Firmware stats command */
+ HNS3_OPC_FIRMWARE_COMPAT_CFG= 0x701A,
+
/* SFP command */
HNS3_OPC_SFP_GET_SPEED = 0x7104,
@@ -633,6 +636,13 @@ enum hns3_promisc_type {
HNS3_BROADCAST = 3,
};
+#define HNS3_LINK_EVENT_REPORT_EN_B0
+#define HNS3_NCSI_ERROR_REPORT_EN_B1
+struct hns3_firmware_compat_cmd {
+ uint32_t compat;
+ uint8_t rsv[20];
+};
+
#define HNS3_MAC_TX_EN_B 6
#define HNS3_MAC_RX_EN_B 7
#define HNS3_MAC_PAD_TX_B 11
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 8c57b63..f93870d 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -3919,6 +3919,26 @@ hns3_buffer_alloc(struct hns3_hw *hw)
}
static int
+hns3_firmware_compat_config(struct hns3_hw *hw, bool is_init)
+{
+ struct hns3_firmware_compat_cmd *req;
+ struct hns3_cmd_desc desc;
+ uint32_t compat = 0;
+
+ hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_FIRMWARE_COMPAT_CFG, false);
+ req = (struct hns3_firmware_compat_cmd *)desc.data;
+
+ if (is_init) {
+ hns3_set_bit(compat, HNS3_LINK_EVENT_REPORT_EN_B, 1);
+ hns3_set_bit(compat, HNS3_NCSI_ERROR_REPORT_EN_B, 0);
+ }
+
+ req->compat = rte_cpu_to_le_32(compat);
+
+ return hns3_cmd_send(hw, &desc, 1);
+}
+
+static int
hns3_mac_init(struct hns3_hw *hw)
{
struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
@@ -4610,6 +4630,15 @@ hns3_init_hardware(struct hns3_adapter *hns)
goto err_mac_init;
}
+ /*
+* Requiring firmware to enable some features, driver can
+* still work without it.
+*/
+ ret = hns3_firmware_compat_config(hw, true);
+ if (ret)
+ PMD_INIT_LOG(WARNING, "firmware compatible features not "
+"supported, ret = %d.", ret);
+
return 0;
err_mac_init:
@@ -4746,6 +4775,7 @@ hns3_init_pf(struct rte_eth_dev *eth_dev)
err_enable_intr:
hns3_fdir_filter_uninit(hns);
err_fdir:
+ (void)hns3_firmware_compat_config(hw, false);
hns3_uninit_umv_space(hw);
err_init_hw:
hns3_tqp_stats_uninit(hw);
@@ -4780,6 +4810,7 @@ hns3_uninit_pf(struct rte_eth_dev *eth_dev)
(void)hns3_config_gro(hw, false);
hns3_promisc_uninit(hw);
hns3_fdir_filter_uninit(hns);
+ (void)hns3_firmware_compat_config(hw, false);
hns3_uninit_umv_space(hw);
hns3_tqp_stats_uninit(hw);
hns3_pf_disable_irq0(hw);
--
2.7.4
[dpdk-dev] [PATCH 11/11] net/hns3: add check for max pkt length of Rx
From: Huisong Li
When jumbo frame is enabled, the MTU size needs to be modified
based on 'max_rx_pkt_len'. Driver needs to check the validity
of 'max_rx_pkt_len'. And it should be in the range of
HNS3_DEFAULT_FRAME_LEN and HNS3_MAX_FRAME_LEN. Otherwise, it may
cause that the MTU size is inconsistent with jumbo frame offload.
Fixes: 19a3ca4c99cf ("net/hns3: add start/stop and configure operations")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_ethdev.c| 19 +--
drivers/net/hns3/hns3_ethdev_vf.c | 19 +--
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index a7ae8f8..dbd48de 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2343,6 +2343,7 @@ hns3_dev_configure(struct rte_eth_dev *dev)
uint16_t nb_rx_q = dev->data->nb_rx_queues;
uint16_t nb_tx_q = dev->data->nb_tx_queues;
struct rte_eth_rss_conf rss_conf;
+ uint32_t max_rx_pkt_len;
uint16_t mtu;
bool gro_en;
int ret;
@@ -2396,12 +2397,18 @@ hns3_dev_configure(struct rte_eth_dev *dev)
* according to the maximum RX packet length.
*/
if (conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {
- /*
-* Security of max_rx_pkt_len is guaranteed in dpdk frame.
-* Maximum value of max_rx_pkt_len is HNS3_MAX_FRAME_LEN, so it
-* can safely assign to "uint16_t" type variable.
-*/
- mtu = (uint16_t)HNS3_PKTLEN_TO_MTU(conf->rxmode.max_rx_pkt_len);
+ max_rx_pkt_len = conf->rxmode.max_rx_pkt_len;
+ if (max_rx_pkt_len > HNS3_MAX_FRAME_LEN ||
+ max_rx_pkt_len <= HNS3_DEFAULT_FRAME_LEN) {
+ hns3_err(hw, "maximum Rx packet length must be greater "
+"than %u and less than %u when jumbo frame
enabled.",
+(uint16_t)HNS3_DEFAULT_FRAME_LEN,
+(uint16_t)HNS3_MAX_FRAME_LEN);
+ ret = -EINVAL;
+ goto cfg_err;
+ }
+
+ mtu = (uint16_t)HNS3_PKTLEN_TO_MTU(max_rx_pkt_len);
ret = hns3_dev_mtu_set(dev, mtu);
if (ret)
goto cfg_err;
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index a607bd3..3f9f328 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -778,6 +778,7 @@ hns3vf_dev_configure(struct rte_eth_dev *dev)
uint16_t nb_rx_q = dev->data->nb_rx_queues;
uint16_t nb_tx_q = dev->data->nb_tx_queues;
struct rte_eth_rss_conf rss_conf;
+ uint32_t max_rx_pkt_len;
uint16_t mtu;
bool gro_en;
int ret;
@@ -825,12 +826,18 @@ hns3vf_dev_configure(struct rte_eth_dev *dev)
* according to the maximum RX packet length.
*/
if (conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) {
- /*
-* Security of max_rx_pkt_len is guaranteed in dpdk frame.
-* Maximum value of max_rx_pkt_len is HNS3_MAX_FRAME_LEN, so it
-* can safely assign to "uint16_t" type variable.
-*/
- mtu = (uint16_t)HNS3_PKTLEN_TO_MTU(conf->rxmode.max_rx_pkt_len);
+ max_rx_pkt_len = conf->rxmode.max_rx_pkt_len;
+ if (max_rx_pkt_len > HNS3_MAX_FRAME_LEN ||
+ max_rx_pkt_len <= HNS3_DEFAULT_FRAME_LEN) {
+ hns3_err(hw, "maximum Rx packet length must be greater "
+"than %u and less than %u when jumbo frame
enabled.",
+(uint16_t)HNS3_DEFAULT_FRAME_LEN,
+(uint16_t)HNS3_MAX_FRAME_LEN);
+ ret = -EINVAL;
+ goto cfg_err;
+ }
+
+ mtu = (uint16_t)HNS3_PKTLEN_TO_MTU(max_rx_pkt_len);
ret = hns3vf_dev_mtu_set(dev, mtu);
if (ret)
goto cfg_err;
--
2.7.4
[dpdk-dev] [PATCH 06/11] net/hns3: fix stats flip overflow
From: Chengchang Tang
Currently, statistics may overflow in some scenarios.
For example, if HW statistics are reset by stats reset operation,
but there are still a lot of residual packets exist in the HW
queues and these packets are error packets, flip may occurred
because the ipacket is obtained by subtracting the number of
software error packets from the number of HW received packets.
This patch verifies the calculation and returns 0 when overflow
may occur.
Fixes: 8839c5e202f3 ("net/hns3: support device stats")
Cc: sta...@dpdk.org
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_stats.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hns3/hns3_stats.c b/drivers/net/hns3/hns3_stats.c
index 3ba09e2..e0e40ca 100644
--- a/drivers/net/hns3/hns3_stats.c
+++ b/drivers/net/hns3/hns3_stats.c
@@ -554,8 +554,14 @@ hns3_stats_get(struct rte_eth_dev *eth_dev, struct
rte_eth_stats *rte_stats)
}
rte_stats->oerrors = 0;
- rte_stats->ipackets = stats->rcb_rx_ring_pktnum_rcd -
- rte_stats->ierrors;
+ /*
+* If HW statistics are reset by stats_reset, but a lot of residual
+* packets exist in the hardware queue and these packets are error
+* packets, flip overflow may occurred. So return 0 in this case.
+*/
+ rte_stats->ipackets =
+ stats->rcb_rx_ring_pktnum_rcd > rte_stats->ierrors ?
+ stats->rcb_rx_ring_pktnum_rcd - rte_stats->ierrors : 0;
rte_stats->opackets = stats->rcb_tx_ring_pktnum_rcd -
rte_stats->oerrors;
rte_stats->rx_nombuf = eth_dev->data->rx_mbuf_alloc_failed;
@@ -792,8 +798,15 @@ hns3_rxq_basic_stats_get(struct rte_eth_dev *dev, struct
rte_eth_xstat *xstats,
rxq_stats = &rxq->basic_stats;
rxq_stats->errors = rxq->err_stats.l2_errors +
rxq->err_stats.pkt_len_errors;
- rxq_stats->packets = stats->rcb_rx_ring_pktnum[i] -
- rxq_stats->errors;
+ /*
+* If HW statistics are reset by stats_reset, but a lot of
+* residual packets exist in the hardware queue and these
+* packets are error packets, flip overflow may occurred.
+* So return 0 in this case.
+*/
+ rxq_stats->packets =
+ stats->rcb_rx_ring_pktnum[i] > rxq_stats->errors ?
+ stats->rcb_rx_ring_pktnum[i] - rxq_stats->errors : 0;
rxq_stats->bytes = 0;
for (j = 0; j < HNS3_NUM_RXQ_BASIC_STATS; j++) {
val = (char *)rxq_stats +
--
2.7.4
[dpdk-dev] [PATCH 10/11] net/hns3: fix VF reset after MBX failed
From: Chengchang Tang
Currently, during the VF reset, the VF will send a MBX to inform
PF to reset it and the disable command bit will be set whether
the MBX is successful. Generally, multiple reset attempts are made
after a failure. However, because the command is disabled, all
subsequent reset will all fail.
This patch disable the command only after the MBX message is
successfully.
Fixes: 2790c6464725 ("net/hns3: support device reset")
Cc: sta...@dpdk.org
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_ethdev_vf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index 4f9da4a..a607bd3 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -2404,15 +2404,17 @@ static int
hns3vf_prepare_reset(struct hns3_adapter *hns)
{
struct hns3_hw *hw = &hns->hw;
- int ret = 0;
+ int ret;
if (hw->reset.level == HNS3_VF_FUNC_RESET) {
ret = hns3_send_mbx_msg(hw, HNS3_MBX_RESET, 0, NULL,
0, true, NULL, 0);
+ if (ret)
+ return ret;
}
__atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
- return ret;
+ return 0;
}
static int
--
2.7.4
[dpdk-dev] [PATCH 04/11] net/hns3: constraint TM peak rate
From: Chengwen Feng
User could config Port or TC's peak rate by TM ops, but hardware does
not support peak rate which lower than 1Mbps. So we constraint tm
peak rate must be at least 1Mbps.
Fixes: c09c7847d892 ("net/hns3: support traffic management")
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_tm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/hns3/hns3_tm.c b/drivers/net/hns3/hns3_tm.c
index d1639d4..bcae57a 100644
--- a/drivers/net/hns3/hns3_tm.c
+++ b/drivers/net/hns3/hns3_tm.c
@@ -200,6 +200,12 @@ hns3_tm_shaper_profile_param_check(struct rte_eth_dev *dev,
return -EINVAL;
}
+ if (profile->peak.rate < hns3_tm_rate_convert_firmware2tm(1)) {
+ error->type = RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PEAK_RATE;
+ error->message = "peak rate must be at least 1Mbps";
+ return -EINVAL;
+ }
+
if (profile->peak.size) {
error->type = RTE_TM_ERROR_TYPE_SHAPER_PROFILE_PEAK_SIZE;
error->message = "peak bucket size not supported";
--
2.7.4
[dpdk-dev] [PATCH 05/11] net/hns3: remove MPLS type from supported flow items
From: Chengwen Feng
The Kunpeng920 and Kunpeng930 don't support parse MPLS packet, so
remove the type from supported flow items.
Fixes: fcba820d9b9e ("net/hns3: support flow director")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_flow.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index a601124..c484114 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -44,8 +44,7 @@ static enum rte_flow_item_type first_items[] = {
RTE_FLOW_ITEM_TYPE_NVGRE,
RTE_FLOW_ITEM_TYPE_VXLAN,
RTE_FLOW_ITEM_TYPE_GENEVE,
- RTE_FLOW_ITEM_TYPE_VXLAN_GPE,
- RTE_FLOW_ITEM_TYPE_MPLS
+ RTE_FLOW_ITEM_TYPE_VXLAN_GPE
};
static enum rte_flow_item_type L2_next_items[] = {
@@ -65,8 +64,7 @@ static enum rte_flow_item_type L3_next_items[] = {
static enum rte_flow_item_type L4_next_items[] = {
RTE_FLOW_ITEM_TYPE_VXLAN,
RTE_FLOW_ITEM_TYPE_GENEVE,
- RTE_FLOW_ITEM_TYPE_VXLAN_GPE,
- RTE_FLOW_ITEM_TYPE_MPLS
+ RTE_FLOW_ITEM_TYPE_VXLAN_GPE
};
static enum rte_flow_item_type tunnel_next_items[] = {
@@ -1118,8 +1116,7 @@ is_tunnel_packet(enum rte_flow_item_type type)
if (type == RTE_FLOW_ITEM_TYPE_VXLAN_GPE ||
type == RTE_FLOW_ITEM_TYPE_VXLAN ||
type == RTE_FLOW_ITEM_TYPE_NVGRE ||
- type == RTE_FLOW_ITEM_TYPE_GENEVE ||
- type == RTE_FLOW_ITEM_TYPE_MPLS)
+ type == RTE_FLOW_ITEM_TYPE_GENEVE)
return true;
return false;
}
--
2.7.4
[dpdk-dev] [PATCH 09/11] net/hns3: fix cmdq cleared during firmware process
From: Chengchang Tang
There are two scenarios that command queue uninit performed
concurrently with the firmware command: asynchronous command
and timeout command.
For asynchronous command, if a large number of functions send
commands, these commands may need to be queued to wait for
firmware processing. If a function is uninited suddenly, CMDQ
clearing and firmware processing may be performed concurrently.
For timeout command, if the command failed due to busy scheduling
of firmware, this command will be processed in the next scheduling.
And this may lead to concurrency.
The preceding concurrency may lead to a firmware exceptions.
This patch add a waiting time to ensure the firmware complete the
processing of left over command when PMD uninit.
Fixes: 737f30e1c3ab ("net/hns3: support command interface with firmware")
Cc: sta...@dpdk.org
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_cmd.c | 14 +-
drivers/net/hns3/hns3_cmd.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index 3d6ffc0..32cd56b 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -582,9 +582,21 @@ hns3_cmd_destroy_queue(struct hns3_hw *hw)
void
hns3_cmd_uninit(struct hns3_hw *hw)
{
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
+
+ /*
+* A delay is added to ensure that the register cleanup operations
+* will not be performed concurrently with the firmware command and
+* ensure that all the reserved commands are executed.
+* Concurrency may occur in two scenarios: asynchronous command and
+* timeout command. If the command fails to be executed due to busy
+* scheduling, the command will be processed in the next scheduling
+* of the firmware.
+*/
+ rte_delay_ms(HNS3_CMDQ_CLEAR_WAIT_TIME);
+
rte_spinlock_lock(&hw->cmq.csq.lock);
rte_spinlock_lock(&hw->cmq.crq.lock);
- __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
hns3_cmd_clear_regs(hw);
rte_spinlock_unlock(&hw->cmq.crq.lock);
rte_spinlock_unlock(&hw->cmq.csq.lock);
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index 5640fe4..5010278 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -8,6 +8,7 @@
#include
#define HNS3_CMDQ_TX_TIMEOUT 3
+#define HNS3_CMDQ_CLEAR_WAIT_TIME 200
#define HNS3_CMDQ_RX_INVLD_B 0
#define HNS3_CMDQ_RX_OUTVLD_B 1
#define HNS3_CMD_DESC_ALIGNMENT4096
--
2.7.4
[dpdk-dev] [PATCH 08/11] net/hns3: fix FD rule residue in hardware when malloc fail
From: Chengwen Feng
After FD rule config success, driver will malloc fdir_rule to hold the
rule info, if malloc fail the FD rule in hardware was not cleanup.
Fixes: fcba820d9b9e ("net/hns3: support flow director")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_flow.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index c484114..a016857 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1806,17 +1806,18 @@ hns3_flow_create(struct rte_eth_dev *dev, const struct
rte_flow_attr *attr,
flow->counter_id = fdir_rule.act_cnt.id;
}
+
+ fdir_rule_ptr = rte_zmalloc("hns3 fdir rule",
+ sizeof(struct hns3_fdir_rule_ele),
+ 0);
+ if (fdir_rule_ptr == NULL) {
+ hns3_err(hw, "failed to allocate fdir_rule memory.");
+ ret = -ENOMEM;
+ goto err_fdir;
+ }
+
ret = hns3_fdir_filter_program(hns, &fdir_rule, false);
if (!ret) {
- fdir_rule_ptr = rte_zmalloc("hns3 fdir rule",
- sizeof(struct hns3_fdir_rule_ele),
- 0);
- if (fdir_rule_ptr == NULL) {
- hns3_err(hw, "Failed to allocate fdir_rule memory");
- ret = -ENOMEM;
- goto err_fdir;
- }
-
memcpy(&fdir_rule_ptr->fdir_conf, &fdir_rule,
sizeof(struct hns3_fdir_rule));
TAILQ_INSERT_TAIL(&process_list->fdir_list,
@@ -1827,10 +1828,10 @@ hns3_flow_create(struct rte_eth_dev *dev, const struct
rte_flow_attr *attr,
return flow;
}
+ rte_free(fdir_rule_ptr);
err_fdir:
if (fdir_rule.flags & HNS3_RULE_FLAG_COUNTER)
hns3_counter_release(dev, fdir_rule.act_cnt.id);
-
err:
rte_flow_error_set(error, -ret, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
"Failed to create flow");
--
2.7.4
[dpdk-dev] [PATCH 07/11] net/hns3: replace all atomic type with C11 atomic builtins
From: Chengchang Tang
Replace all the atomic type with C11 atomic builtins in hns3
PMD.
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
drivers/net/hns3/hns3_cmd.c | 13 +++--
drivers/net/hns3/hns3_ethdev.c| 21 -
drivers/net/hns3/hns3_ethdev.h| 4 ++--
drivers/net/hns3/hns3_ethdev_vf.c | 19 +++
drivers/net/hns3/hns3_intr.c | 22 ++
drivers/net/hns3/hns3_mbx.c | 4 ++--
6 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index b750022..3d6ffc0 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -202,7 +202,8 @@ hns3_cmd_csq_clean(struct hns3_hw *hw)
hns3_err(hw, "wrong cmd head (%u, %u-%u)", head,
csq->next_to_use, csq->next_to_clean);
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1,
+__ATOMIC_RELAXED);
hns3_schedule_delayed_reset(HNS3_DEV_HW_TO_ADAPTER(hw));
}
@@ -311,7 +312,7 @@ static int hns3_cmd_poll_reply(struct hns3_hw *hw)
if (hns3_cmd_csq_done(hw))
return 0;
- if (rte_atomic16_read(&hw->reset.disable_cmd)) {
+ if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
hns3_err(hw,
"Don't wait for reply because of disable_cmd");
return -EBUSY;
@@ -358,7 +359,7 @@ hns3_cmd_send(struct hns3_hw *hw, struct hns3_cmd_desc
*desc, int num)
int retval;
uint32_t ntc;
- if (rte_atomic16_read(&hw->reset.disable_cmd))
+ if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED))
return -EBUSY;
rte_spinlock_lock(&hw->cmq.csq.lock);
@@ -535,7 +536,7 @@ hns3_cmd_init(struct hns3_hw *hw)
ret = -EBUSY;
goto err_cmd_init;
}
- rte_atomic16_clear(&hw->reset.disable_cmd);
+ __atomic_store_n(&hw->reset.disable_cmd, 0, __ATOMIC_RELAXED);
ret = hns3_cmd_query_firmware_version_and_capability(hw);
if (ret) {
@@ -557,7 +558,7 @@ hns3_cmd_init(struct hns3_hw *hw)
return 0;
err_cmd_init:
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
return ret;
}
@@ -583,7 +584,7 @@ hns3_cmd_uninit(struct hns3_hw *hw)
{
rte_spinlock_lock(&hw->cmq.csq.lock);
rte_spinlock_lock(&hw->cmq.crq.lock);
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
hns3_cmd_clear_regs(hw);
rte_spinlock_unlock(&hw->cmq.crq.lock);
rte_spinlock_unlock(&hw->cmq.csq.lock);
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index c0ab3fc..a7ae8f8 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -130,7 +130,7 @@ hns3_proc_imp_reset_event(struct hns3_adapter *hns, bool
is_delay,
{
struct hns3_hw *hw = &hns->hw;
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
hns3_atomic_set_bit(HNS3_IMP_RESET, &hw->reset.pending);
*vec_val = BIT(HNS3_VECTOR0_IMPRESET_INT_B);
if (!is_delay) {
@@ -150,7 +150,7 @@ hns3_proc_global_reset_event(struct hns3_adapter *hns, bool
is_delay,
{
struct hns3_hw *hw = &hns->hw;
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
hns3_atomic_set_bit(HNS3_GLOBAL_RESET, &hw->reset.pending);
*vec_val = BIT(HNS3_VECTOR0_GLOBALRESET_INT_B);
if (!is_delay) {
@@ -5070,7 +5070,7 @@ hns3_do_stop(struct hns3_adapter *hns)
return ret;
hw->mac.link_status = ETH_LINK_DOWN;
- if (rte_atomic16_read(&hw->reset.disable_cmd) == 0) {
+ if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED) == 0) {
hns3_configure_all_mac_addr(hns, true);
ret = hns3_reset_all_tqps(hns);
if (ret) {
@@ -5613,7 +5613,7 @@ hns3_prepare_reset(struct hns3_adapter *hns)
* any mailbox handling or command to firmware is only valid
* after hns3_cmd_init is called.
*/
- rte_atomic16_set(&hw->reset.disable_cmd, 1);
+ __atomic_store_n(&hw->reset.disable_cmd, 1, __ATOMIC_RELAXED);
hw->reset.stats.request_cnt++;
break;
case HNS3_IMP_RESET:
@@ -5673,7 +5673,7 @@ hns3_stop_service(struct hns3_adapter *hns)
* from table space. Hence, for function res
[dpdk-dev] [PATCH 2/2] config/arm: fix Hisilicon kunpeng930 Soc build
From: Chengchang Tang
Because of the '9ca2f16' have merged, the current hns3
pmd driver can not be directly complied on the kunpeng930
FPGA board. Therefore, we need to fix the meson build.
Besides, add kunpeng 930 SoC meson cross compile target.
Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
config/arm/arm64_kunpeng930_linux_gcc | 19 +++
config/arm/meson.build | 7 +++
doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 1 +
3 files changed, 27 insertions(+)
create mode 100644 config/arm/arm64_kunpeng930_linux_gcc
diff --git a/config/arm/arm64_kunpeng930_linux_gcc
b/config/arm/arm64_kunpeng930_linux_gcc
new file mode 100644
index 000..464e44a
--- /dev/null
+++ b/config/arm/arm64_kunpeng930_linux_gcc
@@ -0,0 +1,19 @@
+[binaries]
+c = 'aarch64-linux-gnu-gcc'
+cpp = 'aarch64-linux-gnu-cpp'
+ar = 'aarch64-linux-gnu-gcc-ar'
+strip = 'aarch64-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+pcap-config = ''
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv8-a'
+endian = 'little'
+
+[properties]
+implementer_id = '0x48'
+part_number = '0xd02'
+max_lcores = 256
+max_numa_nodes = 4
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 9b87f5a..f834adb 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -148,6 +148,13 @@ implementer_hisilicon = {
['RTE_MAX_LCORE', 128],
['RTE_ARM_FEATURE_ATOMICS', true]
]
+ },
+ '0xd02': {
+ 'machine_args': ['-march=armv8.2-a+crypto+sve'],
+ 'flag': [['RTE_MACHINE', '"kunpeng930"'],
+['RTE_MAX_LCORE', 256],
+['RTE_ARM_FEATURE_ATOMICS', true]
+ ]
}
}
}
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index afe4f8e..1a54436 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -222,6 +222,7 @@ you may use various combinations of implementer/part
number::
Supported part_numbers for 0x48:
'0xd01':kunpeng920
+ '0xd02':kunpeng930
Supported part_numbers for 0x50:
'0x0': emag
--
2.7.4
[dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC build
From: Chengchang Tang
Because of the '9ca2f16' have merged, the current hns3
pmd driver can not be directly complied on the kunpeng920
server board. Therefore, we need to fix the meson build.
Besides, add kunpeng 920 SoC meson cross compile target.
Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
config/arm/arm64_kunpeng920_linux_gcc | 19 +++
config/arm/meson.build | 20
doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 4
3 files changed, 43 insertions(+)
create mode 100644 config/arm/arm64_kunpeng920_linux_gcc
diff --git a/config/arm/arm64_kunpeng920_linux_gcc
b/config/arm/arm64_kunpeng920_linux_gcc
new file mode 100644
index 000..3eeb2e9
--- /dev/null
+++ b/config/arm/arm64_kunpeng920_linux_gcc
@@ -0,0 +1,19 @@
+[binaries]
+c = 'aarch64-linux-gnu-gcc'
+cpp = 'aarch64-linux-gnu-cpp'
+ar = 'aarch64-linux-gnu-gcc-ar'
+strip = 'aarch64-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+pcap-config = ''
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'armv8-a'
+endian = 'little'
+
+[properties]
+implementer_id = '0x48'
+part_number = '0xd01'
+max_lcores = 128
+max_numa_nodes = 4
diff --git a/config/arm/meson.build b/config/arm/meson.build
index f948768..9b87f5a 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -133,6 +133,25 @@ implementer_cavium = {
}
}
+implementer_hisilicon = {
+ 'description': 'Hisilicon',
+ 'flags': [
+ ['RTE_USE_C11_MEM_MODEL', true],
+ ['RTE_CACHE_LINE_SIZE', 128],
+ ['RTE_MAX_NUMA_NODES', 4]
+ ],
+ 'part_number_config': {
+ '0xd01': {
+ 'machine_args': ['-march=armv8.2-a+crypto',
+'-mtune=tsv110'],
+ 'flag': [['RTE_MACHINE', '"kunpeng920"'],
+['RTE_MAX_LCORE', 128],
+['RTE_ARM_FEATURE_ATOMICS', true]
+ ]
+ }
+ }
+}
+
implementer_ampere = {
'description': 'Ampere Computing',
'flags': [
@@ -176,6 +195,7 @@ implementers = {
'generic': implementer_generic,
'0x41': implementer_arm,
'0x43': implementer_cavium,
+ '0x48': implementer_hisilicon,
'0x50': implementer_ampere,
'0x56': implementer_marvell,
'dpaa': implementer_dpaa
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index faaf24b..afe4f8e 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -197,6 +197,7 @@ you may use various combinations of implementer/part
number::
'generic': Generic armv8
'0x41':Arm
'0x43':Cavium
+ '0x48':Hisilicon
'0x50':Ampere Computing
'0x56':Marvell ARMADA
'dpaa':NXP DPAA
@@ -219,6 +220,9 @@ you may use various combinations of implementer/part
number::
'0xaf':thunderx2t99
'0xb2':octeontx2
+ Supported part_numbers for 0x48:
+ '0xd01':kunpeng920
+
Supported part_numbers for 0x50:
'0x0': emag
--
2.7.4
[dpdk-dev] [PATCH 0/2] meson build fixes for hns3
This series fix meson build for kunpeng920 and kunpeng930 boards. Chengchang Tang (2): config/arm: fix Hisilicon kunpeng920 SoC build config/arm: fix Hisilicon kunpeng930 Soc build config/arm/arm64_kunpeng920_linux_gcc | 19 +++ config/arm/arm64_kunpeng930_linux_gcc | 19 +++ config/arm/meson.build | 27 ++ .../linux_gsg/cross_build_dpdk_for_arm64.rst | 5 4 files changed, 70 insertions(+) create mode 100644 config/arm/arm64_kunpeng920_linux_gcc create mode 100644 config/arm/arm64_kunpeng930_linux_gcc -- 2.7.4
Re: [dpdk-dev] [PATCH] examples/vhost: add error propagation in ioat ops
On 2/3/21 12:52 PM, Jiang, Cheng1 wrote:
> Hi,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Wednesday, February 3, 2021 5:49 PM
>> To: Jiang, Cheng1 ; Xia, Chenbo
>>
>> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
>> ; Wang, Yinan
>> Subject: Re: [PATCH] examples/vhost: add error propagation in ioat ops
>>
>>
>>
>> On 1/31/21 1:36 PM, Cheng Jiang wrote:
>>> It makes more sense to add error propagation for rte_ioat_completed_ops.
>>>
>>> Signed-off-by: Cheng Jiang
>>> ---
>>> examples/vhost/ioat.c | 14 ++
>>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c index
>>> dbad28d43..60b73be93 100644
>>> --- a/examples/vhost/ioat.c
>>> +++ b/examples/vhost/ioat.c
>>> @@ -22,7 +22,6 @@ struct packet_tracker {
>>>
>>> struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
>>>
>>> -
>>> int
>>> open_ioat(const char *value)
>>> {
>>> @@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
>>> struct rte_vhost_async_status *opaque_data, uint16_t count)
>> {
>>> uint32_t i_desc;
>>> - int dev_id = dma_bind[vid].dmas[queue_id * 2 +
>> VIRTIO_RXQ].dev_id;
>>> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 +
>>> +VIRTIO_RXQ].dev_id;
>>
>> This change from uint16_t to int does not seem related to the purpose of this
>> patch. Is it?
>
> Yes, this change has nothing to do with adding the log, I just noticed
> uint16_t is more appropriate and changed here.
> I can only add the log if you think change the type of dev_id here is not ok.
Better to have two commits since these are two different changes.
At least please mention it in the commit message.
Thanks,
Maxime
> Thanks.
> Cheng
>
>>
>>> struct rte_vhost_iov_iter *src = NULL;
>>> struct rte_vhost_iov_iter *dst = NULL;
>>> unsigned long i_seg;
>>> @@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid,
>> uint16_t queue_id,
>>> unsigned short mask = MAX_ENQUEUED_SIZE - 1;
>>> unsigned short i;
>>>
>>> - int dev_id = dma_bind[vid].dmas[queue_id * 2
>>> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
>>> + VIRTIO_RXQ].dev_id;
>>> n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
>>> - if (n_seg <= 0)
>>> + if (n_seg < 0) {
>>> + RTE_LOG(ERR,
>>> + VHOST_DATA,
>>> + "fail to poll completed buf on IOAT
>> device %u",
>>> + dev_id);
>>> + return 0;
>>> + }
>>> + if (n_seg == 0)
>>> return 0;
>>>
>>> cb_tracker[dev_id].ioat_space += n_seg;
>>>
>
Re: [dpdk-dev] [PATCH 1/1] doc: explain steps for improved code spell checking
03/02/2021 13:18, Bruce Richardson: > On Wed, Feb 03, 2021 at 11:30:57AM +0100, Thomas Monjalon wrote: > > - > > https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt > > + git clone https://github.com/codespell-project/codespell.git > > > > Does installing via apt or dnf work as well? If we do install from package > do we still need to specify the path to codespell as script parameter? It depends whether all needed dictionary files are installed. Are they? > > -The path to the downloaded ``dictionary.txt`` must be set > > +There is a DPDK script to build an adjusted dictionary:: > > + > > + devtools/build-dict.sh codespell/ > codespell-dpdk.txt > > + > > Do we always need to have people build this themselves? Can we create a > .codespell-dpdk.txt file in the repo and have that as the default value for > the path if the environment variable is not set? The dictionaries are frequently updated. I don't really want to update them in DPDK. The default dictionary from the distro is used by default (if installed). In general, I think only tree maintainers and CI admins have to install the dictionaries for better result.
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
On 2/3/21 1:11 PM, Jiang, Cheng1 wrote:
> Hi,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Wednesday, February 3, 2021 5:52 PM
>> To: Jiang, Cheng1 ; Xia, Chenbo
>>
>> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
>> ; Wang, Yinan
>> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
>> counter
>>
>>
>>
>> On 2/2/21 7:17 AM, Cheng Jiang wrote:
>>> Remove async inflight packet counter since there is no need to keep
>>> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment
>>> number tracking ring from being exhausted.
>>
>> Is that an optimization or a fix?
>>
>> If the former, let's move it to v21.05.
>>
>
> I think it's a fix since there is no need to keep the inflight packet
> counter, sorry I forget adding the fixes, I can submit a v4 to fix it.
OK
>>>
>>> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>>>
>>> Signed-off-by: Cheng Jiang
>>> ---
>>> v3: fixed fixes commit id in git log
>>>
>>> v2: fixed a typo
>>>
>>> examples/vhost/ioat.h | 2 +-
>>> examples/vhost/main.c | 10 +- examples/vhost/main.h | 1 -
>>> 3 files changed, 2 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index
>>> 0a1dbb811..1aa28ed6a 100644
>>> --- a/examples/vhost/ioat.h
>>> +++ b/examples/vhost/ioat.h
>>> @@ -11,7 +11,7 @@
>>>
>>> #define MAX_VHOST_DEVICE 1024
>>> #define IOAT_RING_SIZE 4096
>>> -#define MAX_ENQUEUED_SIZE 512
>>> +#define MAX_ENQUEUED_SIZE 4096
>>
>> Basically, this the size of the ring size, correct?
>> It might be further simplified then.
>>
>
> Yes, it's a the size of packet tracking ring, and it should be no less then
> IOAT_RING_SIZE for some corner cases.
> I'm not sure I understand what you mean by saying It might be further
> simplified then.
I meant maybe in this case just use IOAT_RING_SIZE?
> Thanks,
> Cheng
>
>>>
>>> struct dma_info {
>>> struct rte_pci_addr addr;
>>> diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
>>> e74fc8750..ca73e7086 100644
>>> --- a/examples/vhost/main.c
>>> +++ b/examples/vhost/main.c
>>> @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev)
>>>
>>> complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
>>> VIRTIO_RXQ, p_cpl,
>> MAX_PKT_BURST);
>>> - if (complete_count) {
>>> - __atomic_sub_fetch(&vdev->nr_async_pkts,
>> complete_count,
>>> - __ATOMIC_SEQ_CST);
>>> + if (complete_count)
>>> free_pkts(p_cpl, complete_count);
>>> - }
>>> }
>>>
>>> static __rte_always_inline void
>>> @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
>>> complete_async_pkts(vdev);
>>> ret = rte_vhost_submit_enqueue_burst(vdev->vid,
>> VIRTIO_RXQ,
>>> m, nr_xmit, m_cpu_cpl,
>> &cpu_cpl_nr);
>>> - __atomic_add_fetch(&vdev->nr_async_pkts, ret -
>> cpu_cpl_nr,
>>> - __ATOMIC_SEQ_CST);
>>>
>>> if (cpu_cpl_nr)
>>> free_pkts(m_cpu_cpl, cpu_cpl_nr);
>>> @@ -1210,9 +1205,6 @@ drain_eth_rx(struct vhost_dev *vdev)
>>> enqueue_count = rte_vhost_submit_enqueue_burst(vdev-
>>> vid,
>>> VIRTIO_RXQ, pkts, rx_count,
>>> m_cpu_cpl, &cpu_cpl_nr);
>>> - __atomic_add_fetch(&vdev->nr_async_pkts,
>>> - enqueue_count - cpu_cpl_nr,
>>> - __ATOMIC_SEQ_CST);
>>> if (cpu_cpl_nr)
>>> free_pkts(m_cpu_cpl, cpu_cpl_nr);
>>>
>>> diff --git a/examples/vhost/main.h b/examples/vhost/main.h index
>>> 2d6c05fd7..0ccdce4b4 100644
>>> --- a/examples/vhost/main.h
>>> +++ b/examples/vhost/main.h
>>> @@ -51,7 +51,6 @@ struct vhost_dev {
>>> uint64_t features;
>>> size_t hdr_len;
>>> uint16_t nr_vrings;
>>> - uint64_t nr_async_pkts;
>>> struct rte_vhost_memory *mem;
>>> struct device_statistics stats;
>>> TAILQ_ENTRY(vhost_dev) global_vdev_entry;
>>> --
>>> 2.29.2
>>>
>
[dpdk-dev] [Bug 633] Secondary process crash with virtio PMD
https://bugs.dpdk.org/show_bug.cgi?id=633
Bug ID: 633
Summary: Secondary process crash with virtio PMD
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: anatoly.bura...@intel.com
Target Milestone: ---
This issue looks to be similar to bug 631, but it is not fixed as of latest
main or next-net. Spinning up a VM with DPDK as vhost and legacy virtio device,
and running testpmd as primary, and pdump as secondary results in the following
crash:
```
Thread 1 "dpdk-pdump" received signal SIGSEGV, Segmentation fault.
0x55a12cc8 in rte_pci_ioport_map (dev=0x56442bb0, bar=0,
p=0x562b9ec0 ) at ../drivers/bus/pci/linux/pci.c:751
751 switch (dev->kdrv) {
(gdb) bt
#0 0x55a12cc8 in rte_pci_ioport_map (dev=0x56442bb0, bar=0,
p=0x562b9ec0 ) at ../drivers/bus/pci/linux/pci.c:751
#1 0x55a9cada in vtpci_legacy_ioport_map (hw=0x1003b2dc0) at
../drivers/net/virtio/virtio_pci.c:882
#2 0x55a9558a in virtio_remap_pci (pci_dev=0x562e5ba0,
dev=0x1003b2dc0) at ../drivers/net/virtio/virtio_pci_ethdev.c:63
#3 0x55a956e2 in eth_virtio_pci_init (eth_dev=0x56232540
) at ../drivers/net/virtio/virtio_pci_ethdev.c:90
#4 0x55a95488 in rte_eth_dev_pci_generic_probe
(pci_dev=0x562e5ba0, private_data_size=128, dev_init=0x55a9559c
)
at ../lib/librte_ethdev/ethdev_pci.h:129
#5 0x55a95a91 in eth_virtio_pci_probe (pci_drv=0x55ce4600
, pci_dev=0x562e5ba0) at
../drivers/net/virtio/virtio_pci_ethdev.c:192
#6 0x55a0f72c in rte_pci_probe_one_driver (dr=0x55ce4600
, dev=0x562e5ba0) at
../drivers/bus/pci/pci_common.c:243
#7 0x55a0f92b in pci_probe_all_drivers (dev=0x562e5ba0) at
../drivers/bus/pci/pci_common.c:318
#8 0x55a0f9b4 in pci_probe () at ../drivers/bus/pci/pci_common.c:345
#9 0x559c9573 in rte_bus_probe () at
../lib/librte_eal/common/eal_common_bus.c:72
#10 0x559f720a in rte_eal_init (argc=8, argv=0x7fffe230) at
../lib/librte_eal/linux/eal.c:1281
#11 0x5559 in main (argc=8, argv=0x7fffe3d8) at
../app/pdump/main.c:989
```
Offending commit:
```
commit c8d4b02f72aefda2dbe2895cd661c29161a6770d
Author: Maxime Coquelin
Date: Tue Jan 26 11:16:12 2021 +0100
net/virtio: move legacy IO to virtio PCI
This patch moves Virtio PCI legacy IO handling to
virtio_pci.c. Two functions are created so that
virtio_pci_ethdev does not have to care about it.
Signed-off-by: Maxime Coquelin
Reviewed-by: Chenbo Xia
Reviewed-by: David Marchand
```
VM setup command is as follows:
```
/home/QEMU/qemu-4.2.1/bin/qemu-system-x86_64 -name vm0 -enable-kvm -pidfile
/tmp/.vm0.pid -daemonize -monitor unix:/tmp/vm0_monitor.sock,server,nowait
-netdev user,id=nttsip1,hostfwd=tcp:10.240.183.212:6000-:22 -device
e1000,netdev=nttsip1 -chardev socket,id=char0,path=/root/dpdk/vhost-net0
-netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce -device
virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=true,mrg_rxbuf=on,csum=on,gso=on,guest_csum=on,host_tso4=on,guest_tso4=on,guest_ecn=on
-cpu host -smp 8 -m 8192 -object
memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on -numa
node,memdev=mem -mem-prealloc -chardev
socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 -device virtio-serial
-device virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 -vnc :4
-drive file=/home/image/ubuntu2004.img
```
Test-pmd and pdump can be run without any parameters, so:
```
# app/dpdk-testpmd
# ...in another window...
# app/dpdk-pdump
```
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [dpdk-dev] [PATCH] examples/vhost: add error propagation in ioat ops
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 8:49 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH] examples/vhost: add error propagation in ioat ops
>
>
>
> On 2/3/21 12:52 PM, Jiang, Cheng1 wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Maxime Coquelin
> >> Sent: Wednesday, February 3, 2021 5:49 PM
> >> To: Jiang, Cheng1 ; Xia, Chenbo
> >>
> >> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> >> ; Wang, Yinan
> >> Subject: Re: [PATCH] examples/vhost: add error propagation in ioat
> >> ops
> >>
> >>
> >>
> >> On 1/31/21 1:36 PM, Cheng Jiang wrote:
> >>> It makes more sense to add error propagation for
> rte_ioat_completed_ops.
> >>>
> >>> Signed-off-by: Cheng Jiang
> >>> ---
> >>> examples/vhost/ioat.c | 14 ++
> >>> 1 file changed, 10 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c index
> >>> dbad28d43..60b73be93 100644
> >>> --- a/examples/vhost/ioat.c
> >>> +++ b/examples/vhost/ioat.c
> >>> @@ -22,7 +22,6 @@ struct packet_tracker {
> >>>
> >>> struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
> >>>
> >>> -
> >>> int
> >>> open_ioat(const char *value)
> >>> {
> >>> @@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
> >>> struct rte_vhost_async_status *opaque_data, uint16_t count)
> >> {
> >>> uint32_t i_desc;
> >>> - int dev_id = dma_bind[vid].dmas[queue_id * 2 +
> >> VIRTIO_RXQ].dev_id;
> >>> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 +
> >>> +VIRTIO_RXQ].dev_id;
> >>
> >> This change from uint16_t to int does not seem related to the purpose
> >> of this patch. Is it?
> >
> > Yes, this change has nothing to do with adding the log, I just noticed
> uint16_t is more appropriate and changed here.
> > I can only add the log if you think change the type of dev_id here is not
> > ok.
>
> Better to have two commits since these are two different changes.
> At least please mention it in the commit message.
Sure, I'll mention it in the commit message.
Thanks,
Cheng
>
> Thanks,
> Maxime
>
>
> > Thanks.
> > Cheng
> >
> >>
> >>> struct rte_vhost_iov_iter *src = NULL;
> >>> struct rte_vhost_iov_iter *dst = NULL;
> >>> unsigned long i_seg;
> >>> @@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid,
> >> uint16_t queue_id,
> >>> unsigned short mask = MAX_ENQUEUED_SIZE - 1;
> >>> unsigned short i;
> >>>
> >>> - int dev_id = dma_bind[vid].dmas[queue_id * 2
> >>> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
> >>> + VIRTIO_RXQ].dev_id;
> >>> n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
> >>> - if (n_seg <= 0)
> >>> + if (n_seg < 0) {
> >>> + RTE_LOG(ERR,
> >>> + VHOST_DATA,
> >>> + "fail to poll completed buf on IOAT
> >> device %u",
> >>> + dev_id);
> >>> + return 0;
> >>> + }
> >>> + if (n_seg == 0)
> >>> return 0;
> >>>
> >>> cb_tracker[dev_id].ioat_space += n_seg;
> >>>
> >
[dpdk-dev] [Bug 634] i40e: rte_flow doesn't allow RSS action on IPV4 only
https://bugs.dpdk.org/show_bug.cgi?id=634
Bug ID: 634
Summary: i40e: rte_flow doesn't allow RSS action on IPV4 only
Product: DPDK
Version: 20.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: frederic.coiff...@6cure.com
Target Milestone: ---
Hi,
If I use IPV4+TCP, it works fine :
```
memset(pattern, 0, sizeof(pattern));
memset(action, 0, sizeof(action));
memset(&attr, 0, sizeof(struct rte_flow_attr));
attr.ingress = 1;
action_rss = (struct rte_flow_action_rss){
.types = ETH_RSS_NONFRAG_IPV4_TCP | ETH_RSS_L3_SRC_ONLY,
.key_len = RSS_HASH_KEY_LENGTH,
.queue_num = 0,
.key = default_rss_hash_key,
};
pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4;
pattern[2].type = RTE_FLOW_ITEM_TYPE_TCP;
pattern[3].type = RTE_FLOW_ITEM_TYPE_END;
action[0].type = RTE_FLOW_ACTION_TYPE_RSS;
action[0].conf = &action_rss;
action[1].type = RTE_FLOW_ACTION_TYPE_END;
res = rte_flow_validate(port_id, &attr, pattern, action, error);
if (res) {
LOG_WARNING("rte_flow_validate() fails: %d %s", res, error->message);
return NULL;
}
flow = rte_flow_create(port_id, &attr, pattern, action, error);
if (!flow) {
LOG_WARNING("rte_flow_create() fails: %d %s", res, error->message);
return NULL;
}
LOG_DEBUG("rte_flow_create() success");
```
But as my purpose is to compute on IPv4 source for all IPv4 packets, I would
like :
```
memset(pattern, 0, sizeof(pattern));
memset(action, 0, sizeof(action));
memset(&attr, 0, sizeof(struct rte_flow_attr));
attr.ingress = 1;
action_rss = (struct rte_flow_action_rss){
.types = ETH_RSS_IP | ETH_RSS_L3_SRC_ONLY,
.key_len = RSS_HASH_KEY_LENGTH,
.queue_num = 0,
.key = default_rss_hash_key,
};
pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4;
pattern[2].type = RTE_FLOW_ITEM_TYPE_END;
action[0].type = RTE_FLOW_ACTION_TYPE_RSS;
action[0].conf = &action_rss;
action[1].type = RTE_FLOW_ACTION_TYPE_END;
res = rte_flow_validate(port_id, &attr, pattern, action, error);
if (res) {
LOG_WARNING("rte_flow_validate() fails: %d %s", res, error->message);
/// TODO
exit(-1);
/// TODO
return NULL;
}
flow = rte_flow_create(port_id, &attr, pattern, action, error);
if (!flow) {
LOG_WARNING("rte_flow_create() fails: %d %s", res, error->message);
}
LOG_DEBUG("rte_flow_create() success\n");
```
But in this case, I get "multi pctype is not supported" error. And this is true
as I need `ETH_RSS_IPV4`, `ETH_RSS_FRAG_IPV4` and `ETH_RSS_NONFRAG_IPV4_OTHER`.
So, is this a limitation of the current i40e driver ? Is there a different way
to treat all IPv4 packets ? (and later, to treat IPv6 packets in the same way)
Regards,
Frédéric
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 8:55 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
> counter
>
>
>
> On 2/3/21 1:11 PM, Jiang, Cheng1 wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Maxime Coquelin
> >> Sent: Wednesday, February 3, 2021 5:52 PM
> >> To: Jiang, Cheng1 ; Xia, Chenbo
> >>
> >> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> >> ; Wang, Yinan
> >> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
> >> counter
> >>
> >>
> >>
> >> On 2/2/21 7:17 AM, Cheng Jiang wrote:
> >>> Remove async inflight packet counter since there is no need to keep
> >>> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment
> >>> number tracking ring from being exhausted.
> >>
> >> Is that an optimization or a fix?
> >>
> >> If the former, let's move it to v21.05.
> >>
> >
> > I think it's a fix since there is no need to keep the inflight packet
> > counter,
> sorry I forget adding the fixes, I can submit a v4 to fix it.
> OK
> >>>
> >>> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
Oh, I got fixes here, sorry for the miss.
> >>>
> >>> Signed-off-by: Cheng Jiang
> >>> ---
> >>> v3: fixed fixes commit id in git log
> >>>
> >>> v2: fixed a typo
> >>>
> >>> examples/vhost/ioat.h | 2 +-
> >>> examples/vhost/main.c | 10 +- examples/vhost/main.h | 1 -
> >>> 3 files changed, 2 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index
> >>> 0a1dbb811..1aa28ed6a 100644
> >>> --- a/examples/vhost/ioat.h
> >>> +++ b/examples/vhost/ioat.h
> >>> @@ -11,7 +11,7 @@
> >>>
> >>> #define MAX_VHOST_DEVICE 1024
> >>> #define IOAT_RING_SIZE 4096
> >>> -#define MAX_ENQUEUED_SIZE 512
> >>> +#define It might be further simplified then 4096
> >>
> >> Basically, this the size of the ring size, correct?
> >> It might be further simplified then.
> >>
> >
> > Yes, it's a the size of packet tracking ring, and it should be no less then
> IOAT_RING_SIZE for some corner cases.
> > I'm not sure I understand what you mean by saying It might be further
> simplified then.
>
> I meant maybe in this case just use IOAT_RING_SIZE?
I have thought about it before I use MAX_ENQUEUED_SIZE.
But actually MAX_ENQUEUED_SIZE is used to for packet tracking ring, and
IOAT_RING_SIZE is for ioat ring.
Using IOAT_RING_SIZE for packet tracking ring, I think maybe it's not so
logical and a little bit confusing. What do you think?
Thanks,
Cheng
>
> > Thanks,
> > Cheng
> >
> >>>
> >>> struct dma_info {
> >>> struct rte_pci_addr addr;
> >>> diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
> >>> e74fc8750..ca73e7086 100644
> >>> --- a/examples/vhost/main.c
> >>> +++ b/examples/vhost/main.c
> >>> @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev)
> >>>
> >>> complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
> >>> VIRTIO_RXQ, p_cpl,
> >> MAX_PKT_BURST);
> >>> - if (complete_count) {
> >>> - __atomic_sub_fetch(&vdev->nr_async_pkts,
> >> complete_count,
> >>> - __ATOMIC_SEQ_CST);
> >>> + if (complete_count)
> >>> free_pkts(p_cpl, complete_count);
> >>> - }
> >>> }
> >>>
> >>> static __rte_always_inline void
> >>> @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
> >>> complete_async_pkts(vdev);
> >>> ret = rte_vhost_submit_enqueue_burst(vdev->vid,
> >> VIRTIO_RXQ,
> >>> m, nr_xmit, m_cpu_cpl,
> >> &cpu_cpl_nr);
> >>> - __atomic_add_fetch(&vdev->nr_async_pkts, ret -
> >> cpu_cpl_nr,
> >>> - __ATOMIC_SEQ_CST);
> >>>
> >>> if (cpu_cpl_nr)
> >>> free_pkts(m_cpu_cpl, cpu_cpl_nr); @@ -1210,9
> +1205,6 @@
> >>> drain_eth_rx(struct vhost_dev *vdev)
> >>> enqueue_count = rte_vhost_submit_enqueue_burst(vdev-
> >>> vid,
> >>> VIRTIO_RXQ, pkts, rx_count,
> >>> m_cpu_cpl, &cpu_cpl_nr);
> >>> - __atomic_add_fetch(&vdev->nr_async_pkts,
> >>> - enqueue_count - cpu_cpl_nr,
> >>> - __ATOMIC_SEQ_CST);
> >>> if (cpu_cpl_nr)
> >>> free_pkts(m_cpu_cpl, cpu_cpl_nr);
> >>>
> >>> diff --git a/examples/vhost/main.h b/examples/vhost/main.h index
> >>> 2d6c05fd7..0ccdce4b4 100644
> >>> --- a/examples/vhost/main.h
> >>> +++ b/examples/vhost/main.h
> >>> @@ -51,7 +51,6 @@ struct vhost_dev {
> >>> uint64_t features;
> >>> size_t hdr_len;
> >>> uint16_t nr_vrings;
> >>> - uint64_t nr_async_pkts;
> >>> struct rte_vhost_memory *mem;
> >>> struct device_statistics stats;
> >>> TAILQ_ENTRY(vhost_dev) global_vdev_entry;
> >>> --
> >>> 2.29.2
> >>>
> >
Re: [dpdk-dev] [PATCH 1/1] doc: explain steps for improved code spell checking
On Wed, Feb 03, 2021 at 01:53:58PM +0100, Thomas Monjalon wrote: > 03/02/2021 13:18, Bruce Richardson: > > On Wed, Feb 03, 2021 at 11:30:57AM +0100, Thomas Monjalon wrote: > > > - > > > https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt > > > + git clone https://github.com/codespell-project/codespell.git > > > > > > > Does installing via apt or dnf work as well? If we do install from package > > do we still need to specify the path to codespell as script parameter? > > It depends whether all needed dictionary files are installed. Are they? > > > > -The path to the downloaded ``dictionary.txt`` must be set > > > +There is a DPDK script to build an adjusted dictionary:: > > > + > > > + devtools/build-dict.sh codespell/ > codespell-dpdk.txt > > > + > > > > Do we always need to have people build this themselves? Can we create a > > .codespell-dpdk.txt file in the repo and have that as the default value for > > the path if the environment variable is not set? > > The dictionaries are frequently updated. > I don't really want to update them in DPDK. > > The default dictionary from the distro is used by default (if installed). > > In general, I think only tree maintainers and CI admins > have to install the dictionaries for better result. > That's good. Perhaps it's better to note down then first that the default distro dictionaries are used and if one wants enhanced checking to follow the extra steps. /Bruce
[dpdk-dev] [PATCH v16 0/3] Arm build options rework
The current way of specifying Arm configuration options is insufficient since we can't identify the SoC we're building for from the MIDR information. For example, we can't distinguish between N1SDP, Graviton2 or Ampere Altra. We also want to be able to enable/disable which drivers are built without user input. This is useful when building: 1. on an SoC that is slow and we want to build only what is necessary without the user having to check which libraries they have installed 2. a cross build on a fast aarch64 machine but with target SoC which differs in capabilities or libraries. This is achieved by specifying the drivers in SoC configuration. The current implementation adds/supports the following: * x86 -> aarch64 cross build with added config options/enabled or disabled drivers/libs * aarch64 -> aarch64 builds for a different SoCs using meson -Dplatform option or using a cross file v16: Only three commits remaining - updated the cover letter. Renamed the 'soc' meson option to 'platform'. Added the support for enabling a particular set of drivers. Aligned enabling and disabling with the command line option so that wildcards can be used. Juraj Linkeš (3): build: disable/enable drivers in Arm builds build: add 'platform' meson option and Arm SoC config config: fix Arm implementer and its SoCs config/arm/arm64_armada_linux_gcc | 6 +- config/arm/arm64_armv8_linux_clang_ubuntu1804 | 3 +- config/arm/arm64_armv8_linux_gcc | 5 +- config/arm/arm64_bluefield_linux_gcc | 6 +- config/arm/arm64_dpaa_linux_gcc | 6 +- config/arm/arm64_emag_linux_gcc | 5 +- config/arm/arm64_graviton2_linux_gcc | 6 +- config/arm/arm64_n1sdp_linux_gcc | 6 +- config/arm/arm64_n2_linux_gcc | 6 +- config/arm/arm64_octeontx2_linux_gcc | 6 +- config/arm/arm64_stingray_linux_gcc | 6 +- config/arm/arm64_thunderx2_linux_gcc | 5 +- config/arm/arm64_thunderxt88_linux_gcc| 5 +- config/arm/meson.build| 178 +++--- .../linux_gsg/cross_build_dpdk_for_arm64.rst | 76 +++- drivers/meson.build | 41 +++- meson.build | 2 + meson_options.txt | 2 + 18 files changed, 231 insertions(+), 139 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v16 1/3] build: disable/enable drivers in Arm builds
Add support for enabling or disabling drivers for Arm cross build. Do
not implement any enable/disable lists yet.
Enabling drivers is useful when building for an SoC where we only want
to build a few drivers. That way the list won't be too long.
Similarly, disabling drivers is useful when we want to disable only a
few drivers.
Both of these are advantageous mainly in aarch64 -> aarch64 (or arch ->
same arch) builds, where the build machine may have the required driver
dependencies, yet we don't want to build drivers for a speficic SoC.
By default, build all drivers for which dependencies are found. If
enabled_drivers is a non-empty list, build only those drivers. If
disabled_drivers is non-empty list, build all drivers except those in
disabled_drivers. Error out if both are specified (i.e. do not support
that case).
Remove the old Makefile arm configutaion options which don't do anything
in Meson.
Signed-off-by: Juraj Linkeš
Acked-by: Bruce Richardson
Reviewed-by: Honnappa Nagarahalli
---
config/arm/meson.build| 4 --
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 8
drivers/meson.build | 41 ---
meson.build | 2 +
4 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index f948768578..d279724dec 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -16,9 +16,6 @@ flags_common = [
# ['RTE_ARM64_MEMCPY_ALIGN_MASK', 0xF],
# ['RTE_ARM64_MEMCPY_STRICT_ALIGN', false],
- ['RTE_NET_FM10K', false],
- ['RTE_NET_AVP', false],
-
['RTE_SCHED_VECTOR', false],
['RTE_ARM_USE_WFE', false],
['RTE_ARCH_ARM64', true],
@@ -125,7 +122,6 @@ implementer_cavium = {
['RTE_MACHINE', '"octeontx2"'],
['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_USE_C11_MEM_MODEL', true],
- ['RTE_EAL_IGB_UIO', false],
['RTE_MAX_LCORE', 36],
['RTE_MAX_NUMA_NODES', 1]
]
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index faaf24b95b..1504dbfef0 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -234,3 +234,11 @@ There are other options you may specify in a cross file to
tailor the build::
numa = false# set to false to force building for a non-NUMA
system
# if not set or set to true, the build system will build for a NUMA
# system only if libnuma is installed
+
+ disabled_drivers = ['bus/dpaa', 'crypto/*'] # add disabled drivers
+ # valid values are dir/subdirs in the drivers directory
+ # wildcards are allowed
+
+ enabled_drivers = ['common/*', 'bus/*'] # build only these drivers
+ # valid values are dir/subdirs in the drivers directory
+ # wildcards are allowed
diff --git a/drivers/meson.build b/drivers/meson.build
index fdf76120ac..70c1aa4e6c 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -18,8 +18,36 @@ subdirs = [
'baseband', # depends on common and bus.
]
-disabled_drivers = run_command(list_dir_globs, get_option('disable_drivers'),
- ).stdout().split()
+if meson.is_cross_build()
+ disabled_drivers += meson.get_cross_property('disabled_drivers', [])
+ enabled_drivers += meson.get_cross_property('enabled_drivers', [])
+endif
+
+# add cmdline disabled drivers (comma separated string)
+# and meson disabled drivers (list)
+# together into a comma separated string
+disabled_drivers = ','.join([get_option('disable_drivers'),
','.join(disabled_drivers)]).strip(',')
+if disabled_drivers != ''
+ disabled_drivers = run_command(list_dir_globs,
+ disabled_drivers).stdout().split()
+else
+ disabled_drivers = []
+endif
+
+if enabled_drivers != []
+ enabled_drivers = run_command(list_dir_globs,
+ ','.join(enabled_drivers)).stdout().split()
+endif
+
+if disabled_drivers != [] and enabled_drivers != []
+ # TODO/QUERY we could support both:
+ # first 'select' only drivers by enabled_drivers
+ # then 'deselect' those in disabled_drivers
+ # this would be useful if a directory is in enabled_drivers
+ # and a driver from that directory is in disabled_drivers
+ error('Simultaneous disabled drivers and enabled drivers ' +
+ 'configuration is not supported.')
+endif
default_cflags = machine_args
default_cflags += ['-DALLOW_EXPERIMENTAL_API']
@@ -48,7 +76,7 @@ foreach subpath:subdirs
dpdk_driver_classes += class
endif
# get already enabled drivers of the same class
- enabled_drivers = get_variable(class
[dpdk-dev] [PATCH v16 2/3] build: add 'platform' meson option and Arm SoC config
Add Arm SoC configuration sets to Arm meson.build and add an arch agnostic meson option, 'platform', to select from these SoC configurations for meson native builds. This is preferable to specifying a cross file when doing aarch64 -> aarch64 builds, since the cross file specifies the toolchain as well. Signed-off-by: Juraj Linkeš Reviewed-by: Honnappa Nagarahalli --- config/arm/arm64_armada_linux_gcc | 6 +- config/arm/arm64_armv8_linux_clang_ubuntu1804 | 3 +- config/arm/arm64_armv8_linux_gcc | 5 +- config/arm/arm64_bluefield_linux_gcc | 6 +- config/arm/arm64_dpaa_linux_gcc | 6 +- config/arm/arm64_emag_linux_gcc | 5 +- config/arm/arm64_graviton2_linux_gcc | 6 +- config/arm/arm64_n1sdp_linux_gcc | 6 +- config/arm/arm64_n2_linux_gcc | 6 +- config/arm/arm64_octeontx2_linux_gcc | 6 +- config/arm/arm64_stingray_linux_gcc | 6 +- config/arm/arm64_thunderx2_linux_gcc | 5 +- config/arm/arm64_thunderxt88_linux_gcc| 5 +- config/arm/meson.build| 140 +- .../linux_gsg/cross_build_dpdk_for_arm64.rst | 84 --- meson_options.txt | 2 + 16 files changed, 179 insertions(+), 118 deletions(-) diff --git a/config/arm/arm64_armada_linux_gcc b/config/arm/arm64_armada_linux_gcc index 9958db6692..301418949b 100644 --- a/config/arm/arm64_armada_linux_gcc +++ b/config/arm/arm64_armada_linux_gcc @@ -14,8 +14,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x56' -part_number = '0xd08' -max_lcores = 16 -max_numa_nodes = 1 -numa = false +platform = 'armada' diff --git a/config/arm/arm64_armv8_linux_clang_ubuntu1804 b/config/arm/arm64_armv8_linux_clang_ubuntu1804 index 8d8cc50ea4..db488d75f4 100644 --- a/config/arm/arm64_armv8_linux_clang_ubuntu1804 +++ b/config/arm/arm64_armv8_linux_clang_ubuntu1804 @@ -14,7 +14,6 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = 'generic' -part_number = 'default' +platform = 'generic' c_args = ['-target', 'aarch64-linux-gnu', '--sysroot', '/usr/aarch64-linux-gnu'] c_link_args = ['-target', 'aarch64-linux-gnu', '-fuse-ld=lld', '--gcc-toolchain=/usr'] diff --git a/config/arm/arm64_armv8_linux_gcc b/config/arm/arm64_armv8_linux_gcc index 5451a01da1..5391d35389 100644 --- a/config/arm/arm64_armv8_linux_gcc +++ b/config/arm/arm64_armv8_linux_gcc @@ -14,7 +14,4 @@ endian = 'little' [properties] # Generate binaries that are portable across all Armv8 machines -implementer_id = 'generic' -part_number = 'generic' -max_lcores = 256 -max_numa_nodes = 4 +platform = 'generic' diff --git a/config/arm/arm64_bluefield_linux_gcc b/config/arm/arm64_bluefield_linux_gcc index 6bef87fbd4..248a9f031a 100644 --- a/config/arm/arm64_bluefield_linux_gcc +++ b/config/arm/arm64_bluefield_linux_gcc @@ -13,8 +13,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x41' -part_number = '0xd08' -max_lcores = 16 -max_numa_nodes = 1 -numa = false +platform = 'bluefield' diff --git a/config/arm/arm64_dpaa_linux_gcc b/config/arm/arm64_dpaa_linux_gcc index 37398c7628..e9d5fd31fc 100644 --- a/config/arm/arm64_dpaa_linux_gcc +++ b/config/arm/arm64_dpaa_linux_gcc @@ -14,8 +14,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = 'dpaa' -part_number = '0xd08' -max_lcores = 16 -max_numa_nodes = 1 -numa = false +platform = 'dpaa' diff --git a/config/arm/arm64_emag_linux_gcc b/config/arm/arm64_emag_linux_gcc index 7cbb055106..9cdd931180 100644 --- a/config/arm/arm64_emag_linux_gcc +++ b/config/arm/arm64_emag_linux_gcc @@ -13,7 +13,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x50' -part_number = '0x0' -max_lcores = 32 -max_numa_nodes = 1 +platform = 'emag' diff --git a/config/arm/arm64_graviton2_linux_gcc b/config/arm/arm64_graviton2_linux_gcc index edacb79497..8016fd236c 100644 --- a/config/arm/arm64_graviton2_linux_gcc +++ b/config/arm/arm64_graviton2_linux_gcc @@ -13,8 +13,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x41' -part_number = '0xd0c' -max_lcores = 64 -max_numa_nodes = 1 -numa = false +platform = 'graviton2' diff --git a/config/arm/arm64_n1sdp_linux_gcc b/config/arm/arm64_n1sdp_linux_gcc index b00f2d1ef7..0df283e2f4 100644 --- a/config/arm/arm64_n1sdp_linux_gcc +++ b/config/arm/arm64_n1sdp_linux_gcc @@ -13,8 +13,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x41' -part_number = '0xd0c' -max_lcores = 4 -max_numa_nodes = 1 -numa = false +platform = 'n1sdp' diff --git a/config/arm/arm64_n2_linux_gcc b/config/arm/arm64_n2_linux_gcc index 817b8ee28e..036aee2b0a 100644 --- a/config/arm/arm64_n2_linux_gcc +++ b/config/arm/arm64_n2_linux_gcc @@ -13,8 +13,4 @@ cpu = 'armv8-a' endian = 'little' [properties] -implementer_id = '0x41' -part_number = '0xd49' -max_lcores = 64 -max_numa_nodes = 1 -numa
[dpdk-dev] [PATCH v16 3/3] config: fix Arm implementer and its SoCs
Fix the implementer and part number of DPAA and ARMADA SoCs.
The current values of 16 cores and 1 NUMA node don't cover all SoCs from
the Arm implementer, e.g. Taishan 2280 has 64 cores and 4 NUMA nodes.
Increase these to 64 and 4 to widen the coverage.
Add configuration to SoC options where smaller values are needed.
Fixes: 6ec78c2463ac ("build: add meson support for dpaaX platforms")
Cc: hemant.agra...@nxp.com
Fixes: dd1cd845c102 ("config: add Marvell ARMADA based on armv8-a")
Cc: lir...@marvell.com
Fixes: d97108a33231 ("config: change defaults of armv8")
Cc: ys...@mellanox.com
Signed-off-by: Juraj Linkeš
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Liron Himi
Acked-by: Pavan Nikhilesh
Acked-by: Viacheslav Ovsiienko
---
config/arm/meson.build | 60 +++---
1 file changed, 27 insertions(+), 33 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index c85d2ab005..1727c9def7 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -56,7 +56,8 @@ part_number_config_arm = {
['RTE_MACHINE', '"neoverse-n1"'],
['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_MAX_MEM_MB', 1048576],
- ['RTE_MAX_LCORE', 80]
+ ['RTE_MAX_LCORE', 80],
+ ['RTE_MAX_NUMA_NODES', 1]
]
},
'0xd49': {
@@ -64,7 +65,8 @@ part_number_config_arm = {
'flags': [
['RTE_MACHINE', '"neoverse-n2"'],
['RTE_ARM_FEATURE_ATOMICS', true],
- ['RTE_MAX_LCORE', 64]
+ ['RTE_MAX_LCORE', 64],
+ ['RTE_MAX_NUMA_NODES', 1]
]
}
}
@@ -74,8 +76,8 @@ implementer_arm = {
['RTE_MACHINE', '"armv8a"'],
['RTE_USE_C11_MEM_MODEL', true],
['RTE_CACHE_LINE_SIZE', 64],
- ['RTE_MAX_LCORE', 16],
- ['RTE_MAX_NUMA_NODES', 1]
+ ['RTE_MAX_LCORE', 64],
+ ['RTE_MAX_NUMA_NODES', 4]
],
'part_number_config': part_number_config_arm
}
@@ -143,38 +145,12 @@ implementer_ampere = {
}
}
-implementer_marvell = {
- 'description': 'Marvell ARMADA',
- 'flags': [
- ['RTE_MACHINE', '"armv8a"'],
- ['RTE_CACHE_LINE_SIZE', 64],
- ['RTE_MAX_LCORE', 16],
- ['RTE_MAX_NUMA_NODES', 1]
- ],
- 'part_number_config': part_number_config_arm
-}
-
-implementer_dpaa = {
- 'description': 'NXP DPAA',
- 'flags': [
- ['RTE_MACHINE', '"dpaa"'],
- ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false],
- ['RTE_USE_C11_MEM_MODEL', true],
- ['RTE_CACHE_LINE_SIZE', 64],
- ['RTE_MAX_LCORE', 16],
- ['RTE_MAX_NUMA_NODES', 1]
- ],
- 'part_number_config': part_number_config_arm
-}
-
## Arm implementers (ID from MIDR in Arm Architecture Reference Manual)
implementers = {
'generic': implementer_generic,
'0x41': implementer_arm,
'0x43': implementer_cavium,
- '0x50': implementer_ampere,
- '0x56': implementer_marvell,
- 'dpaa': implementer_dpaa
+ '0x50': implementer_ampere
}
# soc specific aarch64 flags have the highest priority
@@ -187,8 +163,12 @@ soc_generic = {
soc_armada = {
'description': 'Marvell ARMADA',
- 'implementer': '0x56',
+ 'implementer': '0x41',
'part_number': '0xd08',
+ 'flags': [
+ ['RTE_MAX_LCORE', 16],
+ ['RTE_MAX_NUMA_NODES', 1]
+ ],
'numa': false
}
@@ -196,13 +176,23 @@ soc_bluefield = {
'description': 'NVIDIA BlueField',
'implementer': '0x41',
'part_number': '0xd08',
+ 'flags': [
+ ['RTE_MAX_LCORE', 16],
+ ['RTE_MAX_NUMA_NODES', 1]
+ ],
'numa': false
}
soc_dpaa = {
'description': 'NXP DPAA',
- 'implementer': 'dpaa',
+ 'implementer': '0x41',
'part_number': '0xd08',
+ 'flags': [
+ ['RTE_MACHINE', '"dpaa"'],
+ ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false],
+ ['RTE_MAX_LCORE', 16],
+ ['RTE_MAX_NUMA_NODES', 1]
+ ],
'numa': false
}
@@ -246,6 +236,10 @@ soc_octeontx2 = {
soc_stingray = {
'description': 'Broadcom Stingray',
'implementer': '0x41',
+ 'flags': [
+ ['RTE_MAX_LCORE', 16],
+ ['RTE_MAX_NUMA_NODES', 1]
+ ],
'part_number': '0xd08',
'numa': false
}
--
2.20.1
Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table
> back again, do you suggest me to submit v4 with with corrected quota
> character or its ok to have the v3 of the patch itself as you have already
> acked ?
OK, let's ask Raslan to fix this minor issue while integrating the patch.
Raslan, could you, please, fix the quota character in the commit message?
With best regards, Slava
> -Original Message-
> From: Dey, Souvik
> Sent: Wednesday, February 3, 2021 14:09
> To: Slava Ovsiienko ; Raslan Darawsheh
> ; Matan Azrad
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v3] common/mlx5: fix storing the synched MAC to
> internal table
>
> Hi Slava,
> Initially v2 of the patch has " instead of ' in the Fixes tags, but it
> gave
> some warnings as wrong quota. So thought of changing it to '. I can change it
> back again, do you suggest me to submit v4 with with corrected quota
> character or its ok to have the v3 of the patch itself as you have already
> acked ?
>
> --
> Regards,
> Souvik
>
> -Original Message-
> From: dev On Behalf Of Slava Ovsiienko
> Sent: Wednesday, February 3, 2021 3:04 AM
> To: Dey, Souvik ; Raslan Darawsheh
> ; Matan Azrad
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched
> MAC to internal table
>
> NOTICE: This email was received from an EXTERNAL sender.
>
>
> Hi,
>
> I'm sorry, but quota character in "Fixes" tags is still wrong, causing the
> checking script errors.
> It should be " (0x22 ASCII), not ' (0x27 ASCII).
>
> Beside this:
>
> Acked-by: Viacheslav Ovsiienko
>
> > -Original Message-
> > From: Dey, Souvik
> > Sent: Tuesday, February 2, 2021 19:49
> > To: Raslan Darawsheh ; Slava Ovsiienko
> > ; Matan Azrad ; Shahaf
> > Shuler
> > Cc: dev@dpdk.org; sta...@dpdk.org; Souvik Dey
> > Subject: [PATCH v3] common/mlx5: fix storing the synched MAC to
> > internal table
> >
> > From: Souvik Dey
> >
> > As the internal MAC table is divided into Unicast and Multicast
> > address sections, we should check the type of synched MAC address
> > before storing it to the internal table. Currently the check is not
> > done, and the synched MAC of
> > 33:33:00:00:00:01 gets stored in the unicast section (mostly index 1)
> > causing all subsequent mlx5_set_mc_addr_list() to fail with error
> > -EADDRINUSE, as the mac_list contains the MAC 33:33:00:00:00:01. This
> > denies adding of any new multicast address to the internal list and
> > also fails to add the MAC address to the device in case of SR-IOV VF.
> >
> > Fixes: f22442cb5d42 ('net/mlx5: reduce Netlink commands dependencies')
> > Fixes: ccdcba53a3f4 ('net/mlx5: use Netlink to add/remove MAC
> > addresses')
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Souvik Dey
> > ---
> > v2:
> > * net/ -> common/
> > * space after mlx5:
> > * synched -> synched
> > * section -> sections
> > * rewording which causes -> causing
> > * typo: case (to remove)
> > * added Fixes for LTS ML
> > ---
> > v3:
> > * Changed the "" in Fixes tags to ''.
> > ---
> > drivers/common/mlx5/linux/mlx5_nl.c | 20 +++-
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/common/mlx5/linux/mlx5_nl.c
> > b/drivers/common/mlx5/linux/mlx5_nl.c
> > index 40d8620..ef7a521 100644
> > --- a/drivers/common/mlx5/linux/mlx5_nl.c
> > +++ b/drivers/common/mlx5/linux/mlx5_nl.c
> > @@ -758,11 +758,21 @@ mlx5_nl_mac_addr_sync(int nlsk_fd, unsigned
> int
> > iface_idx,
> > break;
> > if (j != n)
> > continue;
> > - /* Find the first entry available. */
> > - for (j = 0; j != n; ++j) {
> > - if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> > - mac_addrs[j] = macs[i];
> > - break;
> > + if (rte_is_multicast_ether_addr(&macs[i])) {
> > + /* Find the first entry available. */
> > + for (j = MLX5_MAX_UC_MAC_ADDRESSES; j != n; ++j)
> > {
> > + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> > + mac_addrs[j] = macs[i];
> > + break;
> > + }
> > + }
> > + } else {
> > + /* Find the first entry available. */
> > + for (j = 0; j != MLX5_MAX_UC_MAC_ADDRESSES; ++j)
> > {
> > + if (rte_is_zero_ether_addr(&mac_addrs[j])) {
> > + mac_addrs[j] = macs[i];
> > + break;
> > + }
> > }
> > }
> > }
> > --
> > 2.9.3.windows.1
> >
> >
>
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the inten
Re: [dpdk-dev] [PATCH] doc: fix supported feature table in mlx5 guide
Hi,
> -Original Message-
> From: Viacheslav Ovsiienko
> Sent: Tuesday, February 2, 2021 4:28 PM
> To: dev@dpdk.org
> Cc: Raslan Darawsheh ; NBU-Contact-Thomas
> Monjalon ; Asaf Penso ;
> carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> Subject: [PATCH] doc: fix supported feature table in mlx5 guide
>
> The fixes:
I'd replace this with something like following if it's OK with you and I can do
it during integration,
This sets the correct minimal requirements for these feature:
>
> - Buffer Split offload is supported/verified on ConnectX-5
> - Tx scheduling requires ConnectX-6DX and depends on firmware version
>
> Fixes: cb7b0c24c835 ("doc: update hardware offloads support in mlx5 guide")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
> ---
> doc/guides/nics/mlx5.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
[..]
Kindest regards
Raslan Darawsheh
[dpdk-dev] [PATCH v1] net/ice: update VLAN strip set in double VLAN mode
Since commit 14e7a4b37b4f ("net/ice/base: support configuring device in
double VLAN mode"), the VLAN strip design is changed, double VLAN mode
is not enabled by updating the VSI setting, it depends on the DDP and FW
running support.
Also, in double VLAN mode, the VLAN strip is applied on outer, since the
VLAN filter is outer; in single VLAN mode, the VLAN strip is applied on
inner, since the VLAN filter is inner.
Signed-off-by: Haiyue Wang
---
drivers/net/ice/ice_ethdev.c | 297 +++
1 file changed, 131 insertions(+), 166 deletions(-)
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 02a25e8d2a..cb2c0cf449 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -68,8 +68,6 @@ static struct proto_xtr_ol_flag
ice_proto_xtr_ol_flag_params[] = {
.ol_flag = &rte_net_ice_dynflag_proto_xtr_ip_offset_mask },
};
-#define ICE_DFLT_OUTER_TAG_TYPE ICE_AQ_VSI_OUTER_TAG_VLAN_9100
-
#define ICE_OS_DEFAULT_PKG_NAME"ICE OS Default Package"
#define ICE_COMMS_PKG_NAME "ICE COMMS Package"
#define ICE_MAX_RES_DESC_NUM1024
@@ -1122,127 +1120,6 @@ ice_remove_all_mac_vlan_filters(struct ice_vsi *vsi)
return ret;
}
-static int
-ice_vsi_config_qinq_insertion(struct ice_vsi *vsi, bool on)
-{
- struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
- struct ice_vsi_ctx ctxt;
- uint8_t qinq_flags;
- int ret = 0;
-
- /* Check if it has been already on or off */
- if (vsi->info.valid_sections &
- rte_cpu_to_le_16(ICE_AQ_VSI_PROP_OUTER_TAG_VALID)) {
- if (on) {
- if ((vsi->info.outer_vlan_flags &
-ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST) ==
- ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST)
- return 0; /* already on */
- } else {
- if (!(vsi->info.outer_vlan_flags &
- ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST))
- return 0; /* already off */
- }
- }
-
- if (on)
- qinq_flags = ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST;
- else
- qinq_flags = 0;
- /* clear global insertion and use per packet insertion */
- vsi->info.outer_vlan_flags &=
~(ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_INSERT);
- vsi->info.outer_vlan_flags &=
~(ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_ACCEPT_HOST);
- vsi->info.outer_vlan_flags |= qinq_flags;
- /* use default vlan type 0x8100 */
- vsi->info.outer_vlan_flags &= ~(ICE_AQ_VSI_OUTER_TAG_TYPE_M);
- vsi->info.outer_vlan_flags |= ICE_DFLT_OUTER_TAG_TYPE <<
-ICE_AQ_VSI_OUTER_TAG_TYPE_S;
- (void)rte_memcpy(&ctxt.info, &vsi->info, sizeof(vsi->info));
- ctxt.info.valid_sections =
- rte_cpu_to_le_16(ICE_AQ_VSI_PROP_OUTER_TAG_VALID);
- ctxt.vsi_num = vsi->vsi_id;
- ret = ice_update_vsi(hw, vsi->idx, &ctxt, NULL);
- if (ret) {
- PMD_DRV_LOG(INFO,
- "Update VSI failed to %s qinq stripping",
- on ? "enable" : "disable");
- return -EINVAL;
- }
-
- vsi->info.valid_sections |=
- rte_cpu_to_le_16(ICE_AQ_VSI_PROP_OUTER_TAG_VALID);
-
- return ret;
-}
-
-static int
-ice_vsi_config_qinq_stripping(struct ice_vsi *vsi, bool on)
-{
- struct ice_hw *hw = ICE_VSI_TO_HW(vsi);
- struct ice_vsi_ctx ctxt;
- uint8_t qinq_flags;
- int ret = 0;
-
- /* Check if it has been already on or off */
- if (vsi->info.valid_sections &
- rte_cpu_to_le_16(ICE_AQ_VSI_PROP_OUTER_TAG_VALID)) {
- if (on) {
- if ((vsi->info.outer_vlan_flags &
-ICE_AQ_VSI_OUTER_VLAN_EMODE_M) ==
- ICE_AQ_VSI_OUTER_VLAN_EMODE_SHOW)
- return 0; /* already on */
- } else {
- if ((vsi->info.outer_vlan_flags &
-ICE_AQ_VSI_OUTER_VLAN_EMODE_M) ==
- ICE_AQ_VSI_OUTER_VLAN_EMODE_SHOW_BOTH)
- return 0; /* already off */
- }
- }
-
- if (on)
- qinq_flags = ICE_AQ_VSI_OUTER_VLAN_EMODE_SHOW;
- else
- qinq_flags = ICE_AQ_VSI_OUTER_VLAN_EMODE_SHOW_BOTH;
- vsi->info.outer_vlan_flags &= ~(ICE_AQ_VSI_OUTER_VLAN_EMODE_M);
- vsi->info.outer_vlan_flags |= qinq_flags;
- /* use default vlan type 0x8100 */
- vsi->info.outer_vlan_flags &= ~(ICE_AQ_VSI_OUTER_TAG_TYPE_M);
- vsi->info.outer_vlan_flags |= ICE_DFLT_OUTER_TAG_TYPE <<
-ICE_AQ_VSI_OUTER_TAG_TYPE_S;
- (void)rte_memcpy(&ctxt.info, &vsi->info, si
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
On 2/3/21 2:42 PM, Jiang, Cheng1 wrote:
>
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Wednesday, February 3, 2021 8:55 PM
>> To: Jiang, Cheng1 ; Xia, Chenbo
>>
>> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
>> ; Wang, Yinan
>> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
>> counter
>>
>>
>>
>> On 2/3/21 1:11 PM, Jiang, Cheng1 wrote:
>>> Hi,
>>>
-Original Message-
From: Maxime Coquelin
Sent: Wednesday, February 3, 2021 5:52 PM
To: Jiang, Cheng1 ; Xia, Chenbo
Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
; Wang, Yinan
Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
counter
On 2/2/21 7:17 AM, Cheng Jiang wrote:
> Remove async inflight packet counter since there is no need to keep
> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment
> number tracking ring from being exhausted.
Is that an optimization or a fix?
If the former, let's move it to v21.05.
>>>
>>> I think it's a fix since there is no need to keep the inflight packet
>>> counter,
>> sorry I forget adding the fixes, I can submit a v4 to fix it.
>> OK
>
> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>
> Oh, I got fixes here, sorry for the miss.
>
>
> Signed-off-by: Cheng Jiang
> ---
> v3: fixed fixes commit id in git log
>
> v2: fixed a typo
>
> examples/vhost/ioat.h | 2 +-
> examples/vhost/main.c | 10 +- examples/vhost/main.h | 1 -
> 3 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index
> 0a1dbb811..1aa28ed6a 100644
> --- a/examples/vhost/ioat.h
> +++ b/examples/vhost/ioat.h
> @@ -11,7 +11,7 @@
>
> #define MAX_VHOST_DEVICE 1024
> #define IOAT_RING_SIZE 4096
> -#define MAX_ENQUEUED_SIZE 512
> +#define It might be further simplified then 4096
Basically, this the size of the ring size, correct?
It might be further simplified then.
>>>
>>> Yes, it's a the size of packet tracking ring, and it should be no less then
>> IOAT_RING_SIZE for some corner cases.
>>> I'm not sure I understand what you mean by saying It might be further
>> simplified then.
>>
>> I meant maybe in this case just use IOAT_RING_SIZE?
>
> I have thought about it before I use MAX_ENQUEUED_SIZE.
> But actually MAX_ENQUEUED_SIZE is used to for packet tracking ring, and
> IOAT_RING_SIZE is for ioat ring.
> Using IOAT_RING_SIZE for packet tracking ring, I think maybe it's not so
> logical and a little bit confusing. What do you think?
OK, let's keep it as is then.
Thanks,
Maxime
> Thanks,
> Cheng
>
>>
>>> Thanks,
>>> Cheng
>>>
>
> struct dma_info {
> struct rte_pci_addr addr;
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
> e74fc8750..ca73e7086 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev)
>
> complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
> VIRTIO_RXQ, p_cpl,
MAX_PKT_BURST);
> - if (complete_count) {
> - __atomic_sub_fetch(&vdev->nr_async_pkts,
complete_count,
> - __ATOMIC_SEQ_CST);
> + if (complete_count)
> free_pkts(p_cpl, complete_count);
> - }
> }
>
> static __rte_always_inline void
> @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
> complete_async_pkts(vdev);
> ret = rte_vhost_submit_enqueue_burst(vdev->vid,
VIRTIO_RXQ,
> m, nr_xmit, m_cpu_cpl,
&cpu_cpl_nr);
> - __atomic_add_fetch(&vdev->nr_async_pkts, ret -
cpu_cpl_nr,
> - __ATOMIC_SEQ_CST);
>
> if (cpu_cpl_nr)
> free_pkts(m_cpu_cpl, cpu_cpl_nr); @@ -1210,9
>> +1205,6 @@
> drain_eth_rx(struct vhost_dev *vdev)
> enqueue_count = rte_vhost_submit_enqueue_burst(vdev-
> vid,
> VIRTIO_RXQ, pkts, rx_count,
> m_cpu_cpl, &cpu_cpl_nr);
> - __atomic_add_fetch(&vdev->nr_async_pkts,
> - enqueue_count - cpu_cpl_nr,
> - __ATOMIC_SEQ_CST);
> if (cpu_cpl_nr)
> free_pkts(m_cpu_cpl, cpu_cpl_nr);
>
> diff --git a/examples/vhost/main.h b/examples/vhost/main.h index
> 2d6c05fd7..0ccdce4b4 100644
> --- a/examples/vhost/main.h
> +++ b/examples/vhost/main.h
> @@ -51,7 +51,6 @@ struct vhost_dev {
> uint64_t features;
> size_t hdr_len;
> uint16_t nr_vrings;
> - uint64_t nr_async_pkts;
> struct rte_vhost_memory *mem;
> struc
Re: [dpdk-dev] [PATCH] doc: fix supported feature table in mlx5 guide
> -Original Message-
> From: Raslan Darawsheh
> Sent: Wednesday, February 3, 2021 16:19
> To: Slava Ovsiienko ; dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon ; Asaf Penso
> ; carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> Subject: RE: [PATCH] doc: fix supported feature table in mlx5 guide
>
> Hi,
>
> > -Original Message-
> > From: Viacheslav Ovsiienko
> > Sent: Tuesday, February 2, 2021 4:28 PM
> > To: dev@dpdk.org
> > Cc: Raslan Darawsheh ; NBU-Contact-Thomas
> Monjalon
> > ; Asaf Penso ;
> > carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> > Subject: [PATCH] doc: fix supported feature table in mlx5 guide
> >
> > The fixes:
> I'd replace this with something like following if it's OK with you and I can
> do
> it during integration,
>This sets the correct minimal requirements for these
> feature:
>
Just a typo: "these featureS"
I'm OK with the update, thank you.
With best regards,
Slava
> > - Buffer Split offload is supported/verified on ConnectX-5
> > - Tx scheduling requires ConnectX-6DX and depends on firmware version
> >
> > Fixes: cb7b0c24c835 ("doc: update hardware offloads support in mlx5
> > guide")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Viacheslav Ovsiienko
> > ---
> > doc/guides/nics/mlx5.rst | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> [..]
>
> Kindest regards
> Raslan Darawsheh
Re: [dpdk-dev] [PATCH] doc: fix supported feature table in mlx5 guide
> -Original Message-
> From: Slava Ovsiienko
> Sent: Wednesday, February 3, 2021 4:25 PM
> To: Raslan Darawsheh ; dev@dpdk.org
> Cc: NBU-Contact-Thomas Monjalon ; Asaf Penso
> ; carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> Subject: RE: [PATCH] doc: fix supported feature table in mlx5 guide
>
> > -Original Message-
> > From: Raslan Darawsheh
> > Sent: Wednesday, February 3, 2021 16:19
> > To: Slava Ovsiienko ; dev@dpdk.org
> > Cc: NBU-Contact-Thomas Monjalon ; Asaf Penso
> > ; carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> > Subject: RE: [PATCH] doc: fix supported feature table in mlx5 guide
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Viacheslav Ovsiienko
> > > Sent: Tuesday, February 2, 2021 4:28 PM
> > > To: dev@dpdk.org
> > > Cc: Raslan Darawsheh ; NBU-Contact-Thomas
> > Monjalon
> > > ; Asaf Penso ;
> > > carsten.andr...@tu-ilmenau.de; sta...@dpdk.org
> > > Subject: [PATCH] doc: fix supported feature table in mlx5 guide
> > >
> > > The fixes:
> > I'd replace this with something like following if it's OK with you and I
> > can do
> > it during integration,
> >This sets the correct minimal requirements for these
> > feature:
> >
> Just a typo: "these featureS"
Sure,
>
> I'm OK with the update, thank you.
>
> With best regards,
> Slava
>
> > > - Buffer Split offload is supported/verified on ConnectX-5
> > > - Tx scheduling requires ConnectX-6DX and depends on firmware version
> > >
> > > Fixes: cb7b0c24c835 ("doc: update hardware offloads support in mlx5
> > > guide")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Viacheslav Ovsiienko
> > > ---
> > > doc/guides/nics/mlx5.rst | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > [..]
> >
> > Kindest regards
> > Raslan Darawsheh
Patch applied to next-net-mlx, with the small modification agreed above.
Kindest regards
Raslan Darawsheh
Re: [dpdk-dev] [PATCH] net/mlx5: fix validation for counter and age
Hi,
> -Original Message-
> From: Jiawei Wang
> Sent: Tuesday, February 2, 2021 6:43 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix validation for counter and age
>
> Currently old age action was implemented by flow counter and only one
> counter index was maintained in each flow. While there was old age
> action and share count action in one flow, and the same share count
> action in the another flow, the counter was updated if second flow
> was hit, so it may cause the first flow didn't aged out since the
> counter was updated by second flow.
>
> This patch updates the validation function for count and old age action:
> - Old age and shared count action combination is not supported.
> - Old age and count(not shared) action could work in the same sub flow.
>
> Fixes: e7138997e07d ("net/mlx5: make shared counters thread safe")
> Cc: sta...@dpdk.org
>
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 10:21 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
> counter
>
>
>
> On 2/3/21 2:42 PM, Jiang, Cheng1 wrote:
> >
> >
> >> -Original Message-
> >> From: Maxime Coquelin
> >> Sent: Wednesday, February 3, 2021 8:55 PM
> >> To: Jiang, Cheng1 ; Xia, Chenbo
> >>
> >> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> >> ; Wang, Yinan
> >> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet
> >> counter
> >>
> >>
> >>
> >> On 2/3/21 1:11 PM, Jiang, Cheng1 wrote:
> >>> Hi,
> >>>
> -Original Message-
> From: Maxime Coquelin
> Sent: Wednesday, February 3, 2021 5:52 PM
> To: Jiang, Cheng1 ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX
> ; Wang, Yinan
> Subject: Re: [PATCH v3] examples/vhost: remove async inflight
> packet counter
>
>
>
> On 2/2/21 7:17 AM, Cheng Jiang wrote:
> > Remove async inflight packet counter since there is no need to
> > keep tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet
> > segment number tracking ring from being exhausted.
>
> Is that an optimization or a fix?
>
> If the former, let's move it to v21.05.
>
> >>>
> >>> I think it's a fix since there is no need to keep the inflight
> >>> packet counter,
> >> sorry I forget adding the fixes, I can submit a v4 to fix it.
> >> OK
> >
> > Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
> >
> > Oh, I got fixes here, sorry for the miss.
> >
> >
> > Signed-off-by: Cheng Jiang
> > ---
> > v3: fixed fixes commit id in git log
> >
> > v2: fixed a typo
> >
> > examples/vhost/ioat.h | 2 +-
> > examples/vhost/main.c | 10 +- examples/vhost/main.h | 1
> > -
> > 3 files changed, 2 insertions(+), 11 deletions(-)
> >
> > diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index
> > 0a1dbb811..1aa28ed6a 100644
> > --- a/examples/vhost/ioat.h
> > +++ b/examples/vhost/ioat.h
> > @@ -11,7 +11,7 @@
> >
> > #define MAX_VHOST_DEVICE 1024
> > #define IOAT_RING_SIZE 4096
> > -#define MAX_ENQUEUED_SIZE 512
> > +#define It might be further simplified then 4096
>
> Basically, this the size of the ring size, correct?
> It might be further simplified then.
>
> >>>
> >>> Yes, it's a the size of packet tracking ring, and it should be no
> >>> less then
> >> IOAT_RING_SIZE for some corner cases.
> >>> I'm not sure I understand what you mean by saying It might be
> >>> further
> >> simplified then.
> >>
> >> I meant maybe in this case just use IOAT_RING_SIZE?
> >
> > I have thought about it before I use MAX_ENQUEUED_SIZE.
> > But actually MAX_ENQUEUED_SIZE is used to for packet tracking ring, and
> IOAT_RING_SIZE is for ioat ring.
> > Using IOAT_RING_SIZE for packet tracking ring, I think maybe it's not so
> logical and a little bit confusing. What do you think?
>
> OK, let's keep it as is then.
Sure, then this is the last version of this patch.
Thanks,
Cheng
>
> Thanks,
> Maxime
>
> > Thanks,
> > Cheng
> >
> >>
> >>> Thanks,
> >>> Cheng
> >>>
> >
> > struct dma_info {
> > struct rte_pci_addr addr;
> > diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
> > e74fc8750..ca73e7086 100644
> > --- a/examples/vhost/main.c
> > +++ b/examples/vhost/main.c
> > @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev
> *vdev)
> >
> > complete_count = rte_vhost_poll_enqueue_completed(vdev->vid,
> > VIRTIO_RXQ, p_cpl,
> MAX_PKT_BURST);
> > - if (complete_count) {
> > - __atomic_sub_fetch(&vdev->nr_async_pkts,
> complete_count,
> > - __ATOMIC_SEQ_CST);
> > + if (complete_count)
> > free_pkts(p_cpl, complete_count);
> > - }
> > }
> >
> > static __rte_always_inline void
> > @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev)
> > complete_async_pkts(vdev);
> > ret = rte_vhost_submit_enqueue_burst(vdev->vid,
> VIRTIO_RXQ,
> > m, nr_xmit, m_cpu_cpl,
> &cpu_cpl_nr);
> > - __atomic_add_fetch(&vdev->nr_async_pkts, ret -
> cpu_cpl_nr,
> > - __ATOMIC_SEQ_CST);
> >
> > if (cpu_cpl_nr)
> > free_pkts(m_cpu_cpl, cpu_cpl_nr); @@ -1210,9
> >> +1205,6 @@
> > drain_eth_rx(struct vhost_dev *vdev)
> > enqueue_count = rte_vhost_submit_enqueue_burst(vdev-
> > vid,
> >
Re: [dpdk-dev] [PATCH v3] common/mlx5: fix storing the synched MAC to internal table
> -Original Message- > From: Slava Ovsiienko > Sent: Wednesday, February 3, 2021 4:15 PM > To: Dey, Souvik ; Raslan Darawsheh > ; Matan Azrad > Cc: dev@dpdk.org; sta...@dpdk.org > Subject: RE: [PATCH v3] common/mlx5: fix storing the synched MAC to > internal table > > > back again, do you suggest me to submit v4 with with corrected quota > > character or its ok to have the v3 of the patch itself as you have already > > acked ? > > OK, let's ask Raslan to fix this minor issue while integrating the patch. > Raslan, could you, please, fix the quota character in the commit message? Sure, will handle on integration, > > With best regards, Slava > Kindest regards Raslan Darawsheh
[dpdk-dev] [PATCH v2] examples/vhost: add error propagation in ioat ops
It makes more sense to add error propagation for rte_ioat_completed_ops.
And change the type of dev_id from int to uint16_t.
Signed-off-by: Cheng Jiang
---
v2: mentioned dev_id type changes in git log
examples/vhost/ioat.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
index dbad28d43..60b73be93 100644
--- a/examples/vhost/ioat.c
+++ b/examples/vhost/ioat.c
@@ -22,7 +22,6 @@ struct packet_tracker {
struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
-
int
open_ioat(const char *value)
{
@@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
struct rte_vhost_async_status *opaque_data, uint16_t count)
{
uint32_t i_desc;
- int dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
+ uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
struct rte_vhost_iov_iter *src = NULL;
struct rte_vhost_iov_iter *dst = NULL;
unsigned long i_seg;
@@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid, uint16_t queue_id,
unsigned short mask = MAX_ENQUEUED_SIZE - 1;
unsigned short i;
- int dev_id = dma_bind[vid].dmas[queue_id * 2
+ uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
+ VIRTIO_RXQ].dev_id;
n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
- if (n_seg <= 0)
+ if (n_seg < 0) {
+ RTE_LOG(ERR,
+ VHOST_DATA,
+ "fail to poll completed buf on IOAT device %u",
+ dev_id);
+ return 0;
+ }
+ if (n_seg == 0)
return 0;
cb_tracker[dev_id].ioat_space += n_seg;
--
2.29.2
[dpdk-dev] [PATCH] net/pcap: fix infinite Rx with large files
Packet forwarding is not working when infinite Rx feature is used with
large .pcap files that has high number of packets.
The problem is number of allocated mbufs are less than the infinite Rx
ring size, and all mbufs consumed to fill the ring, so there is no mbuf
left for forwarding.
Current logic can not detect that infinite Rx ring is not filled
completely and no more mbufs left, and setup continues which leads
silent fail on packet forwarding.
There isn't much can be done when there is not enough mbuf for the given
.pcap file, so additional checks added to detect the case and fail
explicitly with an error log.
Bugzilla ID: 595
Fixes: a3f5252e5cbd ("net/pcap: enable infinitely Rx a pcap file")
Cc: sta...@dpdk.org
Reported-by: Cian Ferriter
Signed-off-by: Ferruh Yigit
---
drivers/net/pcap/rte_eth_pcap.c | 40 -
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index ff02ade70d1a..98f80368ca1d 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -735,6 +735,17 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static inline void
+infinite_rx_ring_free(struct rte_ring *pkts)
+{
+ struct rte_mbuf *bufs;
+
+ while (!rte_ring_dequeue(pkts, (void **)&bufs))
+ rte_pktmbuf_free(bufs);
+
+ rte_ring_free(pkts);
+}
+
static int
eth_dev_close(struct rte_eth_dev *dev)
{
@@ -753,7 +764,6 @@ eth_dev_close(struct rte_eth_dev *dev)
if (internals->infinite_rx) {
for (i = 0; i < dev->data->nb_rx_queues; i++) {
struct pcap_rx_queue *pcap_q = &internals->rx_queue[i];
- struct rte_mbuf *pcap_buf;
/*
* 'pcap_q->pkts' can be NULL if 'eth_dev_close()'
@@ -762,11 +772,7 @@ eth_dev_close(struct rte_eth_dev *dev)
if (pcap_q->pkts == NULL)
continue;
- while (!rte_ring_dequeue(pcap_q->pkts,
- (void **)&pcap_buf))
- rte_pktmbuf_free(pcap_buf);
-
- rte_ring_free(pcap_q->pkts);
+ infinite_rx_ring_free(pcap_q->pkts);
}
}
@@ -835,21 +841,25 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
while (eth_pcap_rx(pcap_q, bufs, 1)) {
/* Check for multiseg mbufs. */
if (bufs[0]->nb_segs != 1) {
- rte_pktmbuf_free(*bufs);
-
- while (!rte_ring_dequeue(pcap_q->pkts,
- (void **)bufs))
- rte_pktmbuf_free(*bufs);
-
- rte_ring_free(pcap_q->pkts);
- PMD_LOG(ERR, "Multiseg mbufs are not supported
in infinite_rx "
- "mode.");
+ infinite_rx_ring_free(pcap_q->pkts);
+ PMD_LOG(ERR,
+ "Multiseg mbufs are not supported in
infinite_rx mode.");
return -EINVAL;
}
rte_ring_enqueue_bulk(pcap_q->pkts,
(void * const *)bufs, 1, NULL);
}
+
+ if (rte_ring_count(pcap_q->pkts) < pcap_pkt_count) {
+ infinite_rx_ring_free(pcap_q->pkts);
+ PMD_LOG(ERR,
+ "Not enough mbuf to fill the infinite_rx ring. "
+ "At least %" PRIu64 " mbufs per queue is
required to fill the ring",
+ pcap_pkt_count);
+ return -EINVAL;
+ }
+
/*
* Reset the stats for this queue since eth_pcap_rx calls above
* didn't result in the application receiving packets.
--
2.29.2
Re: [dpdk-dev] [PATCH 1/1] doc: explain steps for improved code spell checking
03/02/2021 14:59, Bruce Richardson: > On Wed, Feb 03, 2021 at 01:53:58PM +0100, Thomas Monjalon wrote: > > 03/02/2021 13:18, Bruce Richardson: > > > On Wed, Feb 03, 2021 at 11:30:57AM +0100, Thomas Monjalon wrote: > > > > - > > > > https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt > > > > + git clone https://github.com/codespell-project/codespell.git > > > > > > > > > > Does installing via apt or dnf work as well? If we do install from package > > > do we still need to specify the path to codespell as script parameter? > > > > It depends whether all needed dictionary files are installed. Are they? > > > > > > -The path to the downloaded ``dictionary.txt`` must be set > > > > +There is a DPDK script to build an adjusted dictionary:: > > > > + > > > > + devtools/build-dict.sh codespell/ > codespell-dpdk.txt > > > > + > > > > > > Do we always need to have people build this themselves? Can we create a > > > .codespell-dpdk.txt file in the repo and have that as the default value > > > for > > > the path if the environment variable is not set? > > > > The dictionaries are frequently updated. > > I don't really want to update them in DPDK. > > > > The default dictionary from the distro is used by default (if installed). > > > > In general, I think only tree maintainers and CI admins > > have to install the dictionaries for better result. > > > That's good. Perhaps it's better to note down then first that the default > distro dictionaries are used and if one wants enhanced checking to follow > the extra steps. Yes I'll reword.
[dpdk-dev] [PATCH] net/virtio: fix secondary process crash with PCI devices
The Virtio rework series mistakenly moved the rte_pci_device
pointer to struct virtio_hw, which is shared between the two
processes. But this structure is per-process, so this change
made secondary process to try accessing primary process-only
memory, leading to a crash
This patch reverts to proper behavior, by storing the
rte_pci_device pointer into the pre-process
virtio_pci_internal struct. It provides also helper to get
the pointer from the virtio_hw struct pointer.
Bugzilla ID: 633
Fixes: c8d4b02f72ae ("net/virtio: move legacy IO to virtio PCI")
Reported-by: Anatoly Burakov
Signed-off-by: Maxime Coquelin
---
drivers/net/virtio/virtio_pci.c| 25 +
drivers/net/virtio/virtio_pci.h| 12 +++-
drivers/net/virtio/virtio_pci_ethdev.c | 2 ++
3 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index d27e9eb515..c14d1339c9 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -31,13 +31,6 @@
#define VIRTIO_PCI_CONFIG(dev) \
(((dev)->msix_status == VIRTIO_MSIX_ENABLED) ? 24 : 20)
-
-struct virtio_pci_internal {
- struct rte_pci_ioport io;
-};
-
-#define VTPCI_IO(hw) (&virtio_pci_internal[(hw)->port_id].io)
-
struct virtio_pci_internal virtio_pci_internal[RTE_MAX_ETHPORTS];
static inline int
@@ -313,16 +306,14 @@ legacy_intr_detect(struct virtio_hw *hw)
{
struct virtio_pci_dev *dev = virtio_pci_get_dev(hw);
- dev->msix_status = vtpci_msix_detect(dev->pci_dev);
+ dev->msix_status = vtpci_msix_detect(VTPCI_DEV(hw));
hw->intr_lsc = !!dev->msix_status;
}
static int
legacy_dev_close(struct virtio_hw *hw)
{
- struct virtio_pci_dev *dev = virtio_pci_get_dev(hw);
-
- rte_pci_unmap_device(dev->pci_dev);
+ rte_pci_unmap_device(VTPCI_DEV(hw));
rte_pci_ioport_unmap(VTPCI_IO(hw));
return 0;
@@ -574,16 +565,14 @@ modern_intr_detect(struct virtio_hw *hw)
{
struct virtio_pci_dev *dev = virtio_pci_get_dev(hw);
- dev->msix_status = vtpci_msix_detect(dev->pci_dev);
+ dev->msix_status = vtpci_msix_detect(VTPCI_DEV(hw));
hw->intr_lsc = !!dev->msix_status;
}
static int
modern_dev_close(struct virtio_hw *hw)
{
- struct virtio_pci_dev *dev = virtio_pci_get_dev(hw);
-
- rte_pci_unmap_device(dev->pci_dev);
+ rte_pci_unmap_device(VTPCI_DEV(hw));
return 0;
}
@@ -772,8 +761,6 @@ vtpci_init(struct rte_pci_device *pci_dev, struct
virtio_pci_dev *dev)
RTE_BUILD_BUG_ON(offsetof(struct virtio_pci_dev, hw) != 0);
- dev->pci_dev = pci_dev;
-
/*
* Try if we can succeed reading virtio pci caps, which exists
* only on modern pci device. If failed, we fallback to legacy
@@ -816,7 +803,5 @@ void vtpci_legacy_ioport_unmap(struct virtio_hw *hw)
int vtpci_legacy_ioport_map(struct virtio_hw *hw)
{
- struct virtio_pci_dev *dev = virtio_pci_get_dev(hw);
-
- return rte_pci_ioport_map(dev->pci_dev, 0, VTPCI_IO(hw));
+ return rte_pci_ioport_map(VTPCI_DEV(hw), 0, VTPCI_IO(hw));
}
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 57596e471f..11e25a0142 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -104,7 +104,6 @@ enum virtio_msix_status {
struct virtio_pci_dev {
struct virtio_hw hw;
- struct rte_pci_device *pci_dev;
struct virtio_pci_common_cfg *common_cfg;
struct virtio_net_config *dev_cfg;
enum virtio_msix_status msix_status;
@@ -116,6 +115,17 @@ struct virtio_pci_dev {
#define virtio_pci_get_dev(hwp) container_of(hwp, struct virtio_pci_dev, hw)
+struct virtio_pci_internal {
+ struct rte_pci_ioport io;
+ struct rte_pci_device *dev;
+};
+
+extern struct virtio_pci_internal virtio_pci_internal[RTE_MAX_ETHPORTS];
+
+#define VTPCI_IO(hw) (&virtio_pci_internal[(hw)->port_id].io)
+#define VTPCI_DEV(hw) (virtio_pci_internal[(hw)->port_id].dev)
+
+
/*
* How many bits to shift physical queue address written to QUEUE_PFN.
* 12 is historical, and due to x86 page size.
diff --git a/drivers/net/virtio/virtio_pci_ethdev.c
b/drivers/net/virtio/virtio_pci_ethdev.c
index 3bb5c6268b..4083853c48 100644
--- a/drivers/net/virtio/virtio_pci_ethdev.c
+++ b/drivers/net/virtio/virtio_pci_ethdev.c
@@ -78,12 +78,14 @@ eth_virtio_pci_init(struct rte_eth_dev *eth_dev)
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
hw->port_id = eth_dev->data->port_id;
+ VTPCI_DEV(hw) = pci_dev;
ret = vtpci_init(RTE_ETH_DEV_TO_PCI(eth_dev), dev);
if (ret) {
PMD_INIT_LOG(ERR, "Failed to init PCI device\n");
return -1;
}
} else {
+ VTPCI_DEV(hw) = pci_dev;
if (dev->modern)
VIRTIO_O
Re: [dpdk-dev] [PATCH v1 1/2] app/test: remove unnecessary barriers for ring stress test
>
> Hi Feifei,
>
> >
> > Hi, Honnappa, Konstantin and Stephen
> >
> > Thanks very much for your attention of this patch. Based on your
> > opinion, Ruifeng and I discuss about this and make a summary：
> >
> __
>
> > ___
> > ___
> > main thread
> worker thread
> > rte_eal_remote_launch:
> > [ Honnappa focus ]
> >
> > To ensure f can load correct arg,
> >
> > arg store should before f
> > lcore_config[worker_id].f = f;
> > lcore_config[worker_id].arg =
> arg;
> > wmb()? or store-relase on f?
> >
> >
> eal_thread_loop:
> > pipeline_communication
> --> pipeline_communication
> >
> if (lcore_config[lcore_id].f ==
> > NULL)
> >
> rte_panic("NULL function
> > pointer\n");
> >
> >
> fct_arg =
> > lcore_config[lcore_id].arg;
> >
> ret =
> > lcore_config[lcore_id].f(fct_arg);
> >
> __
>
> > ___
> > __
> >
> > test_ring_stress: wmb()?
> > [ Konstantin focus ]
> >
> test_worker:
> > Main thread can use wrk_cmd to
> > Wrk_cmd =WRK_CMD_RUN;
> --> Wrk_cmd == WRK_CMD_RUN;
> > control multiple threads to start running
> >
> wmb()?
> > at the same time as much as possible
> >
> ring_dequeue;
> >
> ring_enqueue;
> > Wrk_cmd =WRK_CMD_STOP;
> --> Wrk_cmd == WRK_CMD_STOP;
> >
> __
>
> > ___
> > ___
> >
> > rte_eal_wait_lcore:
> wmb()
> > [ Honnappa focus ]
> > lcore_config[lcore_id].state == FINISHED
> <- lcore_config[lcore_id].state =
> > FINISHEDLoad-acquire and store-release
> >
> > are used on the variable “state”
> > rmb();
> >
> __
>
> > ___
> > ___
> >
> > From the picture above,
> >
> > 1.First, for the underlying function rte_eal_remote_launch, Honnappa
> > focuses on that, pipeline_communication cannot ensure ‘arg’ parameters
> > is loaded correctly by the worker thread.
> > This is because in weak memory order framework, maybe the main thread
> > and worker thread firstly finish pipeline communication, and then the
> > worker thread receive signal and execute the function ‘ f ’. However,
> > it maybe load a wrong value of ‘arg’ due to that the main thread
> > stores ‘arg’ after pipeline communication. So wmb or store_release is
> necessary for ‘arg’.
> >
> > 2.Second, for the upper-layer test_ring_stress, Konstantin foucese on
> > that, Whether the main thread can use ‘wrk_cmd’ to control multiple
> > threads to run at the same time as much as possible.
> > Because rte_eal_remote_launch only can communicates with one worker
> > thread at the same time. This means some worker thread maybe start
> > working very early but other worker threads maybe need to wait a long
> > time to start working if ‘wrk_cmd' is stored 'RUN' flag before
> rte_remote_launch.
> > At last, for unit test, this may cause that the test results are not stable.
> >
> > 3.Third, for rte_eal_wait_lcore, Honnappa focuses on that the ‘state’ as a
> synchronous bariable,
> > we should add load-acquire and store-release on it. However, there
> > have been rmb and wmb after and before ‘state’, So I’m not sure whether
> we should replace them.
> >
> > In summary, I think Honnappa and Konstantin have different concerns.
> > For Honnappa, we can add wmb or store-release to ensure the ‘arg’ can
> > be loaded correctly in rte_eal_remote_launch.
> > For Konstantin, we can add wmb and rmb to ensure the main thread can
> > control the worker Threads to run at the same time, and then make the
> > test results more accurate in the ring_stress_test.
>
> Agree with both.
Thanks Feifei, understood. I am just trying to take a step back and see what
kind of ordering guarantees rte_eal_remote_launch should provide so that we do
not have to deal with adding additional barriers in the applications. For ex:
if we can avoid the barriers around 'wrk_cmd' (kind of use cases) it will
benefit all the applications.
>
> >
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
On 2/2/21 7:17 AM, Cheng Jiang wrote:
> Remove async inflight packet counter since there is no need to keep
> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment number
> tracking ring from being exhausted.
>
> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>
> Signed-off-by: Cheng Jiang
> ---
> v3: fixed fixes commit id in git log
>
> v2: fixed a typo
>
> examples/vhost/ioat.h | 2 +-
> examples/vhost/main.c | 10 +-
> examples/vhost/main.h | 1 -
> 3 files changed, 2 insertions(+), 11 deletions(-)
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2] examples/vhost: add error propagation in ioat ops
On 2/3/21 3:29 PM, Cheng Jiang wrote:
> It makes more sense to add error propagation for rte_ioat_completed_ops.
> And change the type of dev_id from int to uint16_t.
I would reword it to:
"
This patch adds add error propagation for rte_ioat_completed_ops call,
and also changes dev_id type from int to uint16_t.
"
Reviewed-by: Maxime Coquelin
>
> Signed-off-by: Cheng Jiang
> ---
> v2: mentioned dev_id type changes in git log
>
> examples/vhost/ioat.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
> index dbad28d43..60b73be93 100644
> --- a/examples/vhost/ioat.c
> +++ b/examples/vhost/ioat.c
> @@ -22,7 +22,6 @@ struct packet_tracker {
>
> struct packet_tracker cb_tracker[MAX_VHOST_DEVICE];
>
> -
> int
> open_ioat(const char *value)
> {
> @@ -129,7 +128,7 @@ ioat_transfer_data_cb(int vid, uint16_t queue_id,
> struct rte_vhost_async_status *opaque_data, uint16_t count)
> {
> uint32_t i_desc;
> - int dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2 + VIRTIO_RXQ].dev_id;
> struct rte_vhost_iov_iter *src = NULL;
> struct rte_vhost_iov_iter *dst = NULL;
> unsigned long i_seg;
> @@ -182,10 +181,17 @@ ioat_check_completed_copies_cb(int vid, uint16_t
> queue_id,
> unsigned short mask = MAX_ENQUEUED_SIZE - 1;
> unsigned short i;
>
> - int dev_id = dma_bind[vid].dmas[queue_id * 2
> + uint16_t dev_id = dma_bind[vid].dmas[queue_id * 2
> + VIRTIO_RXQ].dev_id;
> n_seg = rte_ioat_completed_ops(dev_id, 255, dump, dump);
> - if (n_seg <= 0)
> + if (n_seg < 0) {
> + RTE_LOG(ERR,
> + VHOST_DATA,
> + "fail to poll completed buf on IOAT device %u",
> + dev_id);
> + return 0;
> + }
> + if (n_seg == 0)
> return 0;
>
> cb_tracker[dev_id].ioat_space += n_seg;
> --
> 2.29.2
>
Re: [dpdk-dev] [PATCH v2] vhost: avoid iotlb mempool allocation while IOMMU disabled
Hi, On 2/2/21 9:38 AM, Wan Junjie wrote: > If vhost device's IOMMU feature is disabled, iotlb mempool allocation > is unnecessary. > > Reported-by: Peng He > Signed-off-by: Wan Junjie Welcome to the community, looking forward for more contributions! > Reviewed-by: Zhihong Wang And welcome back Zhihong! :) > --- > lib/librte_vhost/vhost.c | 4 ++-- > lib/librte_vhost/vhost_user.c | 6 +- > 2 files changed, 7 insertions(+), 3 deletions(-) > The patch looks good to me, however this is more an optimization than a fix. As we are late in the release cycle, I will postpone it to next release. Reviewed-by: Maxime Coquelin Thanks, Maxime
[dpdk-dev] [PATCH] event/dlb: fix bug accessing unitialized variable
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366200
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb/dlb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
index fd03f87..8b26d1d 100644
--- a/drivers/event/dlb/dlb.c
+++ b/drivers/event/dlb/dlb.c
@@ -3595,7 +3595,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_dir_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
--
1.7.10
[dpdk-dev] [PATCH] event/dlb: fix bug accessing unitialized variable
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366202
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb/dlb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
index b580dc9..fd03f87 100644
--- a/drivers/event/dlb/dlb.c
+++ b/drivers/event/dlb/dlb.c
@@ -3573,7 +3573,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_ldb_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
--
1.7.10
[dpdk-dev] [PATCH] event/dlb: fix bug accessing unitialized variable
Fixes: eb14a3421afd ("event/dlb: add eventdev start")
Coverity issue: 366205
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb/dlb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
index 64e6df7..b580dc9 100644
--- a/drivers/event/dlb/dlb.c
+++ b/drivers/event/dlb/dlb.c
@@ -1847,7 +1847,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_create_dir_queue_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int32_t ret;
cfg.response = (uintptr_t)&response;
--
1.7.10
Re: [dpdk-dev] [PATCH] event/dlb: fix bug accessing unitialized variable
On Wed, Feb 3, 2021 at 10:26 PM Timothy McDaniel
wrote:
>
Please add a comment and also squash the similar patches.
> Fixes: eb14a3421afd ("event/dlb: add eventdev start")
> Coverity issue: 366205
>
> Signed-off-by: Timothy McDaniel
> ---
> drivers/event/dlb/dlb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
> index 64e6df7..b580dc9 100644
> --- a/drivers/event/dlb/dlb.c
> +++ b/drivers/event/dlb/dlb.c
> @@ -1847,7 +1847,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
> *dlb)
> {
> struct dlb_hw_dev *handle = &dlb->qm_instance;
> struct dlb_create_dir_queue_args cfg;
> - struct dlb_cmd_response response;
> + struct dlb_cmd_response response = {0};
> int32_t ret;
>
> cfg.response = (uintptr_t)&response;
> --
> 1.7.10
>
Re: [dpdk-dev] [PATCH] net/virtio: fix secondary process crash with PCI devices
On Wed, Feb 3, 2021 at 4:58 PM Maxime Coquelin
wrote:
>
> The Virtio rework series mistakenly moved the rte_pci_device
> pointer to struct virtio_hw, which is shared between the two
> processes. But this structure is per-process, so this change
> made secondary process to try accessing primary process-only
> memory, leading to a crash
crash.*
Ah the joy of multiprocess support :-).
>
> This patch reverts to proper behavior, by storing the
> rte_pci_device pointer into the pre-process
per*
> virtio_pci_internal struct. It provides also helper to get
also provides*
> the pointer from the virtio_hw struct pointer.
>
> Bugzilla ID: 633
> Fixes: c8d4b02f72ae ("net/virtio: move legacy IO to virtio PCI")
>
> Reported-by: Anatoly Burakov
> Signed-off-by: Maxime Coquelin
The patch lgtm.
Reviewed-by: David Marchand
Thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] net/virtio: fix secondary process crash with PCI devices
On 2/3/21 4:58 PM, Maxime Coquelin wrote:
> The Virtio rework series mistakenly moved the rte_pci_device
> pointer to struct virtio_hw, which is shared between the two
> processes. But this structure is per-process, so this change
> made secondary process to try accessing primary process-only
> memory, leading to a crash
>
> This patch reverts to proper behavior, by storing the
> rte_pci_device pointer into the pre-process
> virtio_pci_internal struct. It provides also helper to get
> the pointer from the virtio_hw struct pointer.
>
> Bugzilla ID: 633
> Fixes: c8d4b02f72ae ("net/virtio: move legacy IO to virtio PCI")
>
> Reported-by: Anatoly Burakov
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/virtio/virtio_pci.c| 25 +
> drivers/net/virtio/virtio_pci.h| 12 +++-
> drivers/net/virtio/virtio_pci_ethdev.c | 2 ++
> 3 files changed, 18 insertions(+), 21 deletions(-)
>
Applied to dpdk-next-virtio/main with typo fixed.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2] examples/vhost: add error propagation in ioat ops
On 2/3/21 3:29 PM, Cheng Jiang wrote: > |It makes more sense to add error propagation for > rte_ioat_completed_ops. And change the type of dev_id from int to > uint16_t. Signed-off-by: Cheng Jiang --- v2: > mentioned dev_id type changes in git log examples/vhost/ioat.c | 14 > ++ 1 file changed, 10 insertions(+), 4 deletions(-)| Applied to dpdk-next-virtio/main with commit message fixed. Thanks, Maxime
Re: [dpdk-dev] [PATCH v2] examples/vhost: fix potentially overflowing expression
On 2/2/21 8:24 AM, Cheng Jiang wrote:
> |Change the type of buff_idx from uint64_t to uint32_t to fix coverity
> issue. Coverity issue: 366264 Fixes: a68ba8e0a6b6 ("examples/vhost:
> refactor vhost data path") Signed-off-by: Cheng Jiang
> --- v2: fixed the format of git log
> examples/vhost/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)|
Applied to dpdk-next-virtio/main with typo fixed.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter
On 2/3/21 5:27 PM, Maxime Coquelin wrote:
>
>
> On 2/2/21 7:17 AM, Cheng Jiang wrote:
>> Remove async inflight packet counter since there is no need to keep
>> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment number
>> tracking ring from being exhausted.
>>
>> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path")
>>
>> Signed-off-by: Cheng Jiang
>> ---
>> v3: fixed fixes commit id in git log
>>
>> v2: fixed a typo
>>
>> examples/vhost/ioat.h | 2 +-
>> examples/vhost/main.c | 10 +-
>> examples/vhost/main.h | 1 -
>> 3 files changed, 2 insertions(+), 11 deletions(-)
>>
>
> Reviewed-by: Maxime Coquelin
>
> Thanks,
> Maxime
>
Applied to dpdk-next-virtio/main.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2] vhost: fix vid allocation race
On 2/1/21 9:48 AM, Peng He wrote:
> vhost_new_device might be called in different threads at the same time.
> thread 1(config thread)
> rte_vhost_driver_start
>->vhost_user_start_client
>->vhost_user_add_connection
> -> vhost_new_device
>
> thread 2(vhost-events)
> vhost_user_read_cb
>->vhost_user_msg_handler (return value < 0)
> -> vhost_user_start_client
> -> vhost_new_device
>
> So there could be a case that a same vid has been allocated twice, or
> some vid might be lost in DPDK lib however still held by the upper
> applications.
>
> Another place where race would happen is at the func *vhost_destroy_device*,
> but after a detailed investigation, the race does not exist as long as
> no two devices have the same vid: Calling vhost_destroy_devices in
> different threads with different vids is actually safe.
>
> Fixes: a277c715987 ("vhost: refactor code structure")
> Reported-by: Peng He
> Signed-off-by: Fei Chen
> Reviewed-by: Zhihong Wang
> ---
> lib/librte_vhost/vhost.c | 6 ++
> 1 file changed, 6 insertions(+)
Applied to dpdk-next-virtio/main.
Thanks,
Maxime
[dpdk-dev] [PATCH] net/pcap: fix byte stats for drop Tx
Drop Tx path in pcap is Tx that just drops the packets, which is used
for the case only Rx from a pcap file is requested/matters.
The byte stats was calculated using first mbuf segment, which gives
wrong values for multi segmented mbufs, updated to use packet length
instead.
Bugzilla ID: 597
Fixes: a3f5252e5cbd ("net/pcap: enable infinitely Rx a pcap file")
Cc: sta...@dpdk.org
Reported-by: Cian Ferriter
Signed-off-by: Ferruh Yigit
---
drivers/net/pcap/rte_eth_pcap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index ff02ade70d1a..c7751b7ba742 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -386,7 +386,7 @@ eth_tx_drop(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
return 0;
for (i = 0; i < nb_pkts; i++) {
- tx_bytes += bufs[i]->data_len;
+ tx_bytes += bufs[i]->pkt_len;
rte_pktmbuf_free(bufs[i]);
}
--
2.29.2
[dpdk-dev] [PATCH] event/dlb: fix bugs due to accessing unitialized variables
This patch updates the PMD to initialize response fields
prior to calling into the PF layer.
Fixes the following coverity issues:
Fixes: eb14a3421afd ("event/dlb: add eventdev start")
Coverity issue: 366205
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366202
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366200
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb/dlb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
index 64e6df7..8b26d1d 100644
--- a/drivers/event/dlb/dlb.c
+++ b/drivers/event/dlb/dlb.c
@@ -1847,7 +1847,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_create_dir_queue_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int32_t ret;
cfg.response = (uintptr_t)&response;
@@ -3573,7 +3573,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_ldb_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
@@ -3595,7 +3595,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_dir_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
--
1.7.10
[dpdk-dev] [PATCH] event/dlb: fix bugs due to accessing uninitialized variables
This patch updates the PMD to initialize response fields
prior to calling into the PF layer.
Fixes the following coverity issues:
Fixes: eb14a3421afd ("event/dlb: add eventdev start")
Coverity issue: 366205
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366202
Fixes: f0073621940c ("event/dlb: add eventdev stop and close")
Coverity issue: 366200
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb/dlb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/event/dlb/dlb.c b/drivers/event/dlb/dlb.c
index 64e6df7..8b26d1d 100644
--- a/drivers/event/dlb/dlb.c
+++ b/drivers/event/dlb/dlb.c
@@ -1847,7 +1847,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_create_dir_queue_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int32_t ret;
cfg.response = (uintptr_t)&response;
@@ -3573,7 +3573,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_ldb_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
@@ -3595,7 +3595,7 @@ static int dlb_num_dir_queues_setup(struct dlb_eventdev
*dlb)
{
struct dlb_hw_dev *handle = &dlb->qm_instance;
struct dlb_get_dir_queue_depth_args cfg;
- struct dlb_cmd_response response;
+ struct dlb_cmd_response response = {0};
int ret;
cfg.queue_id = queue->qm_queue.id;
--
1.7.10
[dpdk-dev] [PATCH v3 1/1] ethdev: refine doxygen comment of UDP tunnel API
From: Qi Zhang
Clarify what is the scope and impact of the UDP port tunnel API.
There are still missing infos to be improved in future:
- no capability flag
- dependency between ports of the same device
- required privilege
Signed-off-by: Qi Zhang
Signed-off-by: Thomas Monjalon
---
v2 (Qi): focus on API impact based on previous discussion
v3 (Thomas): reword more lines, in functions, struct and enum
---
lib/librte_ethdev/rte_ethdev.h | 57 --
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 667373f06f..059a061072 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1214,7 +1214,8 @@ struct rte_eth_pfc_conf {
};
/**
- * Tunneled type.
+ * Tunnel type for device-specific classifier configuration.
+ * @see rte_eth_udp_tunnel
*/
enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NONE = 0,
@@ -1270,14 +1271,16 @@ struct rte_fdir_conf {
/**
* UDP tunneling configuration.
- * Used to config the UDP port for a type of tunnel.
- * NICs need the UDP port to identify the tunnel type.
- * Normally a type of tunnel has a default UDP port, this structure can be used
- * in case if the users want to change or support more UDP port.
+ *
+ * Used to configure the classifier of a device,
+ * associating an UDP port with a type of tunnel.
+ *
+ * Some NICs may need such configuration to properly parse a tunnel
+ * with any standard or custom UDP port.
*/
struct rte_eth_udp_tunnel {
uint16_t udp_port; /**< UDP port used for the tunnel. */
- uint8_t prot_type; /**< Tunnel type. Defined in rte_eth_tunnel_type. */
+ uint8_t prot_type; /**< Tunnel type. @see rte_eth_tunnel_type */
};
/**
@@ -3868,7 +3871,7 @@ int rte_eth_dev_rss_reta_update(uint16_t port_id,
struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size);
- /**
+/**
* Query Redirection Table(RETA) of Receive Side Scaling of Ethernet device.
*
* @param port_id
@@ -3890,7 +3893,7 @@ int rte_eth_dev_rss_reta_query(uint16_t port_id,
struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size);
- /**
+/**
* Updates unicast hash table for receiving packet with the given destination
* MAC address, and the packet is routed to all VFs for which the RX mode is
* accept packets that match the unicast hash table.
@@ -3912,7 +3915,7 @@ int rte_eth_dev_rss_reta_query(uint16_t port_id,
int rte_eth_dev_uc_hash_table_set(uint16_t port_id, struct rte_ether_addr
*addr,
uint8_t on);
- /**
+/**
* Updates all unicast hash bitmaps for receiving packet with any Unicast
* Ethernet MAC addresses,the packet is routed to all VFs for which the RX
* mode is accept packets that match the unicast hash table.
@@ -3995,7 +3998,7 @@ int rte_eth_mirror_rule_reset(uint16_t port_id,
int rte_eth_set_queue_rate_limit(uint16_t port_id, uint16_t queue_idx,
uint16_t tx_rate);
- /**
+/**
* Configuration of Receive Side Scaling hash computation of Ethernet device.
*
* @param port_id
@@ -4012,7 +4015,7 @@ int rte_eth_set_queue_rate_limit(uint16_t port_id,
uint16_t queue_idx,
int rte_eth_dev_rss_hash_update(uint16_t port_id,
struct rte_eth_rss_conf *rss_conf);
- /**
+/**
* Retrieve current configuration of Receive Side Scaling hash computation
* of Ethernet device.
*
@@ -4030,12 +4033,18 @@ int
rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
struct rte_eth_rss_conf *rss_conf);
- /**
- * Add UDP tunneling port for a specific type of tunnel.
- * The packets with this UDP port will be identified as this type of tunnel.
- * Before enabling any offloading function for a tunnel, users can call this
API
- * to change or add more UDP port for the tunnel. So the offloading function
- * can take effect on the packets with the specific UDP port.
+/**
+ * Add UDP tunneling port for a type of tunnel.
+ *
+ * Some NICs may require such configuration to properly parse a tunnel
+ * with any standard or custom UDP port.
+ * The packets with this UDP port will be parsed for this type of tunnel.
+ * The device parser will also check the rest of the tunnel headers
+ * before classifying the packet.
+ *
+ * With some devices, this API will affect packet classification, i.e.:
+ * - mbuf.packet_type reported on Rx
+ * - rte_flow rules with tunnel items
*
* @param port_id
* The port identifier of the Ethernet device.
@@ -4052,13 +4061,13 @@ int
rte_eth_dev_udp_tunnel_port_add(uint16_t port_id,
struct rte_eth_udp_tunnel *tunnel_udp);
- /**
- * Delete UDP tunneling port a specific type of tunnel.
- * The packets with this UDP port will not be identified as this type of tunnel
-
[dpdk-dev] [PATCH] config: increase default maximum number of NUMA nodes
AMD CPU can present a high number of NUMA nodes.
The default should be 32 for better compatibility.
Signed-off-by: Thomas Monjalon
---
meson_options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson_options.txt b/meson_options.txt
index 5c382487da..6eff62e47d 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -26,7 +26,7 @@ option('max_ethports', type: 'integer', value: 32,
description: 'maximum number of Ethernet devices')
option('max_lcores', type: 'integer', value: 128,
description: 'maximum number of cores/threads supported by EAL')
-option('max_numa_nodes', type: 'integer', value: 4,
+option('max_numa_nodes', type: 'integer', value: 32,
description: 'maximum number of NUMA nodes supported by EAL')
option('enable_trace_fp', type: 'boolean', value: false,
description: 'enable fast path trace points.')
--
2.30.0
[dpdk-dev] [PATCH] eal/ppc: add ppc specific TSC frequency value
Return a PPC specific value for get_tsc_freq_arch() rather than
depending on the EAL framework to estimate the frequency.
Signed-off-by: David Christensen
---
lib/librte_eal/ppc/rte_cycles.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/ppc/rte_cycles.c b/lib/librte_eal/ppc/rte_cycles.c
index c96a2143b..9359ac50b 100644
--- a/lib/librte_eal/ppc/rte_cycles.c
+++ b/lib/librte_eal/ppc/rte_cycles.c
@@ -2,10 +2,11 @@
* Copyright (C) IBM Corporation 2019.
*/
+#include
#include "eal_private.h"
uint64_t
get_tsc_freq_arch(void)
{
- return 0;
+ return __ppc_get_timebase_freq();
}
--
2.27.0
[dpdk-dev] [PATCH v3 1/1] net/pcap: imissed stats support
get value from pcap_stats.ps_drop (see man pcap_stats)
the value is adjusted in this cases:
- port stop - pcap is closed and will lose count
- stats reset - pcap doesn't provide reset api
- rollover - pcap counter size is u_32 only
Signed-off-by: Ido Goshen
---
v3:
* code cleanup by dedicated struct and functions extraction
* multi stop support by menmonic+= accumulation
* rollover fixup
v2:
* sum all queues (rx_missed_total += fix)
* null pcap protection
* inter stop/start persistancy (counter won't reset on stop)
drivers/net/pcap/rte_eth_pcap.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index a32b1f3f3..16e8752f3 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -60,11 +60,21 @@ struct queue_stat {
volatile unsigned long err_pkts;
};
+struct queue_missed_stat {
+ /* last value retrieved from pcap */
+ volatile unsigned int pcap;
+ /* stores values lost by pcap stop or rollover */
+ volatile unsigned long mnemonic;
+ /* value on last reset */
+ volatile unsigned long reset;
+};
+
struct pcap_rx_queue {
uint16_t port_id;
uint16_t queue_id;
struct rte_mempool *mb_pool;
struct queue_stat rx_stat;
+ struct queue_missed_stat missed_stat;
char name[PATH_MAX];
char type[ETH_PCAP_ARG_MAXLEN];
@@ -144,6 +154,49 @@ RTE_LOG_REGISTER(eth_pcap_logtype, pmd.net.pcap, NOTICE);
rte_log(RTE_LOG_ ## level, eth_pcap_logtype, \
"%s(): " fmt "\n", __func__, ##args)
+static struct queue_missed_stat*
+queue_missed_stat_update(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ struct queue_missed_stat *missed_stat =
+ &internals->rx_queue[qid].missed_stat;
+ const struct pmd_process_private *pp = dev->process_private;
+ pcap_t *pcap = pp->rx_pcap[qid];
+ struct pcap_stat stat;
+ if (!pcap || (pcap_stats(pcap, &stat) != 0))
+ return missed_stat;
+ /* rollover check - best effort fixup assuming single rollover */
+ if (stat.ps_drop < missed_stat->pcap)
+ missed_stat->mnemonic += UINT_MAX;
+ missed_stat->pcap = stat.ps_drop;
+ return missed_stat;
+}
+
+static void
+queue_missed_stat_on_stop_update(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ missed_stat->mnemonic += missed_stat->pcap;
+}
+
+static void
+queue_missed_stat_reset(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ missed_stat->reset = missed_stat->pcap;
+ missed_stat->mnemonic = 0;
+}
+
+static unsigned long
+queue_missed_stat_get(struct rte_eth_dev *dev, unsigned int qid)
+{
+ const struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ return missed_stat->pcap + missed_stat->mnemonic - missed_stat->reset;
+}
+
static int
eth_pcap_rx_jumbo(struct rte_mempool *mb_pool, struct rte_mbuf *mbuf,
const u_char *data, uint16_t data_len)
@@ -621,6 +674,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
/* Special iface case. Single pcap is open and shared between tx/rx. */
if (internals->single_iface) {
+ queue_missed_stat_on_stop_update(dev, 0);
pcap_close(pp->tx_pcap[0]);
pp->tx_pcap[0] = NULL;
pp->rx_pcap[0] = NULL;
@@ -641,6 +695,7 @@ eth_dev_stop(struct rte_eth_dev *dev)
for (i = 0; i < dev->data->nb_rx_queues; i++) {
if (pp->rx_pcap[i] != NULL) {
+ queue_missed_stat_on_stop_update(dev, i);
pcap_close(pp->rx_pcap[i]);
pp->rx_pcap[i] = NULL;
}
@@ -685,6 +740,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats
*stats)
{
unsigned int i;
unsigned long rx_packets_total = 0, rx_bytes_total = 0;
+ unsigned long rx_missed_total = 0;
unsigned long tx_packets_total = 0, tx_bytes_total = 0;
unsigned long tx_packets_err_total = 0;
const struct pmd_internals *internal = dev->data->dev_private;
@@ -695,6 +751,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats
*stats)
stats->q_ibytes[i] = internal->rx_queue[i].rx_stat.bytes;
rx_packets_total += stats->q_ipackets[i];
rx_bytes_total += stats->q_ibytes[i];
+ rx_missed_total += queue_missed_stat_get(dev, i);
}
for (i = 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS &&
@@ -708,6 +765,7 @@ eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats
*stats)
stats-
Re: [dpdk-dev] [PATCH v3 1/1] net/pcap: imissed stats support
On 2/3/2021 11:07 PM, Ido Goshen wrote:
get value from pcap_stats.ps_drop (see man pcap_stats)
the value is adjusted in this cases:
- port stop - pcap is closed and will lose count
- stats reset - pcap doesn't provide reset api
- rollover - pcap counter size is u_32 only
Signed-off-by: Ido Goshen
---
v3:
* code cleanup by dedicated struct and functions extraction
* multi stop support by menmonic+= accumulation
* rollover fixup
v2:
* sum all queues (rx_missed_total += fix)
* null pcap protection
* inter stop/start persistancy (counter won't reset on stop)
drivers/net/pcap/rte_eth_pcap.c | 59 +
1 file changed, 59 insertions(+)
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index a32b1f3f3..16e8752f3 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -60,11 +60,21 @@ struct queue_stat {
volatile unsigned long err_pkts;
};
+struct queue_missed_stat {
+ /* last value retrieved from pcap */
+ volatile unsigned int pcap;
+ /* stores values lost by pcap stop or rollover */
+ volatile unsigned long mnemonic;
+ /* value on last reset */
+ volatile unsigned long reset;
+};
I am aware other stats has 'volatile' keyword, but as far as I can see it is not
needed, since these are new ones can you please drop the 'volatile'?
+
struct pcap_rx_queue {
uint16_t port_id;
uint16_t queue_id;
struct rte_mempool *mb_pool;
struct queue_stat rx_stat;
+ struct queue_missed_stat missed_stat;
char name[PATH_MAX];
char type[ETH_PCAP_ARG_MAXLEN];
@@ -144,6 +154,49 @@ RTE_LOG_REGISTER(eth_pcap_logtype, pmd.net.pcap, NOTICE);
rte_log(RTE_LOG_ ## level, eth_pcap_logtype, \
"%s(): " fmt "\n", __func__, ##args)
+static struct queue_missed_stat*
+queue_missed_stat_update(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct pmd_internals *internals = dev->data->dev_private;
+ struct queue_missed_stat *missed_stat =
+ &internals->rx_queue[qid].missed_stat;
+ const struct pmd_process_private *pp = dev->process_private;
+ pcap_t *pcap = pp->rx_pcap[qid];
+ struct pcap_stat stat;
Can you please put an empty line after variable declarations, and before return.
+ if (!pcap || (pcap_stats(pcap, &stat) != 0))
+ return missed_stat;
+ /* rollover check - best effort fixup assuming single rollover */
+ if (stat.ps_drop < missed_stat->pcap)
+ missed_stat->mnemonic += UINT_MAX;
+ missed_stat->pcap = stat.ps_drop;
here.
+ return missed_stat;
+}
+
+static void
+queue_missed_stat_on_stop_update(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ missed_stat->mnemonic += missed_stat->pcap;
Better to reset 'missed_stat->pcap' afterwards, in case stats requested before
port started again:
missed_stat->pcap = 0;
+}
+
+static void
+queue_missed_stat_reset(struct rte_eth_dev *dev, unsigned int qid)
+{
+ struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ missed_stat->reset = missed_stat->pcap;
I guess this should be:
"missed_stat->reset = missed_stat->pcap + missed_stat->mnemonic;"
+ missed_stat->mnemonic = 0;
+}
+
+static unsigned long
+queue_missed_stat_get(struct rte_eth_dev *dev, unsigned int qid)
+{
+ const struct queue_missed_stat *missed_stat =
+ queue_missed_stat_update(dev, qid);
+ return missed_stat->pcap + missed_stat->mnemonic - missed_stat->reset;
+}
+
<...>
