Re: [PATCH v2 1/4] eal/windows: translate Windows errors to errno-style errors
On Tue, Apr 12, 2022 at 12:44 PM Tyler Retzlaff wrote: > > Add function to translate Windows error codes to errno-style error > codes. The possible return values are chosen so that we have as > much semantical compatibility between platforms as possible. > > Signed-off-by: Narcisa Vasile > Signed-off-by: Tyler Retzlaff This patch alone does not make sense, and I guess it breaks compilation on Windows if we stop at it during a bisect (because it adds two unused static symbols). It can be squashed in patch 3 where thread_log_last_error is first used. -- David Marchand
Re: [PATCH v3 2/4] eal: add basic thread ID and current thread identifier API
On Wed, Apr 13, 2022 at 9:43 AM Tyler Retzlaff
wrote:
>
> Provide a portable type-safe thread identifier.
> Provide rte_thread_self for obtaining current thread identifier.
>
> Signed-off-by: Narcisa Vasile
> Signed-off-by: Tyler Retzlaff
> ---
> lib/eal/include/rte_thread.h | 22 ++
> lib/eal/unix/rte_thread.c| 11 +++
> lib/eal/version.map | 3 +++
> lib/eal/windows/rte_thread.c | 10 ++
> 4 files changed, 46 insertions(+)
>
> diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> index 8be8ed8..fb66d9a 100644
> --- a/lib/eal/include/rte_thread.h
> +++ b/lib/eal/include/rte_thread.h
> @@ -1,7 +1,10 @@
> /* SPDX-License-Identifier: BSD-3-Clause
> * Copyright(c) 2021 Mellanox Technologies, Ltd
> + * Copyright (C) 2022 Microsoft Corporation
> */
>
> +#include
> +
> #include
> #include
>
> @@ -21,10 +24,29 @@
> #endif
>
> /**
> + * Thread id descriptor.
> + */
> +typedef struct rte_thread_tag {
Is there a need for rte_thread_tag.
I don't see it used.
--
David Marchand
Re: [PATCH v3 3/4] eal: implement functions for get/set thread affinity
On Wed, Apr 13, 2022 at 9:43 AM Tyler Retzlaff
wrote:
>
> Implement functions for getting/setting thread affinity.
> Threads can be pinned to specific cores by setting their
> affinity attribute.
>
> note: rte_convert_cpuset_to_affinity has a limitation that all cpus of
> the set belong to the same processor group.
>
> Signed-off-by: Narcisa Vasile
> Signed-off-by: Tyler Retzlaff
[snip]
> diff --git a/lib/eal/windows/rte_thread.c b/lib/eal/windows/rte_thread.c
> index d730bb4..032b09f 100644
> --- a/lib/eal/windows/rte_thread.c
> +++ b/lib/eal/windows/rte_thread.c
> @@ -6,7 +6,8 @@
> #include
> #include
> #include
> -#include
> +
> +#include "eal_windows.h"
>
> struct eal_tls_key {
> DWORD thread_index;
> @@ -146,3 +147,131 @@ struct eal_tls_key {
> }
> return output;
> }
> +
> +static int
> +rte_convert_cpuset_to_affinity(const rte_cpuset_t *cpuset,
> + PGROUP_AFFINITY affinity)
This is Windows only, static code.
Please don't use rte_ prefix.
For static code, I see no need for a prefix at all.
--
David Marchand
Re: [PATCH v3] eal/windows: set Windows main lcore affinitization
On Thu, Apr 14, 2022 at 3:08 PM David Marchand wrote: > > On Thu, Apr 14, 2022 at 2:43 PM Tyler Retzlaff > wrote: > > > > Add missing code to affinitize main_lcore from lcore configuration. > > > > Signed-off-by: Tyler Retzlaff > Reviewed-by: David Marchand Applied, thanks. -- David Marchand
Re: [PATCH] ethdev: prohibit polling of a stopped queue
10/04/2022 23:35, Dmitry Kozlyuk:
> Whether it is allowed to call Rx/Tx functions for a stopped queue
> was undocumented. Some PMDs make this behavior a no-op
> either by explicitly checking the queue state
> or by the way how their routines are implemented or HW works.
>
> No-op behavior may be convenient for application developers.
> But it also means that pollers of stopped queues
> would go all the way down to PMD Rx/Tx routines, wasting cycles.
> Some PMDs would do a check for the queue state on data path,
> even though it may never be needed for a particular application.
> Also, use cases for stopping queues or starting them deferred
> do not logically require polling stopped queues.
>
> Use case 1: a secondary that was polling the queue has crashed,
> the primary is doing a recovery to free all mbufs.
> By definition the queue to be restarted is not polled.
>
> Use case 2: deferred queue start or queue reconfiguration.
> The polling thread must be synchronized anyway,
> because queue start and stop are non-atomic.
>
> Prohibit calling Rx/Tx functions on stopped queues.
>
> Fixes: 0748be2cf9a2 ("ethdev: queue start and stop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dmitry Kozlyuk
> ---
> This patch is was originally a part of the series:
> http://patchwork.dpdk.org/project/dpdk/patch/20220307125351.697936-3-dkozl...@nvidia.com/
> The discussion there is summarized in the commit message.
[...]
> * rte_eth_rx_queue_setup()), it must call rte_eth_dev_stop() first to stop
> the
> * device and then do the reconfiguration before calling rte_eth_dev_start()
> * again. The transmit and receive functions should not be invoked when the
> - * device is stopped.
> + * device is stopped or when the queue is stopped (for that queue).
I think we can make it simpler:
The transmit and receive functions should not be invoked when the device
or the queue is stopped.
[PATCH] net/iavf: when E810 VF interrupt disable, only receive 4 packets once, fix 4 to 1.
For Rx-Queue Interrupt Setting, when vf rx interrupt disable(INTENA=0), there are two ways to write back descriptor to host memory: 1)Set WB_ON_ITR bit 0 to Interrupt Dynamic Control Register: Completed descriptors are posted to host memory according to the internal descriptor cache policy (in other words when a full cache line is available for write-back). 2)Set WB_ON_ITR bit 1 to Interrupt Dynamic Control Register: Completed descriptors also trigger the ITR. Following ITR expiration, all leftover completed descriptors are posted to host memory. Changing 1) to 2) to make sure VF synchronizing with PF. Signed-off-by: Ke Zhang --- drivers/net/iavf/iavf_ethdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c index d6190ac24a..17c7720600 100644 --- a/drivers/net/iavf/iavf_ethdev.c +++ b/drivers/net/iavf/iavf_ethdev.c @@ -1833,7 +1833,7 @@ iavf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev, uint16_t queue_id) IAVF_WRITE_REG(hw, IAVF_VFINT_DYN_CTLN1(msix_intr - IAVF_RX_VEC_START), - 0); + IAVF_VFINT_DYN_CTLN1_WB_ON_ITR_MASK); IAVF_WRITE_FLUSH(hw); return 0; -- 2.25.1
Re: [PATCH v2 1/4] eal/windows: translate Windows errors to errno-style errors
On Mon, Apr 25, 2022 at 10:25:30AM +0200, David Marchand wrote: > On Tue, Apr 12, 2022 at 12:44 PM Tyler Retzlaff > wrote: > > > > Add function to translate Windows error codes to errno-style error > > codes. The possible return values are chosen so that we have as > > much semantical compatibility between platforms as possible. > > > > Signed-off-by: Narcisa Vasile > > Signed-off-by: Tyler Retzlaff > > This patch alone does not make sense, and I guess it breaks > compilation on Windows if we stop at it during a bisect (because it > adds two unused static symbols). interesting, didn't happen locally but i can see that it should have. > It can be squashed in patch 3 where thread_log_last_error is first used. yep, makes sense to me. i'll push a new version. thanks
Re: [PATCH v3 2/4] eal: add basic thread ID and current thread identifier API
On Mon, Apr 25, 2022 at 10:26:42AM +0200, David Marchand wrote:
> On Wed, Apr 13, 2022 at 9:43 AM Tyler Retzlaff
> wrote:
> >
> > Provide a portable type-safe thread identifier.
> > Provide rte_thread_self for obtaining current thread identifier.
> >
> > Signed-off-by: Narcisa Vasile
> > Signed-off-by: Tyler Retzlaff
> > ---
> > lib/eal/include/rte_thread.h | 22 ++
> > lib/eal/unix/rte_thread.c| 11 +++
> > lib/eal/version.map | 3 +++
> > lib/eal/windows/rte_thread.c | 10 ++
> > 4 files changed, 46 insertions(+)
> >
> > diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> > index 8be8ed8..fb66d9a 100644
> > --- a/lib/eal/include/rte_thread.h
> > +++ b/lib/eal/include/rte_thread.h
> > @@ -1,7 +1,10 @@
> > /* SPDX-License-Identifier: BSD-3-Clause
> > * Copyright(c) 2021 Mellanox Technologies, Ltd
> > + * Copyright (C) 2022 Microsoft Corporation
> > */
> >
> > +#include
> > +
> > #include
> > #include
> >
> > @@ -21,10 +24,29 @@
> > #endif
> >
> > /**
> > + * Thread id descriptor.
> > + */
> > +typedef struct rte_thread_tag {
>
> Is there a need for rte_thread_tag.
> I don't see it used.
i don't think so. it was part of the original series i'll remove it.
>
>
> --
> David Marchand
Re: [PATCH v3 3/4] eal: implement functions for get/set thread affinity
On Mon, Apr 25, 2022 at 10:26:58AM +0200, David Marchand wrote:
> On Wed, Apr 13, 2022 at 9:43 AM Tyler Retzlaff
> wrote:
> >
> > Implement functions for getting/setting thread affinity.
> > Threads can be pinned to specific cores by setting their
> > affinity attribute.
> >
> > note: rte_convert_cpuset_to_affinity has a limitation that all cpus of
> > the set belong to the same processor group.
> >
> > Signed-off-by: Narcisa Vasile
> > Signed-off-by: Tyler Retzlaff
>
> [snip]
>
> > diff --git a/lib/eal/windows/rte_thread.c b/lib/eal/windows/rte_thread.c
> > index d730bb4..032b09f 100644
> > --- a/lib/eal/windows/rte_thread.c
> > +++ b/lib/eal/windows/rte_thread.c
> > @@ -6,7 +6,8 @@
> > #include
> > #include
> > #include
> > -#include
> > +
> > +#include "eal_windows.h"
> >
> > struct eal_tls_key {
> > DWORD thread_index;
> > @@ -146,3 +147,131 @@ struct eal_tls_key {
> > }
> > return output;
> > }
> > +
> > +static int
> > +rte_convert_cpuset_to_affinity(const rte_cpuset_t *cpuset,
> > + PGROUP_AFFINITY affinity)
>
> This is Windows only, static code.
> Please don't use rte_ prefix.
>
> For static code, I see no need for a prefix at all.
agreed. will fix in next revision.
>
>
> --
> David Marchand
RE: [v4 1/3] ethdev: introduce protocol type based header split
Hi Andrew, > -Original Message- > From: Andrew Rybchenko > Sent: Wednesday, April 20, 2022 10:40 PM > To: Ding, Xuan ; Jerin Jacob ; > Wu, WenxuanX > Cc: Thomas Monjalon ; Li, Xiaoyun > ; Singh, Aman Deep ; > Zhang, Yuying ; Zhang, Qi Z > ; dpdk-dev ; Stephen Hemminger > ; Morten Brørup > ; Viacheslav Ovsiienko > ; Yu, Ping ; Wang, YuanX > > Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split > > On 4/12/22 19:40, Ding, Xuan wrote: > > Hi Jacob, > > > >> -Original Message- > >> From: Jerin Jacob > >> Sent: Thursday, April 7, 2022 9:27 PM > >> To: Wu, WenxuanX > >> Cc: Thomas Monjalon ; Andrew Rybchenko > >> ; Li, Xiaoyun ; > >> Singh, Aman Deep ; Zhang, Yuying > >> ; Zhang, Qi Z ; > >> dpdk-dev ; Stephen Hemminger > >> ; Morten Brørup > >> ; Viacheslav Ovsiienko > >> ; Yu, Ping ; Ding, Xuan > >> ; Wang, YuanX > >> Subject: Re: [v4 1/3] ethdev: introduce protocol type based header > >> split > >> > >> On Sat, Apr 2, 2022 at 4:33 PM wrote: > >>> > >>> From: Xuan Ding > >>> > >>> Header split consists of splitting a received packet into two > >>> separate regions based on the packet content. The split happens > >>> after the packet header and before the packet payload. Splitting is > >>> usually between the packet header that can be posted to a dedicated > >>> buffer and the packet payload that can be posted to a different buffer. > >>> > >>> Currently, Rx buffer split supports length and offset based packet split. > >>> Although header split is a subset of buffer split, configuring > >>> buffer split based on length is not suitable for NICs that do split > >>> based on header protocol types. Because tunneling makes the > >>> conversion from length to protocol type impossible. > >>> > >>> This patch extends the current buffer split to support protocol type > >>> and offset based header split. A new proto field is introduced in > >>> the rte_eth_rxseg_split structure reserved field to specify header > >>> protocol type. With Rx offload flag > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT > >>> enabled and protocol type configured, PMD will split the ingress > >>> packets into two separate regions. Currently, both inner and outer > >>> L2/L3/L4 level header split can be supported. > >>> > >>> For example, let's suppose we configured the Rx queue with the > >>> following segments: > >>> seg0 - pool0, off0=2B > >>> seg1 - pool1, off1=128B > >>> > >>> With header split type configured with RTE_ETH_RX_HEADER_SPLIT_UDP, > >>> the packet consists of MAC_IP_UDP_PAYLOAD will be split like following: > >>> seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from > pool0 > >> > >> If we set rte_eth_rxseg_split::proto = RTE_ETH_RX_HEADER_SPLIT_UDP > >> and rte_eth_rxseg_split.offset = 2, What will be the content for > >> seg0, Will it be, > >> - offset as Starts atUDP Header > >> - size of segment as MAX(size of UDP header + 2, 128(as seg 1 start > from128). > >> Right? If not, Please describe > > > > Proto defines the location in packet for split. > > Offset defines data buffer from beginning of mbuf data buffer, it can be > zero. > > With proto and offset configured, packets received will be split into two > segments. > > > > So in this configuration, the seg0 content is UDP header, the seg1 content > > is > the payload. > > Size of seg0 is size of UDP header, size of seg1 is size of payload. > > rte_eth_rxseg_split.offset = 2/128 decides the mbuf offset, rather than > segment size. > > Above discussion proves that definition of the struct rte_eth_rxseg_split is > misleading. It is hard to catch from naming that length defines a maximum > data amount to be copied, but office is a an offset in destination mbuf. The > structure is still experimental and I think we should improve naming: offset > -> > mbuf_offset? Yes, you are right. In rte_eth_rxseg_split structure, even the length and offset are documented, it is hard to understand just from the naming. Thanks, Xuan > > > > >> > >> Also, I don't think we need duplate > >> rte_eth_rx_header_split_protocol_type instead we can reuse existing > >> RTE_PTYPE_* flags. > > > > That's a good idea. Yes, I can use the RTE_PTYPE_* here. My only > > concern is the 32-bits RTE_PTYPE_* will run out of the 32-bits reserved > fields. > > If this proposal is agreed, I will use RTE_PTYPE_* instead of > rte_eth_rx_header_split_protocol_type. > > > > Best Regards, > > Xuan > > > >> > >> > >>> seg1 - payload @ 128 in mbuf from pool1 > >>> > >>> The memory attributes for the split parts may differ either - for > >>> example the mempool0 and mempool1 belong to dpdk memory and > >> external > >>> memory, respectively.
[PATCH 0/2] net/mlx5: LRO fixes
Independent fixes about LRO supporting. Michael Baum (2): net/mlx5: fix miss LRO validation in RxQ setup net/mlx5: fix LRO configuration in drop RxQ drivers/net/mlx5/mlx5_devx.c | 5 +++-- drivers/net/mlx5/mlx5_rxq.c | 8 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.25.1
[PATCH 1/2] net/mlx5: fix miss LRO validation in RxQ setup
The mlx5_rx_queue_setup() gets from user the LRO offload.
When LRO is configured, the LRO flag in rxq_data is set to 1.
This patch adds validation to make sure the LRO is supported.
Fixes: 17ed314 ("net/mlx5: allow LRO per Rx queue")
Cc: ma...@mellanox.com
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_rxq.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 981c296f29..a2d03f9f67 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -842,6 +842,14 @@ mlx5_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
dev->data->dev_conf.rxmode.offloads;
bool is_extmem = false;
+ if ((offloads & RTE_ETH_RX_OFFLOAD_TCP_LRO) &&
+ !priv->sh->dev_cap.lro_supported) {
+ DRV_LOG(ERR,
+ "Port %u queue %u LRO is configured but not supported.",
+ dev->data->port_id, idx);
+ rte_errno = EINVAL;
+ return -rte_errno;
+ }
if (mp) {
/*
* The parameters should be checked on rte_eth_dev layer.
--
2.25.1
[PATCH 2/2] net/mlx5: fix LRO configuration in drop RxQ
The driver wrongly set the LRO configurations to the TIR of the DevX
drop queue even when LRO is not supported.
Actually, the LRO configuration is not relevant to the drop queue at
all.
This causes failure in the initialization of the device, which doesn't
support LRO where the drop queue is created.
Probably, the drop queue creation by DevX missed the fact that LRO is
set by default in the TIR creation function and didn't unset it in the
drop queue case like other cases that unset LRO.
Move the default LRO configuration to unset it and set it only in the
case of all the TIR queues configured with LRO.
Fixes: bc5bee028ebc ("net/mlx5: create drop queue using DevX")
Cc: dkozl...@nvidia.com
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_devx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_devx.c b/drivers/net/mlx5/mlx5_devx.c
index 5ab092a259..03c0fac32f 100644
--- a/drivers/net/mlx5/mlx5_devx.c
+++ b/drivers/net/mlx5/mlx5_devx.c
@@ -715,7 +715,7 @@ mlx5_devx_tir_attr_set(struct rte_eth_dev *dev, const
uint8_t *rss_key,
{
struct mlx5_priv *priv = dev->data->dev_private;
bool is_hairpin;
- bool lro = true;
+ bool lro = false;
uint32_t i;
/* NULL queues designate drop queue. */
@@ -724,9 +724,9 @@ mlx5_devx_tir_attr_set(struct rte_eth_dev *dev, const
uint8_t *rss_key,
} else if (mlx5_is_external_rxq(dev, ind_tbl->queues[0])) {
/* External RxQ supports neither Hairpin nor LRO. */
is_hairpin = false;
- lro = false;
} else {
is_hairpin = mlx5_rxq_is_hairpin(dev, ind_tbl->queues[0]);
+ lro = true;
/* Enable TIR LRO only if all the queues were configured for. */
for (i = 0; i < ind_tbl->queues_n; ++i) {
struct mlx5_rxq_data *rxq_i =
@@ -776,6 +776,7 @@ mlx5_devx_tir_attr_set(struct rte_eth_dev *dev, const
uint8_t *rss_key,
if (dev->data->dev_conf.lpbk_mode)
tir_attr->self_lb_block = MLX5_TIRC_SELF_LB_BLOCK_BLOCK_UNICAST;
if (lro) {
+ MLX5_ASSERT(priv->sh->dev_cap.lro_supported);
tir_attr->lro_timeout_period_usecs = priv->config.lro_timeout;
tir_attr->lro_max_msg_sz = priv->max_lro_msg_size;
tir_attr->lro_enable_mask =
--
2.25.1
RE: [PATCH 1/3] ethdev: fix telemetry xstats return null with some PMDs
> From: fengchengwen [mailto:fengcheng...@huawei.com] > Sent: Sunday, 24 April 2022 05.45 > > The root cause is: when the xstats is NULL and n less than required > number of > elements is zero, the return value of rte_eth_xstats_get is ambiguous > from > rte_ethdev.h's declaration. > > But the implementation of rte_eth_xstats_get return required number of > elements > when xstats is NULL and n less than required number of elements. > > There are two modification schemes: > a) the value of xstats cannot be NULL, and the value of n must be > greater than >or equal to the required number, otherwise, an error code is > returned. > b) define the behavior as the same as rte_eth_xstats_get_names, which > means return >required number of elelement when xstats is NULL and n less than > required number >of elements. > > I prefer the scheme a because rte_eth_xstats_get and > rte_eth_xstats_get_name are > symbiotic, and it's not necessary to both implement the same logic. > > Also for scheme a, there is no need to modify the PMD implementation. > > What about your opinions ? This is an excellent proposal. And if the documentation for rte_eth_xstats_get() refers to rte_eth_xstats_get_names() for getting the number of elements, it is perfect. > > On 2022/4/21 14:49, Andrew Rybchenko wrote: > > On 4/16/22 04:38, Stephen Hemminger wrote: > >> On Sat, 16 Apr 2022 09:07:45 +0800 > >> Chengwen Feng wrote: > >> > >>> Currently the telemetry xstats uses rte_eth_xstats_get() to > retrieve > >>> the number of elements. But the value to be returned when the > parameter > >>> 'xstats' is NULL is not specified, some PMDs (eg. > hns3/ipn3ke/mvpp2/ > >>> axgbe) return zero while others return the required number of > elements. > >> > >> Lets fix the PMD's this impacts other code as well. > > > > +1 > > > > . >
RE: [PATCH v2 3/5] net/vhost: move to Vhost library stats API
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Thursday, March 24, 2022 8:47 PM
> To: dev@dpdk.org; Xia, Chenbo ;
> david.march...@redhat.com; i.maxim...@ovn.org
> Cc: Maxime Coquelin
> Subject: [PATCH v2 3/5] net/vhost: move to Vhost library stats API
>
> Now that we have Vhost statistics APIs, this patch replaces
> Vhost PMD extented statistics implementation with calls
extented -> extended
> to the new API. It will enable getting more statistics for
> counters that cannot be implmented at the PMD level.
implmented -> implemented
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/net/vhost/rte_eth_vhost.c | 348 +++---
> 1 file changed, 120 insertions(+), 228 deletions(-)
>
> diff --git a/drivers/net/vhost/rte_eth_vhost.c
> b/drivers/net/vhost/rte_eth_vhost.c
> index 070f0e6dfd..bac1c0acba 100644
> --- a/drivers/net/vhost/rte_eth_vhost.c
> +++ b/drivers/net/vhost/rte_eth_vhost.c
> @@ -59,33 +59,10 @@ static struct rte_ether_addr base_eth_addr = {
> }
> };
>
> -enum vhost_xstats_pkts {
> - VHOST_UNDERSIZE_PKT = 0,
> - VHOST_64_PKT,
> - VHOST_65_TO_127_PKT,
> - VHOST_128_TO_255_PKT,
> - VHOST_256_TO_511_PKT,
> - VHOST_512_TO_1023_PKT,
> - VHOST_1024_TO_1522_PKT,
> - VHOST_1523_TO_MAX_PKT,
> - VHOST_BROADCAST_PKT,
> - VHOST_MULTICAST_PKT,
> - VHOST_UNICAST_PKT,
> - VHOST_PKT,
> - VHOST_BYTE,
> - VHOST_MISSED_PKT,
> - VHOST_ERRORS_PKT,
> - VHOST_ERRORS_FRAGMENTED,
> - VHOST_ERRORS_JABBER,
> - VHOST_UNKNOWN_PROTOCOL,
> - VHOST_XSTATS_MAX,
> -};
> -
> struct vhost_stats {
> uint64_t pkts;
> uint64_t bytes;
> uint64_t missed_pkts;
> - uint64_t xstats[VHOST_XSTATS_MAX];
> };
>
> struct vhost_queue {
> @@ -140,138 +117,92 @@ struct rte_vhost_vring_state {
>
> static struct rte_vhost_vring_state *vring_states[RTE_MAX_ETHPORTS];
>
> -#define VHOST_XSTATS_NAME_SIZE 64
> -
> -struct vhost_xstats_name_off {
> - char name[VHOST_XSTATS_NAME_SIZE];
> - uint64_t offset;
> -};
> -
> -/* [rx]_is prepended to the name string here */
> -static const struct vhost_xstats_name_off vhost_rxport_stat_strings[] = {
> - {"good_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_PKT])},
> - {"total_bytes",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_BYTE])},
> - {"missed_pkts",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_MISSED_PKT])},
> - {"broadcast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_BROADCAST_PKT])},
> - {"multicast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_MULTICAST_PKT])},
> - {"unicast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_UNICAST_PKT])},
> - {"undersize_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_UNDERSIZE_PKT])},
> - {"size_64_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_64_PKT])},
> - {"size_65_to_127_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_65_TO_127_PKT])},
> - {"size_128_to_255_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_128_TO_255_PKT])},
> - {"size_256_to_511_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_256_TO_511_PKT])},
> - {"size_512_to_1023_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_512_TO_1023_PKT])},
> - {"size_1024_to_1522_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_1024_TO_1522_PKT])},
> - {"size_1523_to_max_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_1523_TO_MAX_PKT])},
> - {"errors_with_bad_CRC",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_ERRORS_PKT])},
> - {"fragmented_errors",
> - offsetof(struct vhost_queue,
> stats.xstats[VHOST_ERRORS_FRAGMENTED])},
> - {"jabber_errors",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_ERRORS_JABBER])},
> - {"unknown_protos_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_UNKNOWN_PROTOCOL])},
> -};
> -
> -/* [tx]_ is prepended to the name string here */
> -static const struct vhost_xstats_name_off vhost_txport_stat_strings[] = {
> - {"good_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_PKT])},
> - {"total_bytes",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_BYTE])},
> - {"missed_pkts",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_MISSED_PKT])},
> - {"broadcast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_BROADCAST_PKT])},
> - {"multicast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_MULTICAST_PKT])},
> - {"unicast_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_UNICAST_PKT])},
> - {"undersize_packets",
> - offsetof(struct vhost_queue, stats.xstats[VHOST_UNDERSIZE_PKT])},
> - {"size_64_packets",
> - offsetof(struct vhost_queue
RE: [PATCH v2 4/5] vhost: add statistics for guest notifications
> -Original Message- > From: Maxime Coquelin > Sent: Thursday, March 24, 2022 8:47 PM > To: dev@dpdk.org; Xia, Chenbo ; > david.march...@redhat.com; i.maxim...@ovn.org > Cc: Maxime Coquelin > Subject: [PATCH v2 4/5] vhost: add statistics for guest notifications > > This patch adds a new virtqueue statistic for guest > notifications. It is useful to deduce from hypervisor side > whether the corresponding guest Virtio device is using > Kernel Virtio-net driver or DPDK Virtio PMD. > > Signed-off-by: Maxime Coquelin > --- > lib/vhost/vhost.c | 1 + > lib/vhost/vhost.h | 5 + > 2 files changed, 6 insertions(+) > Reviewed-by: Chenbo Xia
RE: [PATCH v2 5/5] vhost: add statistics for IOTLB
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Thursday, March 24, 2022 8:47 PM
> To: dev@dpdk.org; Xia, Chenbo ;
> david.march...@redhat.com; i.maxim...@ovn.org
> Cc: Maxime Coquelin
> Subject: [PATCH v2 5/5] vhost: add statistics for IOTLB
>
> This patch adds statistics for IOTLB hits and misses.
>
> Signed-off-by: Maxime Coquelin
> ---
> lib/vhost/vhost.c | 10 +-
> lib/vhost/vhost.h | 3 +++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
> index 58b58fc40e..7f4fafdcb0 100644
> --- a/lib/vhost/vhost.c
> +++ b/lib/vhost/vhost.c
> @@ -43,6 +43,8 @@ static const struct vhost_vq_stats_name_off
> vhost_vq_stat_strings[] = {
> {"size_1024_1518_packets", offsetof(struct vhost_virtqueue,
> stats.size_bins[6])},
> {"size_1519_max_packets", offsetof(struct vhost_virtqueue,
> stats.size_bins[7])},
> {"guest_notifications",offsetof(struct vhost_virtqueue,
> stats.guest_notifications)},
> + {"iotlb_hits", offsetof(struct vhost_virtqueue,
> stats.iotlb_hits)},
> + {"iotlb_misses", offsetof(struct vhost_virtqueue,
> stats.iotlb_misses)},
> };
>
> #define VHOST_NB_VQ_STATS RTE_DIM(vhost_vq_stat_strings)
> @@ -60,8 +62,14 @@ __vhost_iova_to_vva(struct virtio_net *dev, struct
> vhost_virtqueue *vq,
> tmp_size = *size;
>
> vva = vhost_user_iotlb_cache_find(vq, iova, &tmp_size, perm);
> - if (tmp_size == *size)
> + if (tmp_size == *size) {
> + if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
> + vq->stats.iotlb_hits++;
> return vva;
> + }
> +
> + if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
> + vq->stats.iotlb_misses++;
>
> iova += tmp_size;
>
> diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
> index 13c5c2266d..e876fc157b 100644
> --- a/lib/vhost/vhost.h
> +++ b/lib/vhost/vhost.h
> @@ -134,6 +134,9 @@ struct virtqueue_stats {
> /* Size bins in array as RFC 2819, undersized [0], 64 [1], etc */
> uint64_t size_bins[8];
> uint64_t guest_notifications;
> + uint64_t iotlb_hits;
> + uint64_t iotlb_misses;
> + uint64_t iotlb_errors;
This seems defined but never used.
Thanks,
Chenbo
> };
>
> /**
> --
> 2.35.1
RE: [PATCH v4 00/10] app/test: add inline IPsec and reassembly cases
Hi everyone, When running inline_ipsec_autotest, tests should be marked as "skipped" rather than "failed". Kind Regards, Jakub Poczatek -Original Message- From: Akhil Goyal Sent: Saturday 16 April 2022 20:25 To: dev@dpdk.org Cc: tho...@monjalon.net; david.march...@redhat.com; hemant.agra...@nxp.com; ano...@marvell.com; Ananyev, Konstantin ; Power, Ciara ; Yigit, Ferruh ; andrew.rybche...@oktetlabs.ru; ndabilpu...@marvell.com; vattun...@marvell.com; Akhil Goyal Subject: [PATCH v4 00/10] app/test: add inline IPsec and reassembly cases IP reassembly offload was added in last release. The test app for unit testing IP reassembly of inline inbound IPsec flows is added in this patchset. For testing IP reassembly, base inline IPsec is also added. The app is enhanced in v4 to handle more functional unit test cases for inline IPsec similar to Lookaside IPsec. The functions from Lookaside more are reused to verify functional cases. Changes in v4: - rebased over next-crypto - updated app to take benefit from Lookaside protocol test functions. - Added more functional cases - Added soft and hard expiry event subtypes in ethdev for testing SA soft and hard pkt/byte expiry events. - reassembly cases are squashed in a single patch Changes in v3: - incorporated latest ethdev changes for reassembly. - skipped build on windows as it needs rte_ipsec lib which is not compiled on windows. changes in v2: - added IPsec burst mode case - updated as per the latest ethdev changes. Akhil Goyal (6): app/test: add unit cases for inline IPsec offload test/security: add inline inbound IPsec cases test/security: add combined mode inline IPsec cases test/security: add inline IPsec reassembly cases test/security: add more inline IPsec functional cases test/security: add ESN and anti-replay cases for inline Vamsi Attunuru (4): ethdev: add IPsec SA expiry event subtypes test/security: add inline IPsec SA soft expiry cases test/security: add inline IPsec SA hard expiry cases test/security: add inline IPsec IPv6 flow label cases MAINTAINERS |2 +- app/test/meson.build |1 + app/test/test_cryptodev_security_ipsec.c | 35 +- app/test/test_cryptodev_security_ipsec.h | 12 + app/test/test_security_inline_proto.c | 2525 + app/test/test_security_inline_proto_vectors.h | 710 + lib/ethdev/rte_ethdev.h |9 + 7 files changed, 3292 insertions(+), 2 deletions(-) create mode 100644 app/test/test_security_inline_proto.c create mode 100644 app/test/test_security_inline_proto_vectors.h -- 2.25.1
RE: [PATCH v6 03/16] vhost: add vhost msg support
Hi Andy,
> -Original Message-
> From: Pei, Andy
> Sent: Thursday, April 21, 2022 4:34 PM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; maxime.coque...@redhat.com; Cao,
> Gang ; Liu, Changpeng
> Subject: [PATCH v6 03/16] vhost: add vhost msg support
>
> Add support for VHOST_USER_GET_CONFIG and VHOST_USER_SET_CONFIG.
> VHOST_USER_GET_CONFIG and VHOST_USER_SET_CONFIG message is only
> supported by virtio blk VDPA device.
>
> Signed-off-by: Andy Pei
> ---
> lib/vhost/vhost_user.c | 69
> ++
> lib/vhost/vhost_user.h | 13 ++
> 2 files changed, 82 insertions(+)
>
> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> index 1d39067..3780804 100644
> --- a/lib/vhost/vhost_user.c
> +++ b/lib/vhost/vhost_user.c
> @@ -80,6 +80,8 @@
> [VHOST_USER_NET_SET_MTU] = "VHOST_USER_NET_SET_MTU",
> [VHOST_USER_SET_SLAVE_REQ_FD] = "VHOST_USER_SET_SLAVE_REQ_FD",
> [VHOST_USER_IOTLB_MSG] = "VHOST_USER_IOTLB_MSG",
> + [VHOST_USER_GET_CONFIG] = "VHOST_USER_GET_CONFIG",
> + [VHOST_USER_SET_CONFIG] = "VHOST_USER_SET_CONFIG",
> [VHOST_USER_CRYPTO_CREATE_SESS] = "VHOST_USER_CRYPTO_CREATE_SESS",
> [VHOST_USER_CRYPTO_CLOSE_SESS] = "VHOST_USER_CRYPTO_CLOSE_SESS",
> [VHOST_USER_POSTCOPY_ADVISE] = "VHOST_USER_POSTCOPY_ADVISE",
> @@ -2542,6 +2544,71 @@ static int is_vring_iotlb(struct virtio_net *dev,
> }
>
> static int
> +vhost_user_get_config(struct virtio_net **pdev,
> + struct vhu_msg_context *ctx,
> + int main_fd __rte_unused)
> +{
> + struct virtio_net *dev = *pdev;
> + struct rte_vdpa_device *vdpa_dev = dev->vdpa_dev;
> + int ret = 0;
> +
> + if (vdpa_dev->ops->get_config) {
> + ret = vdpa_dev->ops->get_config(dev->vid,
> +ctx->msg.payload.cfg.region,
> +ctx->msg.payload.cfg.size);
> + if (ret != 0) {
> + ctx->msg.size = 0;
> + VHOST_LOG_CONFIG(ERR,
> + "(%s) get_config() return error!\n",
> + dev->ifname);
> + }
> + } else {
> + VHOST_LOG_CONFIG(ERR, "(%s) get_config() not supportted!\n",
Supported
> + dev->ifname);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_config(struct virtio_net **pdev,
> + struct vhu_msg_context *ctx,
> + int main_fd __rte_unused)
> +{
> + struct virtio_net *dev = *pdev;
> + struct rte_vdpa_device *vdpa_dev = dev->vdpa_dev;
> + int ret = 0;
> +
> + if (ctx->msg.size != sizeof(struct vhost_user_config)) {
I think you should do sanity check on payload.cfg.size and make sure it's
smaller
than VHOST_USER_MAX_CONFIG_SIZE
and same check for offset
> + VHOST_LOG_CONFIG(ERR,
> + "(%s) invalid set config msg size: %"PRId32" != %d\n",
> + dev->ifname, ctx->msg.size,
Based on you will change the log too, payload.cfg.size is uint32_t,
so PRId32 -> PRIu32
> + (int)sizeof(struct vhost_user_config));
So this can be %u
> + goto OUT;
> + }
> +
> + if (vdpa_dev->ops->set_config) {
> + ret = vdpa_dev->ops->set_config(dev->vid,
> + ctx->msg.payload.cfg.region,
> + ctx->msg.payload.cfg.offset,
> + ctx->msg.payload.cfg.size,
> + ctx->msg.payload.cfg.flags);
> + if (ret)
> + VHOST_LOG_CONFIG(ERR,
> + "(%s) set_config() return error!\n",
> + dev->ifname);
> + } else {
> + VHOST_LOG_CONFIG(ERR, "(%s) set_config() not supportted!\n",
Supported
> + dev->ifname);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +
> +OUT:
Lower case looks better
> + return RTE_VHOST_MSG_RESULT_ERR;
> +}
Almost all handlers need check on expected fd num (this case is 0), so the
above new
handlers should also do that. Please refer to validate_msg_fds in other
handlers.
BTW, you can wait for review for other patches and send new versions later.
Thanks,
Chenbo
> +
> +static int
> vhost_user_iotlb_msg(struct virtio_net **pdev,
> struct vhu_msg_context *ctx,
> int main_fd __rte_unused)
> @@ -2782,6 +2849,8 @@ typedef int (*vhost_message_handler_t)(struct
> virtio_net **pdev,
> [VHOST_USER_NET_SET_MTU] = vhost_user_net_set_mtu,
> [VHOST_USER_SET_SLAVE_REQ_FD] = vhost_user_set_req_fd,
> [VHOST_USER_IOTLB_MSG] = vhost_user_iotlb_msg,
> + [VHOST_USER_GET_CONFIG] = vhost_user_get_config,
> + [VHOST_USER_SET_CONFIG] = vhost_user_set_config,
> [VHOST_USER_POSTCOPY_ADVISE] = v
[PATCH 1/2] vhost: remove unneeded max enums
Move message handler description and callbacks into a single array and
remove unneeded VHOST_USER_MAX and VHOST_SLAVE_MAX enums.
Signed-off-by: David Marchand
---
drivers/net/virtio/virtio_user/vhost_user.c | 1 -
examples/vhost_blk/blk_spec.h | 1 -
lib/vhost/vhost_user.c | 175 +---
lib/vhost/vhost_user.h | 2 -
4 files changed, 76 insertions(+), 103 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/vhost_user.c
b/drivers/net/virtio/virtio_user/vhost_user.c
index 00d0dcaa74..7d1749114d 100644
--- a/drivers/net/virtio/virtio_user/vhost_user.c
+++ b/drivers/net/virtio/virtio_user/vhost_user.c
@@ -78,7 +78,6 @@ enum vhost_user_request {
VHOST_USER_SET_VRING_ENABLE = 18,
VHOST_USER_SET_STATUS = 39,
VHOST_USER_GET_STATUS = 40,
- VHOST_USER_MAX
};
struct vhost_user_msg {
diff --git a/examples/vhost_blk/blk_spec.h b/examples/vhost_blk/blk_spec.h
index 594bd6a29b..3c54f70eaf 100644
--- a/examples/vhost_blk/blk_spec.h
+++ b/examples/vhost_blk/blk_spec.h
@@ -56,7 +56,6 @@ enum vhost_user_request {
VHOST_USER_SET_PROTOCOL_FEATURES = 16,
VHOST_USER_GET_QUEUE_NUM = 17,
VHOST_USER_SET_VRING_ENABLE = 18,
- VHOST_USER_MAX
};
/** Get/set config msg payload */
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 1d390677fa..17cfeafa16 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -56,40 +56,12 @@
#define INFLIGHT_ALIGNMENT 64
#define INFLIGHT_VERSION 0x1
-static const char *vhost_message_str[VHOST_USER_MAX] = {
- [VHOST_USER_NONE] = "VHOST_USER_NONE",
- [VHOST_USER_GET_FEATURES] = "VHOST_USER_GET_FEATURES",
- [VHOST_USER_SET_FEATURES] = "VHOST_USER_SET_FEATURES",
- [VHOST_USER_SET_OWNER] = "VHOST_USER_SET_OWNER",
- [VHOST_USER_RESET_OWNER] = "VHOST_USER_RESET_OWNER",
- [VHOST_USER_SET_MEM_TABLE] = "VHOST_USER_SET_MEM_TABLE",
- [VHOST_USER_SET_LOG_BASE] = "VHOST_USER_SET_LOG_BASE",
- [VHOST_USER_SET_LOG_FD] = "VHOST_USER_SET_LOG_FD",
- [VHOST_USER_SET_VRING_NUM] = "VHOST_USER_SET_VRING_NUM",
- [VHOST_USER_SET_VRING_ADDR] = "VHOST_USER_SET_VRING_ADDR",
- [VHOST_USER_SET_VRING_BASE] = "VHOST_USER_SET_VRING_BASE",
- [VHOST_USER_GET_VRING_BASE] = "VHOST_USER_GET_VRING_BASE",
- [VHOST_USER_SET_VRING_KICK] = "VHOST_USER_SET_VRING_KICK",
- [VHOST_USER_SET_VRING_CALL] = "VHOST_USER_SET_VRING_CALL",
- [VHOST_USER_SET_VRING_ERR] = "VHOST_USER_SET_VRING_ERR",
- [VHOST_USER_GET_PROTOCOL_FEATURES] =
"VHOST_USER_GET_PROTOCOL_FEATURES",
- [VHOST_USER_SET_PROTOCOL_FEATURES] =
"VHOST_USER_SET_PROTOCOL_FEATURES",
- [VHOST_USER_GET_QUEUE_NUM] = "VHOST_USER_GET_QUEUE_NUM",
- [VHOST_USER_SET_VRING_ENABLE] = "VHOST_USER_SET_VRING_ENABLE",
- [VHOST_USER_SEND_RARP] = "VHOST_USER_SEND_RARP",
- [VHOST_USER_NET_SET_MTU] = "VHOST_USER_NET_SET_MTU",
- [VHOST_USER_SET_SLAVE_REQ_FD] = "VHOST_USER_SET_SLAVE_REQ_FD",
- [VHOST_USER_IOTLB_MSG] = "VHOST_USER_IOTLB_MSG",
- [VHOST_USER_CRYPTO_CREATE_SESS] = "VHOST_USER_CRYPTO_CREATE_SESS",
- [VHOST_USER_CRYPTO_CLOSE_SESS] = "VHOST_USER_CRYPTO_CLOSE_SESS",
- [VHOST_USER_POSTCOPY_ADVISE] = "VHOST_USER_POSTCOPY_ADVISE",
- [VHOST_USER_POSTCOPY_LISTEN] = "VHOST_USER_POSTCOPY_LISTEN",
- [VHOST_USER_POSTCOPY_END] = "VHOST_USER_POSTCOPY_END",
- [VHOST_USER_GET_INFLIGHT_FD] = "VHOST_USER_GET_INFLIGHT_FD",
- [VHOST_USER_SET_INFLIGHT_FD] = "VHOST_USER_SET_INFLIGHT_FD",
- [VHOST_USER_SET_STATUS] = "VHOST_USER_SET_STATUS",
- [VHOST_USER_GET_STATUS] = "VHOST_USER_GET_STATUS",
-};
+typedef struct vhost_message_handler {
+ const char *description;
+ int (*callback)(struct virtio_net **pdev, struct vhu_msg_context *ctx,
+ int main_fd);
+} vhost_message_handler_t;
+static vhost_message_handler_t vhost_message_handlers[];
static int send_vhost_reply(struct virtio_net *dev, int sockfd, struct
vhu_msg_context *ctx);
static int read_vhost_message(struct virtio_net *dev, int sockfd, struct
vhu_msg_context *ctx);
@@ -122,7 +94,7 @@ validate_msg_fds(struct virtio_net *dev, struct
vhu_msg_context *ctx, int expect
VHOST_LOG_CONFIG(ERR, "(%s) expect %d FDs for request %s, received
%d\n",
dev->ifname, expected_fds,
- vhost_message_str[ctx->msg.request.master],
+ vhost_message_handlers[ctx->msg.request.master].description,
ctx->fd_num);
close_msg_fds(ctx);
@@ -2754,42 +2726,44 @@ vhost_user_set_status(struct virtio_net **pdev,
return RTE_VHOST_MSG_RESULT_OK;
}
-typedef int (*vhost_message_handler_t)(struct virtio_net **pdev,
- struct vhu_msg_context *ctx,
- int main_fd);
-
-static vhost_message_handler_t vhost_message_handlers[VHOST_USE
[PATCH 2/2] vhost: validate fds attached to messages
Some message handlers do not expect any file descriptor attached as
ancillary data.
Provide a common way to enforce this by adding a accepts_fd boolean in
the message handler structure. When a message handler sets accepts_fd to
true, it is responsible for calling validate_msg_fds with a right
expected file descriptor count.
This will avoid leaking some file descriptor by mistake when adding
support for new vhost user message types.
Signed-off-by: David Marchand
---
lib/vhost/vhost_user.c | 145 -
1 file changed, 43 insertions(+), 102 deletions(-)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 17cfeafa16..850848c269 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -60,6 +60,7 @@ typedef struct vhost_message_handler {
const char *description;
int (*callback)(struct virtio_net **pdev, struct vhu_msg_context *ctx,
int main_fd);
+ bool accepts_fd;
} vhost_message_handler_t;
static vhost_message_handler_t vhost_message_handlers[];
@@ -262,28 +263,20 @@ vhost_user_notify_queue_state(struct virtio_net *dev,
uint16_t index,
* the device hasn't been initialised.
*/
static int
-vhost_user_set_owner(struct virtio_net **pdev,
- struct vhu_msg_context *ctx,
+vhost_user_set_owner(struct virtio_net **pdev __rte_unused,
+ struct vhu_msg_context *ctx __rte_unused,
int main_fd __rte_unused)
{
- struct virtio_net *dev = *pdev;
-
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
return RTE_VHOST_MSG_RESULT_OK;
}
static int
vhost_user_reset_owner(struct virtio_net **pdev,
- struct vhu_msg_context *ctx,
+ struct vhu_msg_context *ctx __rte_unused,
int main_fd __rte_unused)
{
struct virtio_net *dev = *pdev;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
vhost_destroy_device_notify(dev);
cleanup_device(dev, 0);
@@ -302,9 +295,6 @@ vhost_user_get_features(struct virtio_net **pdev,
struct virtio_net *dev = *pdev;
uint64_t features = 0;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
rte_vhost_driver_get_features(dev->ifname, &features);
ctx->msg.payload.u64 = features;
@@ -325,9 +315,6 @@ vhost_user_get_queue_num(struct virtio_net **pdev,
struct virtio_net *dev = *pdev;
uint32_t queue_num = 0;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
rte_vhost_driver_get_queue_num(dev->ifname, &queue_num);
ctx->msg.payload.u64 = (uint64_t)queue_num;
@@ -350,9 +337,6 @@ vhost_user_set_features(struct virtio_net **pdev,
uint64_t vhost_features = 0;
struct rte_vdpa_device *vdpa_dev;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
rte_vhost_driver_get_features(dev->ifname, &vhost_features);
if (features & ~vhost_features) {
VHOST_LOG_CONFIG(ERR, "(%s) received invalid negotiated
features.\n",
@@ -438,9 +422,6 @@ vhost_user_set_vring_num(struct virtio_net **pdev,
struct virtio_net *dev = *pdev;
struct vhost_virtqueue *vq =
dev->virtqueue[ctx->msg.payload.state.index];
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
if (ctx->msg.payload.state.num > 32768) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid virtqueue size %u\n",
dev->ifname, ctx->msg.payload.state.num);
@@ -882,9 +863,6 @@ vhost_user_set_vring_addr(struct virtio_net **pdev,
struct vhost_vring_addr *addr = &ctx->msg.payload.addr;
bool access_ok;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
if (dev->mem == NULL)
return RTE_VHOST_MSG_RESULT_ERR;
@@ -926,9 +904,6 @@ vhost_user_set_vring_base(struct virtio_net **pdev,
struct vhost_virtqueue *vq =
dev->virtqueue[ctx->msg.payload.state.index];
uint64_t val = ctx->msg.payload.state.num;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
if (vq_is_packed(dev)) {
/*
* Bit[0:14]: avail index
@@ -1574,9 +1549,6 @@ vhost_user_get_inflight_fd(struct virtio_net **pdev,
int numa_node = SOCKET_ID_ANY;
void *addr;
- if (validate_msg_fds(dev, ctx, 0) != 0)
- return RTE_VHOST_MSG_RESULT_ERR;
-
if (ctx->msg.size != sizeof(ctx->msg.payload.inflight)) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid get_inflight_fd message
size is %d\n",
dev->ifname, ctx->msg.size);
@@ -2097,9 +2069,6 @@ vh
RE: [PATCH v6 05/16] vdpa/ifc: add vDPA interrupt for blk device
Hi Andy,
> -Original Message-
> From: Pei, Andy
> Sent: Thursday, April 21, 2022 4:34 PM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; maxime.coque...@redhat.com; Cao,
> Gang ; Liu, Changpeng
> Subject: [PATCH v6 05/16] vdpa/ifc: add vDPA interrupt for blk device
>
> For the block device type, we have to relay
> the commands on all queues.
It's a bit short... although I can understand, please add some background
on current implementation for others to easily understand.
>
> Signed-off-by: Andy Pei
> ---
> drivers/vdpa/ifc/ifcvf_vdpa.c | 46 --
> -
> 1 file changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
> index 8ee041f..8d104b7 100644
> --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> @@ -370,24 +370,48 @@ struct rte_vdpa_dev_info {
> irq_set->index = VFIO_PCI_MSIX_IRQ_INDEX;
> irq_set->start = 0;
> fd_ptr = (int *)&irq_set->data;
> + /* The first interrupt is for the configure space change
> notification */
> fd_ptr[RTE_INTR_VEC_ZERO_OFFSET] =
> rte_intr_fd_get(internal->pdev->intr_handle);
>
> for (i = 0; i < nr_vring; i++)
> internal->intr_fd[i] = -1;
>
> - for (i = 0; i < nr_vring; i++) {
> - rte_vhost_get_vhost_vring(internal->vid, i, &vring);
> - fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = vring.callfd;
> - if ((i & 1) == 0 && m_rx == true) {
> - fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> - if (fd < 0) {
> - DRV_LOG(ERR, "can't setup eventfd: %s",
> - strerror(errno));
> - return -1;
> + if (internal->device_type == IFCVF_NET) {
> + for (i = 0; i < nr_vring; i++) {
> + rte_vhost_get_vhost_vring(internal->vid, i, &vring);
> + fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = vring.callfd;
> + if ((i & 1) == 0 && m_rx == true) {
> + /* For the net we only need to relay rx queue,
> + * which will change the mem of VM.
> + */
> + fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> + if (fd < 0) {
> + DRV_LOG(ERR, "can't setup eventfd: %s",
> + strerror(errno));
> + return -1;
> + }
> + internal->intr_fd[i] = fd;
> + fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = fd;
> + }
> + }
> + } else if (internal->device_type == IFCVF_BLK) {
> + for (i = 0; i < nr_vring; i++) {
> + rte_vhost_get_vhost_vring(internal->vid, i, &vring);
> + fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = vring.callfd;
> + if (m_rx == true) {
> + /* For the blk we need to relay all the read cmd
> + * of each queue
> + */
> + fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> + if (fd < 0) {
> + DRV_LOG(ERR, "can't setup eventfd: %s",
> + strerror(errno));
> + return -1;
> + }
> + internal->intr_fd[i] = fd;
> + fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = fd;
Many duplicated code here for blk and net. What if we use this condition to know
creating eventfd or not:
if (m_rx == true && (is_blk_dev || (i & 1) == 0)) {
/* create eventfd and save now */
}
Thanks,
Chenbo
> }
> - internal->intr_fd[i] = fd;
> - fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = fd;
> }
> }
>
> --
> 1.8.3.1
Re: [PATCH v6 03/16] vhost: add vhost msg support
On Thu, Apr 21, 2022 at 11:20 AM Andy Pei wrote:
> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> index 1d39067..3780804 100644
> --- a/lib/vhost/vhost_user.c
> +++ b/lib/vhost/vhost_user.c
> @@ -80,6 +80,8 @@
> [VHOST_USER_NET_SET_MTU] = "VHOST_USER_NET_SET_MTU",
> [VHOST_USER_SET_SLAVE_REQ_FD] = "VHOST_USER_SET_SLAVE_REQ_FD",
> [VHOST_USER_IOTLB_MSG] = "VHOST_USER_IOTLB_MSG",
> + [VHOST_USER_GET_CONFIG] = "VHOST_USER_GET_CONFIG",
> + [VHOST_USER_SET_CONFIG] = "VHOST_USER_SET_CONFIG",
> [VHOST_USER_CRYPTO_CREATE_SESS] = "VHOST_USER_CRYPTO_CREATE_SESS",
> [VHOST_USER_CRYPTO_CLOSE_SESS] = "VHOST_USER_CRYPTO_CLOSE_SESS",
> [VHOST_USER_POSTCOPY_ADVISE] = "VHOST_USER_POSTCOPY_ADVISE",
> @@ -2542,6 +2544,71 @@ static int is_vring_iotlb(struct virtio_net *dev,
> }
>
> static int
> +vhost_user_get_config(struct virtio_net **pdev,
> + struct vhu_msg_context *ctx,
> + int main_fd __rte_unused)
> +{
> + struct virtio_net *dev = *pdev;
> + struct rte_vdpa_device *vdpa_dev = dev->vdpa_dev;
> + int ret = 0;
You must check if there is any fd attached to this message.
> +
> + if (vdpa_dev->ops->get_config) {
> + ret = vdpa_dev->ops->get_config(dev->vid,
> + ctx->msg.payload.cfg.region,
> + ctx->msg.payload.cfg.size);
> + if (ret != 0) {
> + ctx->msg.size = 0;
> + VHOST_LOG_CONFIG(ERR,
> +"(%s) get_config() return error!\n",
> +dev->ifname);
> + }
> + } else {
> + VHOST_LOG_CONFIG(ERR, "(%s) get_config() not supportted!\n",
> +dev->ifname);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_config(struct virtio_net **pdev,
> + struct vhu_msg_context *ctx,
> + int main_fd __rte_unused)
> +{
> + struct virtio_net *dev = *pdev;
> + struct rte_vdpa_device *vdpa_dev = dev->vdpa_dev;
> + int ret = 0;
Idem.
> +
> + if (ctx->msg.size != sizeof(struct vhost_user_config)) {
> + VHOST_LOG_CONFIG(ERR,
> + "(%s) invalid set config msg size: %"PRId32" != %d\n",
> + dev->ifname, ctx->msg.size,
> + (int)sizeof(struct vhost_user_config));
> + goto OUT;
> + }
For info, I posted a series to make this kind of check more systematic.
See:
https://patchwork.dpdk.org/project/dpdk/patch/20220425125431.26464-2-david.march...@redhat.com/
--
David Marchand
RE: [PATCH v6 06/16] vdpa/ifc: add block device SW live-migration
> -Original Message-
> From: Pei, Andy
> Sent: Thursday, April 21, 2022 4:34 PM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; maxime.coque...@redhat.com; Cao,
> Gang ; Liu, Changpeng
> Subject: [PATCH v6 06/16] vdpa/ifc: add block device SW live-migration
>
> Add SW live-migration support to block device.
> Add dirty page logging to block device.
Add SW live-migration support including dirty page logging for block device.
>
> Signed-off-by: Andy Pei
> ---
> drivers/vdpa/ifc/base/ifcvf.c | 4 +-
> drivers/vdpa/ifc/base/ifcvf.h | 6 ++
> drivers/vdpa/ifc/ifcvf_vdpa.c | 128 +++--
> -
> 3 files changed, 115 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/vdpa/ifc/base/ifcvf.c b/drivers/vdpa/ifc/base/ifcvf.c
> index d10c1fd..e417c50 100644
> --- a/drivers/vdpa/ifc/base/ifcvf.c
> +++ b/drivers/vdpa/ifc/base/ifcvf.c
> @@ -191,7 +191,7 @@
> IFCVF_WRITE_REG32(val >> 32, hi);
> }
>
> -STATIC int
> +int
> ifcvf_hw_enable(struct ifcvf_hw *hw)
> {
> struct ifcvf_pci_common_cfg *cfg;
> @@ -240,7 +240,7 @@
> return 0;
> }
>
> -STATIC void
> +void
> ifcvf_hw_disable(struct ifcvf_hw *hw)
> {
> u32 i;
> diff --git a/drivers/vdpa/ifc/base/ifcvf.h b/drivers/vdpa/ifc/base/ifcvf.h
> index 769c603..6dd7925 100644
> --- a/drivers/vdpa/ifc/base/ifcvf.h
> +++ b/drivers/vdpa/ifc/base/ifcvf.h
> @@ -179,4 +179,10 @@ struct ifcvf_hw {
> u64
> ifcvf_get_queue_notify_off(struct ifcvf_hw *hw, int qid);
>
> +int
> +ifcvf_hw_enable(struct ifcvf_hw *hw);
> +
> +void
> +ifcvf_hw_disable(struct ifcvf_hw *hw);
> +
> #endif /* _IFCVF_H_ */
> diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
> index 8d104b7..a23dc2d 100644
> --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> @@ -345,6 +345,56 @@ struct rte_vdpa_dev_info {
> }
> }
>
> +static void
> +vdpa_ifcvf_blk_pause(struct ifcvf_internal *internal)
> +{
> + struct ifcvf_hw *hw = &internal->hw;
> + struct rte_vhost_vring vq;
> + int i, vid;
> + uint64_t features = 0;
> + uint64_t log_base = 0, log_size = 0;
> + uint64_t len;
> +
> + vid = internal->vid;
> +
> + if (internal->device_type == IFCVF_BLK) {
> + for (i = 0; i < hw->nr_vring; i++) {
> + rte_vhost_get_vhost_vring(internal->vid, i, &vq);
> + while (vq.avail->idx != vq.used->idx) {
> + ifcvf_notify_queue(hw, i);
> + usleep(10);
> + }
> + hw->vring[i].last_avail_idx = vq.avail->idx;
> + hw->vring[i].last_used_idx = vq.used->idx;
> + }
> + }
> +
> + ifcvf_hw_disable(hw);
> +
> + for (i = 0; i < hw->nr_vring; i++)
> + rte_vhost_set_vring_base(vid, i, hw->vring[i].last_avail_idx,
> + hw->vring[i].last_used_idx);
> +
> + if (internal->sw_lm)
> + return;
> +
> + rte_vhost_get_negotiated_features(vid, &features);
> + if (RTE_VHOST_NEED_LOG(features)) {
> + ifcvf_disable_logging(hw);
> + rte_vhost_get_log_base(internal->vid, &log_base, &log_size);
> + rte_vfio_container_dma_unmap(internal->vfio_container_fd,
> + log_base, IFCVF_LOG_BASE, log_size);
> + /*
> + * IFCVF marks dirty memory pages for only packet buffer,
> + * SW helps to mark the used ring as dirty after device stops.
> + */
> + for (i = 0; i < hw->nr_vring; i++) {
> + len = IFCVF_USED_RING_LEN(hw->vring[i].size);
> + rte_vhost_log_used_vring(vid, i, 0, len);
> + }
> + }
> +}
Can we consider combining vdpa_ifcvf_blk_pause and vdpa_ifcvf_stop to one
function and
check device type internally to do different things? Because as I see, most
logic is
the same.
> +
> #define MSIX_IRQ_SET_BUF_LEN (sizeof(struct vfio_irq_set) + \
> sizeof(int) * (IFCVF_MAX_QUEUES * 2 + 1))
> static int
> @@ -659,15 +709,22 @@ struct rte_vdpa_dev_info {
> }
> hw->vring[i].avail = gpa;
>
> - /* Direct I/O for Tx queue, relay for Rx queue */
> - if (i & 1) {
> - gpa = hva_to_gpa(vid, (uint64_t)(uintptr_t)vq.used);
> - if (gpa == 0) {
> - DRV_LOG(ERR, "Fail to get GPA for used ring.");
> - return -1;
> + if (internal->device_type == IFCVF_NET) {
> + /* Direct I/O for Tx queue, relay for Rx queue */
> + if (i & 1) {
> + gpa = hva_to_gpa(vid,
> (uint64_t)(uintptr_t)vq.used);
> + if (gpa == 0) {
> + DRV_LOG(ERR, "Fail to get GPA for used
> ring.");
> + return
RE: [PATCH v2 5/7] vdpa/mlx5: cache and reuse hardware resources
Hi Maxime, Thanks for the suggestion, I'll send out a new version. Regards, Xueming Li > -Original Message- > From: Maxime Coquelin > Sent: Wednesday, April 20, 2022 11:03 PM > To: Xueming(Steven) Li ; dev@dpdk.org > Cc: Matan Azrad ; Slava Ovsiienko > Subject: Re: [PATCH v2 5/7] vdpa/mlx5: cache and reuse hardware resources > > > > On 2/24/22 16:50, Xueming Li wrote: > > During device suspend and resume, resources are not changed normally. > > When huge resources allocated to VM, like huge memory size or lots of > > "When huge resources were allocated" > > > queues, time spent on release and recreate became significant. > > > > To speed up, this patch reuse resoruces like VM MR and VirtQ memory if > > "reuses resources" > > > not changed. > > > > Signed-off-by: Xueming Li > > --- > > drivers/vdpa/mlx5/mlx5_vdpa.c | 11 - > > drivers/vdpa/mlx5/mlx5_vdpa.h | 12 - > > drivers/vdpa/mlx5/mlx5_vdpa_mem.c | 27 ++- > > drivers/vdpa/mlx5/mlx5_vdpa_virtq.c | 73 + > > 4 files changed, 99 insertions(+), 24 deletions(-) > > > > Reviewed-by: Maxime Coquelin > > Thanks, > Maxime
RE: [PATCH v6 07/16] examples/vdpa: add vDPA blk support in example
Hi Andy,
> -Original Message-
> From: Pei, Andy
> Sent: Thursday, April 21, 2022 4:34 PM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; maxime.coque...@redhat.com; Cao,
> Gang ; Liu, Changpeng
> Subject: [PATCH v6 07/16] examples/vdpa: add vDPA blk support in example
>
> Add virtio blk device support to vDPA example.
>
> Signed-off-by: Andy Pei
> ---
> examples/vdpa/main.c | 61 +-
> examples/vdpa/vdpa_blk_compact.h | 72 +
> examples/vdpa/vhost_user.h | 169
> +++
> 3 files changed, 301 insertions(+), 1 deletion(-)
> create mode 100644 examples/vdpa/vdpa_blk_compact.h
> create mode 100644 examples/vdpa/vhost_user.h
>
> diff --git a/examples/vdpa/main.c b/examples/vdpa/main.c
> index 5ab0765..1c809ab 100644
> --- a/examples/vdpa/main.c
> +++ b/examples/vdpa/main.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include "vdpa_blk_compact.h"
>
> #define MAX_PATH_LEN 128
> #define MAX_VDPA_SAMPLE_PORTS 1024
> @@ -41,6 +42,7 @@ struct vdpa_port {
> static int devcnt;
> static int interactive;
> static int client_mode;
> +static int isblk;
>
> /* display usage */
> static void
> @@ -49,7 +51,8 @@ struct vdpa_port {
> printf("Usage: %s [EAL options] -- "
>" --interactive|-i: run in interactive
> mode.\n"
>" --iface : specify the path prefix
> of
> the socket files, e.g. /tmp/vhost-user-.\n"
> - " --client: register a vhost-user socket
> as
> client mode.\n",
> + " --client: register a vhost-user socket
> as
> client mode.\n"
> + " --isblk: device is a block device, e.g.
> virtio_blk device.\n",
>prgname);
> }
>
> @@ -61,6 +64,7 @@ struct vdpa_port {
> {"iface", required_argument, NULL, 0},
> {"interactive", no_argument, &interactive, 1},
> {"client", no_argument, &client_mode, 1},
> + {"isblk", no_argument, &isblk, 1},
I think a new API for get_device_type will be better than asking user to
specify the
device type.
> {NULL, 0, 0, 0},
> };
> int opt, idx;
> @@ -159,6 +163,52 @@ struct vdpa_port {
> };
>
> static int
> +vdpa_blk_device_set_features_and_protocol(const char *path)
> +{
> + uint64_t protocol_features = 0;
> + int ret;
> +
> + ret = rte_vhost_driver_set_features(path, VHOST_BLK_FEATURES_BASE);
> + if (ret != 0) {
> + RTE_LOG(ERR, VDPA,
> + "rte_vhost_driver_set_features for %s failed.\n",
> + path);
> + goto out;
> + }
> +
> + ret = rte_vhost_driver_disable_features(path,
> + VHOST_VDPA_BLK_DISABLED_FEATURES);
> + if (ret != 0) {
> + RTE_LOG(ERR, VDPA,
> + "rte_vhost_driver_disable_features for %s failed.\n",
> + path);
> + goto out;
> + }
> +
> + ret = rte_vhost_driver_get_protocol_features(path,
> &protocol_features);
> + if (ret != 0) {
> + RTE_LOG(ERR, VDPA,
> + "rte_vhost_driver_get_protocol_features for %s
> failed.\n",
> + path);
> + goto out;
> + }
> +
> + protocol_features |= (1ULL << VHOST_USER_PROTOCOL_F_CONFIG);
> + protocol_features |= (1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD);
> +
> + ret = rte_vhost_driver_set_protocol_features(path,
> protocol_features);
> + if (ret != 0) {
> + RTE_LOG(ERR, VDPA,
> + "rte_vhost_driver_set_protocol_features for %s
> failed.\n",
> + path);
> + goto out;
> + }
> +
> +out:
> + return ret;
> +}
> +
> +static int
> start_vdpa(struct vdpa_port *vport)
> {
> int ret;
> @@ -192,6 +242,15 @@ struct vdpa_port {
> "attach vdpa device failed: %s\n",
> socket_path);
>
> + if (isblk) {
> + RTE_LOG(NOTICE, VDPA, "is a blk device\n");
> + ret = vdpa_blk_device_set_features_and_protocol(socket_path);
> + if (ret != 0)
> + rte_exit(EXIT_FAILURE,
> + "set vhost blk driver features and protocol
> features failed: %s\n",
> + socket_path);
> + }
> +
> if (rte_vhost_driver_start(socket_path) < 0)
> rte_exit(EXIT_FAILURE,
> "start vhost driver failed: %s\n",
> diff --git a/examples/vdpa/vdpa_blk_compact.h
> b/examples/vdpa/vdpa_blk_compact.h
Please remove unused definition in this header. I didn't check all, but it
seems at least VHOST_BLK_PROTOCOL_FEATURES is not used.
> new file mode 100644
> index 000..e7c0f22
> --- /dev/null
> +++ b/examples/vdpa/vdpa_blk_compact.h
> @@ -0,0 +1,72 @@
> +/* SPDX-License-Identifie
Re: 21.11.1 patches review and test
On 20/04/2022 06:50, Christian Ehrhardt wrote: On Fri, Apr 1, 2022 at 12:22 PM Kevin Traynor wrote: Hi all, Here is a list of patches targeted for stable release 21.11.1. Please try and complete validation by April 13th. Please help with testing and validation of your use cases and report any issues/results with reply-all to this mail. For the final release the fixes and reported validations will be added to the release notes. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.1-rc1 These patches are located at branch 21.11 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Hi Kevin, now that the ABI change discussion has somewhat settled I have run the tests ignoring the symbols changes for now. All LGTM on Ubuntu 22.04 + OVS 2.17 + DPDK 21.11.1-rc1 1.0.0 (11:42:53): phys (BM) tests 1.1.0 (11:42:53): initialize environment 1.1.1 (11:44:54): testpmd => Pass 1.1.2 (11:45:43): check testpmd output => Pass 2.0.0 (11:45:43): prep virtual test environment 1.0.0 (11:48:05): virt tests 1.1.0 (11:48:05): initialize environment 3.0.0 (11:49:30): performance tests 3.1.0 (11:49:30): prep benchmarks 3.2.0 (11:49:51): performance tests 3.2.1 (11:50:02): test guest-openvswitch for OVS-5CPU => Pass 3.2.2 (12:09:30): test guest-dpdk-vhost-user-client-multiq for OVSDPDK-VUC => Pass 4.0.0 (12:28:54): VUC endurance checks 4.1.0 (12:28:54): prep VUC endurance tests 4.1.1 (12:41:59): start stop guests (client) => Pass 4.1.2 (13:48:30): add/remove ports (client) => Pass 4.2.0 (13:58:11): Final cleanup The above is kind of a high level test log, for the validation section of a stable release I usually use: * Build tests of DPDK & OVS 2.13.3 on Ubuntu 20.04 (meson based) * Functional and performance tests based on OVS-DPDK on x86_64 * Autopkgtests for DPDK and OpenvSwitch Thanks for the testing and Christian. I will add your summary to the validation section.
RE: [PATCH v6 08/16] usertools: add support for virtio blk device
> -Original Message-
> From: Pei, Andy
> Sent: Thursday, April 21, 2022 4:34 PM
> To: dev@dpdk.org
> Cc: Xia, Chenbo ; maxime.coque...@redhat.com; Cao,
> Gang ; Liu, Changpeng
> Subject: [PATCH v6 08/16] usertools: add support for virtio blk device
>
> Add virtio blk device support to devbind.
>
> Signed-off-by: Andy Pei
> ---
> usertools/dpdk-devbind.py | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
> index ace4627..cbe336f 100755
> --- a/usertools/dpdk-devbind.py
> +++ b/usertools/dpdk-devbind.py
> @@ -14,6 +14,8 @@
> from os.path import join as path_join
Supporting it in this script or not, it should not be named as 'XXX_class'.
And even may not be defined as new class. Maybe go to misc devices for now?
I'd like to hear others' opinion.
And Stephen commented about using driverctl, please reply to that.
Thanks,
Chenbo
>
> # The PCI base class for all devices
> +virtio_blk_class = {'Class': '01', 'Vendor': "1af4", 'Device': '1001',
> +'SVendor': '8086', 'SDevice': '0002'}
> network_class = {'Class': '02', 'Vendor': None, 'Device': None,
> 'SVendor': None, 'SDevice': None}
> acceleration_class = {'Class': '12', 'Vendor': None, 'Device': None,
> @@ -72,6 +74,7 @@
> cn9k_ree = {'Class': '08', 'Vendor': '177d', 'Device': 'a0f4',
> 'SVendor': None, 'SDevice': None}
>
> +virtio_blk_devices = [virtio_blk_class]
> network_devices = [network_class, cavium_pkx, avp_vnic, ifpga_class]
> baseband_devices = [acceleration_class]
> crypto_devices = [encryption_class, intel_processor_class]
> @@ -587,6 +590,9 @@ def show_status():
> Displays to the user what devices are bound to the igb_uio driver,
> the
> kernel driver or to no driver'''
>
> +if status_dev in ["virtio_blk", "all"]:
> +show_device_status(virtio_blk_devices, "virtio_blk")
> +
> if status_dev in ["net", "all"]:
> show_device_status(network_devices, "Network", if_field=True)
>
> @@ -746,6 +752,7 @@ def do_arg_actions():
> if b_flag is not None:
> clear_data()
> # refresh if we have changed anything
> +get_device_details(virtio_blk_devices)
> get_device_details(network_devices)
> get_device_details(baseband_devices)
> get_device_details(crypto_devices)
> @@ -769,6 +776,7 @@ def main():
> parse_args()
> check_modules()
> clear_data()
> +get_device_details(virtio_blk_devices)
> get_device_details(network_devices)
> get_device_details(baseband_devices)
> get_device_details(crypto_devices)
> --
> 1.8.3.1
[Bug 992] [dpdk 21.11.1-rc1] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag param optimization=1 on Ubuntu20.04 with GCC10.3
https://bugs.dpdk.org/show_bug.cgi?id=992 Kevin Traynor (ktray...@redhat.com) changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Kevin Traynor (ktray...@redhat.com) --- Thanks for validating. I applied the patch to 21.11 stable branch. https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=213001231857c9af72f8f0288c43773b1ac2d580 -- You are receiving this mail because: You are the assignee for the bug.
RE: [v4 1/3] ethdev: introduce protocol type based header split
Hi Andrew, > -Original Message- > From: Andrew Rybchenko > Sent: Wednesday, April 20, 2022 11:48 PM > To: Ding, Xuan ; Wu, WenxuanX > ; tho...@monjalon.net; Li, Xiaoyun > ; Singh, Aman Deep ; > Zhang, Yuying ; Zhang, Qi Z > Cc: dev@dpdk.org; step...@networkplumber.org; > m...@smartsharesystems.com; viachesl...@nvidia.com; Yu, Ping > ; Wang, YuanX ; > david.march...@redhat.com; Ferruh Yigit > Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split > > Hi Xuan, > > On 4/12/22 19:15, Ding, Xuan wrote: > > Hi Andrew, > > > >> -Original Message- > >> From: Andrew Rybchenko > >> Sent: Thursday, April 7, 2022 6:48 PM > >> To: Wu, WenxuanX ; tho...@monjalon.net; > Li, > >> Xiaoyun ; Singh, Aman Deep > >> ; Zhang, Yuying ; > >> Zhang, Qi Z > >> Cc: dev@dpdk.org; step...@networkplumber.org; > >> m...@smartsharesystems.com; viachesl...@nvidia.com; Yu, Ping > >> ; Ding, Xuan ; Wang, YuanX > >> ; david.march...@redhat.com; Ferruh Yigit > >> > >> Subject: Re: [v4 1/3] ethdev: introduce protocol type based header > >> split > >> > >> On 4/2/22 13:41, wenxuanx...@intel.com wrote: > >>> From: Xuan Ding > >>> > >>> Header split consists of splitting a received packet into two > >>> separate regions based on the packet content. The split happens > >>> after the packet header and before the packet payload. Splitting is > >>> usually between the packet header that can be posted to a dedicated > >>> buffer and the packet payload that can be posted to a different buffer. > >>> > >>> Currently, Rx buffer split supports length and offset based packet split. > >>> Although header split is a subset of buffer split, configuring > >>> buffer split based on length is not suitable for NICs that do split > >>> based on header protocol types. Because tunneling makes the > >>> conversion from length to protocol type impossible. > >>> > >>> This patch extends the current buffer split to support protocol type > >>> and offset based header split. A new proto field is introduced in > >>> the rte_eth_rxseg_split structure reserved field to specify header > >>> protocol type. With Rx offload flag > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT > >>> enabled and protocol type configured, PMD will split the ingress > >>> packets into two separate regions. Currently, both inner and outer > >>> L2/L3/L4 level header split can be supported. > >> > >> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload was introduced some time > ago > >> to substitute bit-field header_split in struct rte_eth_rxmode. It > >> allows to enable header split offload with the header size controlled > >> using split_hdr_size in the same structure. > >> > >> Right now I see no single PMD which actually supports > >> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT with above definition. > >> Many examples and test apps initialize the field to 0 explicitly. The > >> most of drivers simply ignore split_hdr_size since the offload is not > >> advertised, but some double-check that its value is 0. > >> > >> I think that it means that the field should be removed on the next > >> LTS, and I'd say, together with the RTE_ETH_RX_OFFLOAD_HEADER_SPLIT > offload bit. > >> > >> We should not redefine the offload meaning. > > > > Yes, you are right. No single PMD supports > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT now. > > Previously, I used this flag is to distinguish buffer split and header > > split. > > The former supports multi-segments split by length and offset. > > offset is misleading here, since split offset is derived from segment lengths. > Offset specified in segments is a different thing. Yes, the length defines the segment length, and the offset defines the data offset in mbuf. The usage of length and offset are explained in the comments, but it is somewhat misleading just from name. > > > The later supports two segments split by proto and offset. > > At this level, header split is a subset of buffer split. > > IMHO, generic definition of the header split should not limit it by just two > segments. Does the header split here refer to the traditional header split? If so, since you mentioned before we should not redefine the offload meaning, I will use protocol and mbuf_offset based buffer split in next version. It is worth noting that the purpose of specifying the split location by protocol is to divide a packet into two segments. If you want to divide into multiple segments, it should still be specified by length. > > > > > Since we shouldn't redefine the meaning of this offload, I will use > > the RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag. > > The existence of tunnel needs to define a proto field in buffer split, > > because some PMDs do not support split based on length and offset. > > Not sure that I fully understand, but I'm looking forward to review v5. Thanks for your comments, I will send a v5, including these main changes: 1. Use protocol and mbuf_offset based buffer split instead of header split. 2. Use RTE_PTYPE* instead of enum rte_eth_rx_header_split_protocol_t
Re: 21.11.1 patches review and test
On 14/04/2022 05:58, Jiang, YuX wrote: -Original Message- From: Jiang, YuX Sent: Tuesday, April 12, 2022 4:59 PM To: Kevin Traynor ; sta...@dpdk.org Cc: dev@dpdk.org; Abhishek Marathe ; Ali Alnubani ; Walker, Benjamin ; David Christensen ; hariprasad.govindhara...@intel.com; Hemant Agrawal ; Stokes, Ian ; Jerin Jacob ; Mcnamara, John ; Ju-Hyoung Lee ; Luca Boccassi ; Pei Zhang ; Xu, Qian Q ; Raslan Darawsheh ; Thomas Monjalon ; Peng, Yuan ; Chen, Zhaoyan Subject: RE: 21.11.1 patches review and test -Original Message- From: Kevin Traynor Sent: Friday, April 1, 2022 6:22 PM To: sta...@dpdk.org Cc: dev@dpdk.org; Abhishek Marathe ; Ali Alnubani ; Walker, Benjamin ; David Christensen ; hariprasad.govindhara...@intel.com; Hemant Agrawal ; Stokes, Ian ; Jerin Jacob ; Mcnamara, John ; Ju-Hyoung Lee ; Kevin Traynor ; Luca Boccassi ; Pei Zhang ; Xu, Qian Q ; Raslan Darawsheh ; Thomas Monjalon ; Peng, Yuan ; Chen, Zhaoyan Subject: 21.11.1 patches review and test Hi all, Here is a list of patches targeted for stable release 21.11.1. Please try and complete validation by April 13th. Please help with testing and validation of your use cases and report any issues/results with reply-all to this mail. For the final release the fixes and reported validations will be added to the release notes. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.1-rc1 These patches are located at branch 21.11 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Thanks. Kevin --- Update the test status for Intel part. Till now dpdk21.11.1-rc1 test rate is 90%. Till now, no critical issue is found. Failure defect: Bug1: https://bugs.dpdk.org/show_bug.cgi?id=992 [dpdk 21.11.1-rc1] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag param optimization=1 on Ubuntu20.04 with GCC10.3 > It was found in 22.03- rc2(https://bugs.dpdk.org/show_bug.cgi?id=939), validation team apply 939's patch failed. Need new patch for LTS21.11.1-rc1. # Basic Intel(R) NIC testing * Build&CFLAG compile: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, etc. - All test done. Find new bug: Bug1, not fix. * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * VF(i40e, ixgbe): test scenarios including VF- RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - All test done. No new dpdk issue is found. * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, etc. - All test done. No big performance drop. * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - All test passed. * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc. - All test passed. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u3, etc. - All test done. No new issue is found. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - Test rate: 80%, no new issue is found currently. *Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. - Test rate: 80%, no new issue is found currently. Update the test status for Intel part. Till now dpdk21.11.1-rc1 test is almost finished. Till now, no critical issue is found. Failure defect: Bug1: https://bugs.dpdk.org/show_bug.cgi?id=992 [dpdk 21.11.1-rc1] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag param optimization=1 on Ubuntu20.04 with GCC10.3 > Verify patchset http://inbox.dpdk.org/stable/20220413120511.566715-1-ktray...@redhat.com/T/#u on baseline 21.11.1-rc1, test passed. Thanks for checking this. I have applied the patch to 21.11 branch now. # Basic Intel(R) NIC testing * Build&CFLAG compile: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, etc. - All test done. Find new bug: Bug1. * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test done. No new dpdk issue is found. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - All test done. No new dpdk issue is f
RE: [v4 1/3] ethdev: introduce protocol type based header split
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, April 21, 2022 6:28 PM
> To: Andrew Rybchenko ; Wu, WenxuanX
> ; Li, Xiaoyun ; Singh,
> Aman Deep ; Zhang, Yuying
> ; Zhang, Qi Z ;
> dev@dpdk.org
> Cc: dev@dpdk.org; step...@networkplumber.org;
> m...@smartsharesystems.com; viachesl...@nvidia.com; Yu, Ping
> ; Wang, YuanX ;
> david.march...@redhat.com; Ferruh Yigit ; Ding, Xuan
>
> Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split
>
> 12/04/2022 18:15, Ding, Xuan:
> > From: Andrew Rybchenko
> > > On 4/2/22 13:41, wenxuanx...@intel.com wrote:
> > > > From: Xuan Ding
> > > >
> > > > Header split consists of splitting a received packet into two
> > > > separate regions based on the packet content. The split happens
> > > > after the packet header and before the packet payload. Splitting
> > > > is usually between the packet header that can be posted to a
> > > > dedicated buffer and the packet payload that can be posted to a
> different buffer.
> > > >
> > > > Currently, Rx buffer split supports length and offset based packet
> > > > split.
> > > > Although header split is a subset of buffer split, configuring
> > > > buffer split based on length is not suitable for NICs that do
> > > > split based on header protocol types. Because tunneling makes the
> > > > conversion from length to protocol type impossible.
> > > >
> > > > This patch extends the current buffer split to support protocol
> > > > type and offset based header split. A new proto field is
> > > > introduced in the rte_eth_rxseg_split structure reserved field to
> > > > specify header protocol type. With Rx offload flag
> > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and protocol type
> > > > configured, PMD will split the ingress packets into two separate
> > > > regions. Currently, both inner and outer
> > > > L2/L3/L4 level header split can be supported.
> > >
> > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload was introduced some
> time ago
> > > to substitute bit-field header_split in struct rte_eth_rxmode. It
> > > allows to enable header split offload with the header size
> > > controlled using split_hdr_size in the same structure.
> > >
> > > Right now I see no single PMD which actually supports
> > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT with above definition.
> > > Many examples and test apps initialize the field to 0 explicitly.
> > > The most of drivers simply ignore split_hdr_size since the offload
> > > is not advertised, but some double-check that its value is 0.
> > >
> > > I think that it means that the field should be removed on the next
> > > LTS, and I'd say, together with the
> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload bit.
> > >
> > > We should not redefine the offload meaning.
> >
> > Yes, you are right. No single PMD supports
> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT now.
> > Previously, I used this flag is to distinguish buffer split and header
> > split.
> > The former supports multi-segments split by length and offset.
> > The later supports two segments split by proto and offset.
> > At this level, header split is a subset of buffer split.
> >
> > Since we shouldn't redefine the meaning of this offload, I will use
> > the RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag.
> > The existence of tunnel needs to define a proto field in buffer split,
> > because some PMDs do not support split based on length and offset.
>
> Before doing anything, the first patch of this series should make the current
> status clearer.
> Example, this line does not explain what it does:
> uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
> And header_split has been removed in ab3ce1e0c193 ("ethdev: remove old
> offload API")
>
> If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a comment
> to start a deprecation.
Agree, I discussed with Andrew before that RTE_ETH_RX_OFFLOAD_HEADER_SPLIT
is no longer supported by any PMDs.
I can send a separate patch of header split deprecation notice in 22.07,
and start removing the code in 22.11. What do you think?
>
> > > > For example, let's suppose we configured the Rx queue with the
> > > > following segments:
> > > > seg0 - pool0, off0=2B
> > > > seg1 - pool1, off1=128B
> > >
> > > Corresponding feature is named Rx buffer split.
> > > Does it mean that protocol type based header split requires Rx
> > > buffer split feature to be supported?
> >
> > Protocol type based header split does not requires Rx buffer split.
> > In previous design, the header split and buffer split are exclusive.
> > Because we only configure one split offload for one RX queue.
>
> Things must be made clear and documented.
Thanks for your suggestion, the documents will be improved in v5.
>
> > > > With header split type configured with
> > > > RTE_ETH_RX_HEADER_SPLIT_UDP, the packet consists of
> MAC_IP_UDP_PAYLOAD will be split like following:
> > > > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from
> > > pool0
> > > > seg1 - p
OVS DPDK DMA-Dev library/Design Discussion
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+ RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETFROM:+ TZOFFSETTO:+0100 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN="Mcnamara, John":mailto:john.mcnam...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stokes, Ia n":mailto:ian.sto...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Pai G, Sun il":mailto:sunil.pa...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hu, Jiayu": mailto:jiayu...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ferriter, Cian":mailto:cian.ferri...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Van Haaren , Harry":mailto:harry.van.haa...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ilya Maxim ets:mailto:i.maxim...@ovn.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Maxime Coq uelin (maxime.coque...@redhat.com):mailto:maxime.coque...@redhat.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ovs-dev@op envswitch.org:mailto:ovs-...@openvswitch.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=dev@dpdk.o rg:mailto:dev@dpdk.org ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="O'Driscoll , Tim":mailto:tim.odrisc...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Finn, Emma" :mailto:emma.f...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ralf Hoffm ann:mailto:ralf.hoffm...@allegro-packets.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Harris, Ja mes R":mailto:james.r.har...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Luse, Paul E":mailto:paul.e.l...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=hemal.shah @broadcom.com:mailto:hemal.s...@broadcom.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Gooch, Ste phen":mailto:stephen.go...@windriver.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Bing Zhao: mailto:bi...@nvidia.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wiles, Kei th":mailto:keith.wi...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Prasanna M urugesan (prasanna):mailto:prasa...@cisco.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ananyev, K onstantin":mailto:konstantin.anan...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Yu, De":mai lto:de...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Tom Barbet te:mailto:tom.barbe...@uclouvain.be ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zeng, Zhic haoX":mailto:zhichaox.z...@intel.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Knight, Jo shua":mailto:joshua.kni...@netscout.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Scheurich, Jan":mailto:jan.scheur...@ericsson.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Sinai, Asa f":mailto:asa...@radware.com DESCRIPTION;LANGUAGE=en-US:Updated with meeting and presentation.\n\nThis m eeting is a follow-up to the previous calls in March and the discussion wh ich has happened since on the DPDK and OVS mailing lists.\n\nThree approac hes were presented in the previous calls:\n\n• "Defer work": Handl e DMA completions at OVS PMD thread level\n• "v3": Handle DMA Tx c ompletions from Rx context.\n• "v3 + lockless ring": Handle DMA Tx completions from Rx context + lockless ring to avoid contention.\n\nAfter these calls\, the discussion continued on the DPDK and OVS mailing lists\ , where an alternate approach has been proposed.\n\nThe newly-suggested ap proach:\n\n• "DMA VirtQ Completions": Add an additional transactio n(s) to each burst of DMA copies\; a special transaction containing the me mory write operation that makes the descriptors available to the Virtio dr iver. Also separate the actual kick of the guest with the data transfer.\n \nAgenda for call 26th April:\n\n• Intel team will present slides to help understand the differences in architecture/designs.\n• Dis cuss the strengths/weaknesses/feasibility of the "DMA VirtQ Completions" a pproach\, comparing to current best-candidate "Defer Work".\n• Wor k toward single-solution to be accepted upstream in DPDK and OVS\n\nSlides : https://github.com/Sunil-Pai-G/OVS-DPDK-presentation-share/blob/main/ovs _datapath_design_2022%20session%203.pdf\n\nGoogle Meet: https://meet.googl e.com/hme-pygf-bfb\n\n\n\n\
Re: [PATCH 2/2] app/testpmd: fix incorrect MTU verification
On 4/6/2022 2:15 PM, Min Hu (Connor) wrote:
From: Huisong Li
The macro RTE_ETHER_MIN_LEN isn't the minimum value of MTU. But testpmd
used it when execute 'port config mtu 0 xx' cmd. This patch fix it.
Fixes: 1bb4a528c41f ("ethdev: fix max Rx packet length")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
app/test-pmd/cmdline.c | 4 ---
app/test-pmd/config.c | 55 ++
2 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6ffea8e21a..91e4090582 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2050,10 +2050,6 @@ cmd_config_mtu_parsed(void *parsed_result,
{
struct cmd_config_mtu_result *res = parsed_result;
- if (res->value < RTE_ETHER_MIN_LEN) {
- fprintf(stderr, "mtu cannot be less than %d\n",
RTE_ETHER_MIN_LEN);
- return;
- }
port_mtu_set(res->port_id, res->value);
}
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index bd689f9f86..1b1e738f83 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1254,6 +1254,57 @@ port_reg_set(portid_t port_id, uint32_t reg_off,
uint32_t reg_v)
display_port_reg_value(port_id, reg_off, reg_v);
}
+static uint32_t
+eth_dev_get_overhead_len(uint32_t max_rx_pktlen, uint16_t max_mtu)
+{
+ uint32_t overhead_len;
+
+ if (max_mtu != UINT16_MAX && max_rx_pktlen > max_mtu)
+ overhead_len = max_rx_pktlen - max_mtu;
+ else
+ overhead_len = RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN;
+
+ return overhead_len;
+}
+
+static int
+eth_dev_validate_mtu(uint16_t port_id, uint16_t mtu)
+{
+ struct rte_eth_dev_info dev_info;
+ uint32_t overhead_len;
+ uint32_t frame_size;
+ int ret;
+
+ ret = rte_eth_dev_info_get(port_id, &dev_info);
+ if (ret != 0)
+ return ret;
+
+ if (mtu < dev_info.min_mtu) {
+ fprintf(stderr,
+ "MTU (%u) < device min MTU (%u) for port_id %u\n",
+ mtu, dev_info.min_mtu, port_id);
+ return -EINVAL;
+ }
+ if (mtu > dev_info.max_mtu) {
+ fprintf(stderr,
+ "MTU (%u) > device max MTU (%u) for port_id %u\n",
+ mtu, dev_info.max_mtu, port_id);
+ return -EINVAL;
+ }
+
+ overhead_len = eth_dev_get_overhead_len(dev_info.max_rx_pktlen,
+ dev_info.max_mtu);
+ frame_size = mtu + overhead_len;
+ if (frame_size > dev_info.max_rx_pktlen) {
+ fprintf(stderr,
+ "Frame size (%u) > device max frame size (%u) for port_id
%u\n",
+ frame_size, dev_info.max_rx_pktlen, port_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
void
port_mtu_set(portid_t port_id, uint16_t mtu)
{
@@ -1263,6 +1314,10 @@ port_mtu_set(portid_t port_id, uint16_t mtu)
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
+ diag = eth_dev_validate_mtu(port_id, mtu);
+ if (diag != 0)
+ return;
+
if (port->need_reconfig == 0) {
diag = rte_eth_dev_set_mtu(port_id, mtu);
if (diag != 0) {
I just wanted to know if these added functions eth_dev_validate_mtu() &
eth_dev_get_overhead_len()
are copy of ethdev library API's in file "rte_ethdev.c", which get
called by rte_eth_dev_set_mtu.
Is our intent, is to call these twice ?
Minutes of Technical Board Meeting, 2022-April-20
Minutes of Technical Board Meeting, 2022-April-20 Members Attending --- -Aaron -Bruce -Hemant -Honnappa -Jerin -Konstantin (chair) -Maxime -Stephen -Thomas NOTE: The technical board meetings are on every second Wednesday at https://meet.jit.si/DPDK at 3 pm UTC. Meetings are public, and DPDK community members are welcome to attend. NOTE: Next meeting will be on Wednesday 2021-May-4 @3pm UTC, and will be chaired by Kevin. 1) Testpmd gRPC support https://patches.dpdk.org/project/dpdk/cover/20220407214707.29730-1-ohily...@iol.unh.edu/ Discussion summary: In general seems like a move in a right direction, though there are some concerns about amount and complexity of the new code to be added. Need to implement some realistic test-case to better understand/estimate all complexities and implications. CLI/gRPC interface: while gRPC should be very useful for CI, we still need to support CLI interface for developers (and current testing environment). So both interfaces should co-exist. For future direction: to minimize amount of code and simplify CLI support, we may consider to re-implement existing CLI commands on top of gRPC interface. Conclusion: TB recommendation to go ahead with RFCv2 that should cover some realistic testpmd scenario (http://git.dpdk.org/tools/dts/tree/test_plans/nic_single_core_perf_test_plan.rst or so). 2) Enrolment DPDK into HackerOne bug bounty program https://www.hackerone.com/ Q&A session: - align with the big community of hackers - H1 team can do the initial investigation of reported vulnerabilities - Disclosure policy can be defined by the community itself - Mostly finding and reporting tool at that moment: actual fixing is usually out of scope, but might be encouraged by reward policy. - Kubernetes involvement (http://hackerone.com/kubernetes) as an successful example of open-source project enrolment. - Can be tried/evaluated for limited amount of time (year/few months). Concerns raised: - Could be a lot of false-positives that H1 triage wouldn't be able to cope with (at least at initial stage), so still would require significant effort from DPDK security team (and rest of the community) for further evaluation and (/or) fixing. No final decision met, discussion to continue. 3) Technical Writer interview process Bruce and Stephen (as native English speakers) agreed to conduct. Suggested to inform other TB members about forth-coming interviews, so other interested people (Thomas, Jerin, Konstantin) can participate too. 4) DPDK UserSpace 2022 event schedule Discussion in progress.
Re: OVS DPDK DMA-Dev library/Design Discussion
On 4/20/22 18:41, Mcnamara, John wrote:
>> -Original Message-
>> From: Ilya Maximets
>> Sent: Friday, April 8, 2022 10:58 AM
>> To: Hu, Jiayu ; Maxime Coquelin
>> ; Van Haaren, Harry
>> ; Morten Brørup ;
>> Richardson, Bruce
>> Cc: i.maxim...@ovn.org; Pai G, Sunil ; Stokes, Ian
>> ; Ferriter, Cian ; ovs-
>> d...@openvswitch.org; dev@dpdk.org; Mcnamara, John
>> ; O'Driscoll, Tim ;
>> Finn, Emma
>> Subject: Re: OVS DPDK DMA-Dev library/Design Discussion
>>
>> On 4/8/22 09:13, Hu, Jiayu wrote:
>>>
>>>
-Original Message-
From: Ilya Maximets
Sent: Thursday, April 7, 2022 10:40 PM
To: Maxime Coquelin ; Van Haaren, Harry
; Morten Brørup
; Richardson, Bruce
Cc: i.maxim...@ovn.org; Pai G, Sunil ; Stokes,
Ian ; Hu, Jiayu ; Ferriter,
Cian ; ovs-...@openvswitch.org;
dev@dpdk.org; Mcnamara, John ; O'Driscoll,
Tim ; Finn, Emma
Subject: Re: OVS DPDK DMA-Dev library/Design Discussion
On 4/7/22 16:25, Maxime Coquelin wrote:
> Hi Harry,
>
> On 4/7/22 16:04, Van Haaren, Harry wrote:
>> Hi OVS & DPDK, Maintainers & Community,
>>
>> Top posting overview of discussion as replies to thread become
>> slower:
>> perhaps it is a good time to review and plan for next steps?
>>
>> From my perspective, it those most vocal in the thread seem to be
>> in favour of the clean rx/tx split ("defer work"), with the
>> tradeoff that the application must be aware of handling the async
>> DMA completions. If there are any concerns opposing upstreaming of
>> this
method, please indicate this promptly, and we can continue technical
discussions here now.
>
> Wasn't there some discussions about handling the Virtio completions
> with the DMA engine? With that, we wouldn't need the deferral of work.
+1
With the virtio completions handled by DMA itself, the vhost port
turns almost into a real HW NIC. With that we will not need any
extra manipulations from the OVS side, i.e. no need to defer any work
while maintaining clear split between rx and tx operations.
>>>
>>> First, making DMA do 2B copy would sacrifice performance, and I think
>>> we all agree on that.
>>
>> I do not agree with that. Yes, 2B copy by DMA will likely be slower than
>> done by CPU, however CPU is going away for dozens or even hundreds of
>> thousands of cycles to process a new packet batch or service other ports,
>> hence DMA will likely complete the transmission faster than waiting for
>> the CPU thread to come back to that task. In any case, this has to be
>> tested.
>>
>>> Second, this method comes with an issue of ordering.
>>> For example, PMD thread0 enqueue 10 packets to vring0 first, then PMD
>>> thread1 enqueue 20 packets to vring0. If PMD thread0 and threa1 have
>>> own dedicated DMA device dma0 and dma1, flag/index update for the
>>> first 10 packets is done by dma0, and flag/index update for the left
>>> 20 packets is done by dma1. But there is no ordering guarantee among
>>> different DMA devices, so flag/index update may error. If PMD threads
>>> don't have dedicated DMA devices, which means DMA devices are shared
>>> among threads, we need lock and pay for lock contention in data-path.
>>> Or we can allocate DMA devices for vring dynamically to avoid DMA
>>> sharing among threads. But what's the overhead of allocation mechanism?
>> Who does it? Any thoughts?
>>
>> 1. DMA completion was discussed in context of per-queue allocation, so
>> there
>>is no re-ordering in this case.
>>
>> 2. Overhead can be minimal if allocated device can stick to the queue for
>> a
>>reasonable amount of time without re-allocation on every send. You may
>>look at XPS implementation in lib/dpif-netdev.c in OVS for example of
>>such mechanism. For sure it can not be the same, but ideas can be re-
>> used.
>>
>> 3. Locking doesn't mean contention if resources are allocated/distributed
>>thoughtfully.
>>
>> 4. Allocation can be done be either OVS or vhost library itself, I'd vote
>>for doing that inside the vhost library, so any DPDK application and
>>vhost ethdev can use it without re-inventing from scratch. It also
>> should
>>be simpler from the API point of view if allocation and usage are in
>>the same place. But I don't have a strong opinion here as for now,
>> since
>>no real code examples exist, so it's hard to evaluate how they could
>> look
>>like.
>>
>> But I feel like we're starting to run in circles here as I did already say
>> most of that before.
>
>
Hi, John.
Just reading this email as I was on PTO for a last 1.5 weeks
and didn't get through all the emails yet.
> This does seem to be going in circles, especially since there seemed to be
> technical alignment on the last public call on March 29th.
I guess, there is a typo in the date here.
It seems to be 26th, not 29th.
> It is not feasible to do a real world implem
[Bug 992] [dpdk 21.11.1-rc1] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag param optimization=1 on Ubuntu20.04 with GCC10.3
https://bugs.dpdk.org/show_bug.cgi?id=992
gaodaxue (daxuex@intel.com) changed:
What|Removed |Added
Status|VERIFIED|UNCONFIRMED
Resolution|FIXED |---
--- Comment #5 from gaodaxue (daxuex@intel.com) ---
In the latest dpdk-stable v21.11.1-rc1 code.
commit id: 05aa560efc
[Error info]
[1283/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev_mtr.c.o
FAILED: drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev_mtr.c.o
gcc -Idrivers/libtmp_rte_net_cnxk.a.p -Idrivers -I../drivers -Idrivers/net/cnxk
-I../drivers/net/cnxk -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig
-I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include
-I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include
-Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs
-I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry
-I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf
-Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter
-I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
-I../drivers/bus/vdev -Ilib/cryptodev -I../lib/cryptodev -Ilib/rcu -I../lib/rcu
-Ilib/eventdev -I../lib/eventdev -Ilib/hash -I../lib/hash -Ilib/timer
-I../lib/timer -Ilib/security -I../lib/security -Idrivers/common/cnxk
-I../drivers/common/cnxk -Idrivers/mempool/cnxk -I../drivers/mempool/cnxk
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Werror -O1 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -flax-vector-conversions -Wno-strict-aliasing
-DRTE_LOG_DEFAULT_LOGTYPE=pmd.net.cnxk -MD -MQ
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev_mtr.c.o -MF
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev_mtr.c.o.d -o
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev_mtr.c.o -c
../drivers/net/cnxk/cnxk_ethdev_mtr.c
In file included from ../drivers/net/cnxk/cnxk_ethdev.h:16,
from ../drivers/net/cnxk/cnxk_ethdev_mtr.c:5:
../drivers/net/cnxk/cnxk_ethdev_mtr.c: In function
‘cnxk_nix_mtr_policy_validate’:
../lib/ethdev/rte_mtr_driver.h:188:10: error: ‘str’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
188 | *error = (struct rte_mtr_error){
| ~~~^
189 |.type = type,
|~
190 |.cause = cause,
|~~~
191 |.message = message,
|~~~
192 | };
| ~
../drivers/net/cnxk/cnxk_ethdev_mtr.c:283:14: note: ‘str’ was declared here
283 | const char *str;
| ^~~
In file included from ../drivers/net/cnxk/cnxk_ethdev.h:16,
from ../drivers/net/cnxk/cnxk_ethdev_mtr.c:5:
../lib/ethdev/rte_mtr_driver.h:188:10: error: ‘str’ may be used uninitialized
in this function [-Werror=maybe-uninitialized]
188 | *error = (struct rte_mtr_error){
| ~~~^
189 |.type = type,
|~
190 |.cause = cause,
|~~~
191 |.message = message,
|~~~
192 | };
| ~
../drivers/net/cnxk/cnxk_ethdev_mtr.c:283:14: note: ‘str’ was declared here
283 | const char *str;
| ^~~
cc1: all warnings being treated as errors
[1284/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_rte_flow.c.o
[1285/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ethdev.c.o
[1286/3000] Compiling C object
drivers/libtmp_rte_net_bond.a.p/net_bonding_rte_eth_bond_8023ad.c.o
[1287/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_ptp.c.o
[1288/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_stats.c.o
[1289/3000] Generating rte_net_bnxt.pmd.c with a custom command
[1290/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cn9k_ethdev.c.o
[1291/3000] Compiling C object
drivers/libtmp_rte_net_cnxk.a.p/net_cnxk_cnxk_tm.c.o
[1292/3000] Compiling C object
drivers/libtmp_rte_net_bond.a.p/net_bonding_rte_eth_bond_pmd.c.o
ninja: build stopped: subcommand failed.Removing buildtools/__pycache__/
Removing x86_64-native-linuxapp-gcc/
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 992] [dpdk 21.11.1-rc1] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag param optimization=1 on Ubuntu20.04 with GCC10.3
https://bugs.dpdk.org/show_bug.cgi?id=992 gaodaxue (daxuex@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from gaodaxue (daxuex@intel.com) --- Verified based on 2130012318 PASSED. OS: Ubuntu 20.04.3 LTS/Linux 5.8.0-48-generic GCC: gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04) -- You are receiving this mail because: You are the assignee for the bug.
RE: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper
Hi Jerin, Thanks for your comments and sorry for the late response. For case one, I think I can refine the design and add LWM(limit watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. For case two(host shaper), I think we can't use RX meter, because it's actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have two terms here: Host-system stands for the system the BF2 NIC is inserted; ARM-system stands for the embedded ARM in BF2. ARM-system is doing the forwarding. This is the way host shaper works: we configure the register on ARM-system, but it affects Host-system's TX shaper, which means the shaper is working on the remote port, it's not a RX meter concept, hence we can't use DPDK RX meter framework. I'd suggest to still use private API. For testpmd part, I understand your concern. Because we need one private API for host shaper, and we need testpmd's forwarding code to show how it works to user, we need to call the private API in testpmd. If current patch is not acceptable, what's the correct way to do it? Any framework to isolate the PMD private logic from testpmd common code, but still give a chance to call private APIs in testpmd? Regards, Spike. > -Original Message- > From: Jerin Jacob > Sent: Tuesday, April 5, 2022 4:59 PM > To: Spike Du ; Andrew Rybchenko > ; Cristian Dumitrescu > ; Ferruh Yigit ; > techbo...@dpdk.org > Cc: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; NBU-Contact- > Thomas Monjalon (EXTERNAL) ; dpdk-dev > ; Raslan Darawsheh > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > External email: Use caution opening links or attachments > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du wrote: > > > > LWM(limit watermark) is per RX queue attribute, when RX queue fullness > > reach the LWM limit, HW sends an event to dpdk application. > > Host shaper can configure shaper rate and lwm-triggered for a host port. > > The shaper limits the rate of traffic from host port to wire port. > > If lwm-triggered is enabled, a 100Mbps shaper is enabled automatically > > when one of the host port's Rx queues receives LWM event. > > > > These two features can combine to control traffic from host port to wire > port. > > The work flow is configure LWM to RX queue and enable lwm-triggered > > flag in host shaper, after receiving LWM event, delay a while until RX > > queue is empty , then disable the shaper. We recycle this work flow to > reduce RX queue drops. > > > > Spike Du (6): > > net/mlx5: add LWM support for Rxq > > common/mlx5: share interrupt management > > net/mlx5: add LWM event handling support > > net/mlx5: add private API to configure Rxq LWM > > net/mlx5: add private API to config host port shaper > > app/testpmd: add LWM and Host Shaper command > > + @Andrew Rybchenko @Ferruh Yigit cristian.dumitre...@intel.com > > I think, case one, can be easily abstracted via adding new > rte_eth_event_type event and case two can be abstracted via the existing > Rx meter framework in ethdev. > > Also, Updating generic testpmd to support PMD specific API should be > avoided, I know there is existing stuff in testpmd, I think, we should have > the > policy to add PMD specific commands to testpmd. > > There are around 56PMDs in ethdev now, If PMDs try to add PMD specific > API in testpmd it will be bloated or at minimum, it should a separate file in > testpmd if we choose to take that path. > > + @techbo...@dpdk.org
[PATCH v5 0/5] add telemetry command for show module EEPROM
Introduce a new telemetry command /ethdev/module_eeprom to show module EEPROM for each port. The format of module EEPROM information follows the SFF(Small Form Factor) Committee specifications. Current the format support SFP(Small Formfactor Pluggable)/SFP+/ QSFP+(Quad Small Formfactor Pluggable)/QSFP28 with specs SFF-8079/ SFF-8472/SFF-8024/SFF-8636. Afther run the /ethdev/module_eeprom command, telemetry client will show the module EEPROM information. We keep the same information content compare with Linux utility ethtool, refer to command 'ethtool -m' of ethtool v5.4. v5: - fix CI robot compile fail issue v4: - remove all printf in primary application, only show information in tememetry client - refine codes v3: - split up codes into several patches for better reivew Robin Zhang (5): ethdev: add telemetry command for module EEPROM ethdev: common utilities for different SFF specs ethdev: format module EEPROM for SFF-8079 ethdev: format module EEPROM for SFF-8472 ethdev: format module EEPROM for SFF-8636 lib/ethdev/ethdev_sff_telemetry.c | 142 ++ lib/ethdev/ethdev_sff_telemetry.h | 37 ++ lib/ethdev/meson.build| 5 + lib/ethdev/rte_ethdev.c | 3 + lib/ethdev/sff_8079.c | 407 lib/ethdev/sff_8472.c | 287 +++ lib/ethdev/sff_8636.c | 775 ++ lib/ethdev/sff_8636.h | 592 +++ lib/ethdev/sff_common.c | 326 + lib/ethdev/sff_common.h | 174 +++ 10 files changed, 2748 insertions(+) create mode 100644 lib/ethdev/ethdev_sff_telemetry.c create mode 100644 lib/ethdev/ethdev_sff_telemetry.h create mode 100644 lib/ethdev/sff_8079.c create mode 100644 lib/ethdev/sff_8472.c create mode 100644 lib/ethdev/sff_8636.c create mode 100644 lib/ethdev/sff_8636.h create mode 100644 lib/ethdev/sff_common.c create mode 100644 lib/ethdev/sff_common.h -- 2.25.1
[PATCH v5 1/5] ethdev: add telemetry command for module EEPROM
Add a new telemetry command /ethdev/module_eeprom to dump the module
EEPROM of each port. The format of module EEPROM information follows
the SFF(Small Form Factor) Committee specifications.
Current the format support SFP(Small Formfactor Pluggable)/SFP+/
QSFP+(Quad Small Formfactor Pluggable)/QSFP28 with specs SFF-8079/
SFF-8472/SFF-8024/SFF-8636.
Signed-off-by: Robin Zhang
---
lib/ethdev/ethdev_sff_telemetry.c | 131 ++
lib/ethdev/ethdev_sff_telemetry.h | 37 +
lib/ethdev/meson.build| 1 +
lib/ethdev/rte_ethdev.c | 3 +
4 files changed, 172 insertions(+)
create mode 100644 lib/ethdev/ethdev_sff_telemetry.c
create mode 100644 lib/ethdev/ethdev_sff_telemetry.h
diff --git a/lib/ethdev/ethdev_sff_telemetry.c
b/lib/ethdev/ethdev_sff_telemetry.c
new file mode 100644
index 00..968b640b17
--- /dev/null
+++ b/lib/ethdev/ethdev_sff_telemetry.c
@@ -0,0 +1,131 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+#include "ethdev_sff_telemetry.h"
+
+static uint16_t sff_item_count;
+
+static void
+sff_port_module_eeprom_display(uint16_t port_id, struct sff_item *items)
+{
+ struct rte_eth_dev_module_info minfo;
+ struct rte_dev_eeprom_info einfo;
+ int ret;
+
+ ret = rte_eth_dev_get_module_info(port_id, &minfo);
+ if (ret != 0) {
+ switch (ret) {
+ case -ENODEV:
+ RTE_ETHDEV_LOG(ERR, "port index %d invalid\n", port_id);
+ break;
+ case -ENOTSUP:
+ RTE_ETHDEV_LOG(ERR, "operation not supported by
device\n");
+ break;
+ case -EIO:
+ RTE_ETHDEV_LOG(ERR, "device is removed\n");
+ break;
+ default:
+ RTE_ETHDEV_LOG(ERR, "Unable to get port %d EEPROM
module info\n", ret);
+ break;
+ }
+ return;
+ }
+
+ einfo.offset = 0;
+ einfo.length = minfo.eeprom_len;
+ einfo.data = calloc(1, minfo.eeprom_len);
+ if (einfo.data == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Allocation of port %u eeprom data
failed\n", port_id);
+ return;
+ }
+
+ ret = rte_eth_dev_get_module_eeprom(port_id, &einfo);
+ if (ret != 0) {
+ switch (ret) {
+ case -ENODEV:
+ RTE_ETHDEV_LOG(ERR, "port index %d invalid\n", port_id);
+ break;
+ case -ENOTSUP:
+ RTE_ETHDEV_LOG(ERR, "operation not supported by
device\n");
+ break;
+ case -EIO:
+ RTE_ETHDEV_LOG(ERR, "device is removed\n");
+ break;
+ default:
+ RTE_ETHDEV_LOG(ERR, "Unable to get port %d module
EEPROM\n", ret);
+ break;
+ }
+ free(einfo.data);
+ return;
+ }
+
+ switch (minfo.type) {
+ /* parsing module EEPROM data base on different module type */
+ default:
+ RTE_ETHDEV_LOG(NOTICE, "Unsupported module type: %u\n",
minfo.type);
+ break;
+ }
+
+ free(einfo.data);
+}
+
+void
+add_item_string(struct sff_item *items, const char *name_str, const char
*value_str)
+{
+ /* append different values for same keys */
+ if (sff_item_count > 0 &&
+ (strcmp(items[sff_item_count - 1].name, name_str) == 0)) {
+ strlcat(items[sff_item_count - 1].value, "; ",
SFF_ITEM_VALUE_SIZE);
+ strlcat(items[sff_item_count - 1].value, value_str,
SFF_ITEM_VALUE_SIZE);
+ return;
+ }
+
+ snprintf(items[sff_item_count].name, SFF_ITEM_NAME_SIZE, "%s",
name_str);
+ snprintf(items[sff_item_count].value, SFF_ITEM_VALUE_SIZE, "%s",
value_str);
+ sff_item_count++;
+}
+
+int
+eth_dev_handle_port_module_eeprom(const char *cmd __rte_unused, const char
*params,
+ struct rte_tel_data *d)
+{
+ char *end_param;
+ int port_id, i;
+ struct sff_item *items;
+ sff_item_count = 0;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ errno = 0;
+ port_id = strtoul(params, &end_param, 0);
+
+ if (errno != 0) {
+ RTE_ETHDEV_LOG(ERR, "Invalid argument\n");
+ return -1;
+ }
+
+ if (*end_param != '\0')
+ RTE_ETHDEV_LOG(NOTICE,
+ "Extra parameters passed to ethdev telemetry command,
ignoring");
+
+ items = calloc(1, sizeof(struct sff_item) * SFF_ITEM_MAX_COUNT);
+ if (items == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Error allocating memory of items\n");
+ return -1;
+
[PATCH v5 2/5] ethdev: common utilities for different SFF specs
This patch implements SFF-8024 Rev 4.0 of pluggable I/O configuration
and some common utilities for SFF-8436/8636 and SFF-8472/8079.
Signed-off-by: Robin Zhang
---
lib/ethdev/meson.build | 1 +
lib/ethdev/sff_common.c | 326
lib/ethdev/sff_common.h | 174 +
3 files changed, 501 insertions(+)
create mode 100644 lib/ethdev/sff_common.c
create mode 100644 lib/ethdev/sff_common.h
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index 49c77acb3f..8f39739e43 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -12,6 +12,7 @@ sources = files(
'rte_mtr.c',
'rte_tm.c',
'ethdev_sff_telemetry.c',
+'sff_common.c',
)
headers = files(
diff --git a/lib/ethdev/sff_common.c b/lib/ethdev/sff_common.c
new file mode 100644
index 00..c9a0227205
--- /dev/null
+++ b/lib/ethdev/sff_common.c
@@ -0,0 +1,326 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8024 Rev 4.0 of pluggable I/O configuration and some
+ * common utilities for SFF-8436/8636 and SFF-8472/8079
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "sff_common.h"
+#include "ethdev_sff_telemetry.h"
+
+
+double convert_mw_to_dbm(double mw)
+{
+ return (10. * log10(mw / 1000.)) + 30.;
+}
+
+void sff_show_value_with_unit(const uint8_t *data, unsigned int reg,
+ const char *name, unsigned int mult,
+ const char *unit, struct sff_item *items)
+{
+ unsigned int val = data[reg];
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ snprintf(val_string, sizeof(val_string), "%u%s", val * mult, unit);
+ add_item_string(items, name, val_string);
+}
+
+void sff_show_ascii(const uint8_t *data, unsigned int first_reg,
+ unsigned int last_reg, const char *name, struct sff_item
*items)
+{
+ unsigned int reg, val;
+ char tmp[3];
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ memset(val_string, 0, sizeof(val_string));
+
+ while (first_reg <= last_reg && data[last_reg] == ' ')
+ last_reg--;
+ for (reg = first_reg; reg <= last_reg; reg++) {
+ val = data[reg];
+ if ((val >= 32) && (val <= 126)) {
+ snprintf(tmp, sizeof(tmp), "%c", val);
+ strlcat(val_string, tmp, sizeof(val_string));
+ } else {
+ strlcat(val_string, "_", sizeof(val_string));
+ }
+ }
+ add_item_string(items, name, val_string);
+}
+
+void sff_8024_show_oui(const uint8_t *data, int id_offset, struct sff_item
*items)
+{
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ snprintf(val_string, sizeof(val_string), "%02x:%02x:%02x",
+ data[id_offset], data[(id_offset) + 1], data[(id_offset) + 2]);
+ add_item_string(items, "Vendor OUI", val_string);
+}
+
+void sff_8024_show_identifier(const uint8_t *data, int id_offset, struct
sff_item *items)
+{
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ snprintf(val_string, sizeof(val_string), "0x%02x", data[id_offset]);
+
+ switch (data[id_offset]) {
+ case SFF_8024_ID_UNKNOWN:
+ strlcat(val_string, " (no module present, unknown, or
unspecified)",
+ sizeof(val_string));
+ break;
+ case SFF_8024_ID_GBIC:
+ strlcat(val_string, " (GBIC)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_SOLDERED_MODULE:
+ strlcat(val_string, " (module soldered to motherboard)",
sizeof(val_string));
+ break;
+ case SFF_8024_ID_SFP:
+ strlcat(val_string, " (SFP)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_300_PIN_XBI:
+ strlcat(val_string, " (300 pin XBI)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_XENPAK:
+ strlcat(val_string, " (XENPAK)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_XFP:
+ strlcat(val_string, " (XFP)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_XFF:
+ strlcat(val_string, " (XFF)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_XFP_E:
+ strlcat(val_string, " (XFP-E)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_XPAK:
+ strlcat(val_string, " (XPAK)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_X2:
+ strlcat(val_string, " (X2)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_DWDM_SFP:
+ strlcat(val_string, " (DWDM-SFP)", sizeof(val_string));
+ break;
+ case SFF_8024_ID_QSFP:
+ strlcat(val_string, " (QSFP)", sizeof(val_string));
+ break;
+
[PATCH v5 3/5] ethdev: format module EEPROM for SFF-8079
This patch implements format module EEPROM information for
SFF-8079 Rev 1.7
Signed-off-by: Robin Zhang
---
lib/ethdev/ethdev_sff_telemetry.c | 3 +
lib/ethdev/meson.build| 1 +
lib/ethdev/sff_8079.c | 407 ++
3 files changed, 411 insertions(+)
create mode 100644 lib/ethdev/sff_8079.c
diff --git a/lib/ethdev/ethdev_sff_telemetry.c
b/lib/ethdev/ethdev_sff_telemetry.c
index 968b640b17..c09352959c 100644
--- a/lib/ethdev/ethdev_sff_telemetry.c
+++ b/lib/ethdev/ethdev_sff_telemetry.c
@@ -66,6 +66,9 @@ sff_port_module_eeprom_display(uint16_t port_id, struct
sff_item *items)
switch (minfo.type) {
/* parsing module EEPROM data base on different module type */
+ case RTE_ETH_MODULE_SFF_8079:
+ sff_8079_show_all(einfo.data, items);
+ break;
default:
RTE_ETHDEV_LOG(NOTICE, "Unsupported module type: %u\n",
minfo.type);
break;
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index 8f39739e43..d94860da0c 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -13,6 +13,7 @@ sources = files(
'rte_tm.c',
'ethdev_sff_telemetry.c',
'sff_common.c',
+'sff_8079.c',
)
headers = files(
diff --git a/lib/ethdev/sff_8079.c b/lib/ethdev/sff_8079.c
new file mode 100644
index 00..b6736da29e
--- /dev/null
+++ b/lib/ethdev/sff_8079.c
@@ -0,0 +1,407 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8079 optics diagnostics.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include "sff_common.h"
+#include "ethdev_sff_telemetry.h"
+
+static void sff_8079_show_identifier(const uint8_t *data, struct sff_item
*items)
+{
+ sff_8024_show_identifier(data, 0, items);
+}
+
+static void sff_8079_show_ext_identifier(const uint8_t *data, struct sff_item
*items)
+{
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ snprintf(val_string, sizeof(val_string), "0x%02x", data[1]);
+ if (data[1] == 0x00)
+ strlcat(val_string, " (GBIC not specified / not MOD_DEF
compliant)",
+ sizeof(val_string));
+ else if (data[1] == 0x04)
+ strlcat(val_string, " (GBIC/SFP defined by 2-wire interface
ID)",
+ sizeof(val_string));
+ else if (data[1] <= 0x07) {
+ char tmp[SFF_ITEM_VAL_COMPOSE_SIZE];
+ snprintf(tmp, sizeof(tmp), " (GBIC compliant with MOD_DEF %u)",
data[1]);
+ strlcat(val_string, tmp, sizeof(val_string));
+ } else
+ strlcat(val_string, " (unknown)", sizeof(val_string));
+ add_item_string(items, "Extended identifier", val_string);
+}
+
+static void sff_8079_show_connector(const uint8_t *data, struct sff_item
*items)
+{
+ sff_8024_show_connector(data, 2, items);
+}
+
+static void sff_8079_show_transceiver(const uint8_t *data, struct sff_item
*items)
+{
+ static const char *name = "Transceiver type";
+ char val_string[SFF_ITEM_VAL_COMPOSE_SIZE];
+
+ snprintf(val_string, sizeof(val_string),
+ "0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x
0x%02x",
+ data[3], data[4], data[5], data[6], data[7], data[8], data[9],
data[10], data[36]);
+ add_item_string(items, "Transceiver codes", val_string);
+
+ /* 10G Ethernet Compliance Codes */
+ if (data[3] & (1 << 7))
+ add_item_string(items, "10G Ethernet transceiver type",
+ "10G Ethernet: 10G Base-ER [SFF-8472 rev10.4 onwards]");
+ if (data[3] & (1 << 6))
+ add_item_string(items, name, "10G Ethernet: 10G Base-LRM");
+ if (data[3] & (1 << 5))
+ add_item_string(items, name, "10G Ethernet: 10G Base-LR");
+ if (data[3] & (1 << 4))
+ add_item_string(items, name, "10G Ethernet: 10G Base-SR");
+
+ /* Infiniband Compliance Codes */
+ if (data[3] & (1 << 3))
+ add_item_string(items, name, "Infiniband: 1X SX");
+ if (data[3] & (1 << 2))
+ add_item_string(items, name, "Infiniband: 1X LX");
+ if (data[3] & (1 << 1))
+ add_item_string(items, name, "Infiniband: 1X Copper Active");
+ if (data[3] & (1 << 0))
+ add_item_string(items, name, "Infiniband: 1X Copper Passive");
+
+ /* ESCON Compliance Codes */
+ if (data[4] & (1 << 7))
+ add_item_string(items, name, "ESCON: ESCON MMF, 1310nm LED");
+ if (data[4] & (1 << 6))
+ add_item_string(items, name, "ESCON: ESCON SMF, 1310nm Laser");
+
+ /* SONET Compliance Codes */
+ if (data[4] & (1 << 5))
+ add_item_string(items, name, "SONET: OC-192, short reach");
+ if (data[4] & (1 << 4))
+ add_item_string(items, name, "SONET: SONET reach specifier bit
1");
+ if (data[4] & (1 << 3))
+
[PATCH v5 4/5] ethdev: format module EEPROM for SFF-8472
This patch implements format module EEPROM information for
SFF-8472 Rev 12.0
Signed-off-by: Robin Zhang
---
lib/ethdev/ethdev_sff_telemetry.c | 4 +
lib/ethdev/meson.build| 1 +
lib/ethdev/sff_8472.c | 287 ++
3 files changed, 292 insertions(+)
create mode 100644 lib/ethdev/sff_8472.c
diff --git a/lib/ethdev/ethdev_sff_telemetry.c
b/lib/ethdev/ethdev_sff_telemetry.c
index c09352959c..2bfed792e0 100644
--- a/lib/ethdev/ethdev_sff_telemetry.c
+++ b/lib/ethdev/ethdev_sff_telemetry.c
@@ -69,6 +69,10 @@ sff_port_module_eeprom_display(uint16_t port_id, struct
sff_item *items)
case RTE_ETH_MODULE_SFF_8079:
sff_8079_show_all(einfo.data, items);
break;
+ case RTE_ETH_MODULE_SFF_8472:
+ sff_8079_show_all(einfo.data, items);
+ sff_8472_show_all(einfo.data, items);
+ break;
default:
RTE_ETHDEV_LOG(NOTICE, "Unsupported module type: %u\n",
minfo.type);
break;
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index d94860da0c..4d81a35c09 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -14,6 +14,7 @@ sources = files(
'ethdev_sff_telemetry.c',
'sff_common.c',
'sff_8079.c',
+'sff_8472.c',
)
headers = files(
diff --git a/lib/ethdev/sff_8472.c b/lib/ethdev/sff_8472.c
new file mode 100644
index 00..b4869d69c0
--- /dev/null
+++ b/lib/ethdev/sff_8472.c
@@ -0,0 +1,287 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8472 optics diagnostics.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "sff_common.h"
+#include "ethdev_sff_telemetry.h"
+
+/* Offsets in decimal, for direct comparison with the SFF specs */
+
+/* A0-based EEPROM offsets for DOM support checks */
+#define SFF_A0_DOM92
+#define SFF_A0_OPTIONS93
+#define SFF_A0_COMP 94
+
+/* EEPROM bit values for various registers */
+#define SFF_A0_DOM_EXTCAL (1 << 4)
+#define SFF_A0_DOM_INTCAL (1 << 5)
+#define SFF_A0_DOM_IMPL (1 << 6)
+#define SFF_A0_DOM_PWRT (1 << 3)
+
+#define SFF_A0_OPTIONS_AW (1 << 7)
+
+/*
+ * This is the offset at which the A2 page is in the EEPROM
+ * blob returned by the kernel.
+ */
+#define SFF_A2_BASE 0x100
+
+/* A2-based offsets for DOM */
+#define SFF_A2_TEMP 96
+#define SFF_A2_TEMP_HALRM 0
+#define SFF_A2_TEMP_LALRM 2
+#define SFF_A2_TEMP_HWARN 4
+#define SFF_A2_TEMP_LWARN 6
+
+#define SFF_A2_VCC98
+#define SFF_A2_VCC_HALRM 8
+#define SFF_A2_VCC_LALRM 10
+#define SFF_A2_VCC_HWARN 12
+#define SFF_A2_VCC_LWARN 14
+
+#define SFF_A2_BIAS 100
+#define SFF_A2_BIAS_HALRM 16
+#define SFF_A2_BIAS_LALRM 18
+#define SFF_A2_BIAS_HWARN 20
+#define SFF_A2_BIAS_LWARN 22
+
+#define SFF_A2_TX_PWR 102
+#define SFF_A2_TX_PWR_HALRM 24
+#define SFF_A2_TX_PWR_LALRM 26
+#define SFF_A2_TX_PWR_HWARN 28
+#define SFF_A2_TX_PWR_LWARN 30
+
+#define SFF_A2_RX_PWR 104
+#define SFF_A2_RX_PWR_HALRM 32
+#define SFF_A2_RX_PWR_LALRM 34
+#define SFF_A2_RX_PWR_HWARN 36
+#define SFF_A2_RX_PWR_LWARN 38
+
+#define SFF_A2_ALRM_FLG 112
+#define SFF_A2_WARN_FLG 116
+
+/* 32-bit little-endian calibration constants */
+#define SFF_A2_CAL_RXPWR4 56
+#define SFF_A2_CAL_RXPWR3 60
+#define SFF_A2_CAL_RXPWR2 64
+#define SFF_A2_CAL_RXPWR1 68
+#define SFF_A2_CAL_RXPWR0 72
+
+/* 16-bit little endian calibration constants */
+#define SFF_A2_CAL_TXI_SLP76
+#define SFF_A2_CAL_TXI_OFF78
+#define SFF_A2_CAL_TXPWR_SLP 80
+#define SFF_A2_CAL_TXPWR_OFF 82
+#define SFF_A2_CAL_T_SLP 84
+#define SFF_A2_CAL_T_OFF 86
+#define SFF_A2_CAL_V_SLP 88
+#define SFF_A2_CAL_V_OFF 90
+
+static struct sff_8472_aw_flags {
+ const char *str;/* Human-readable string, null at the end */
+ int offset; /* A2-relative address offset */
+ uint8_t value; /* Alarm is on if (offset & value) != 0. */
+} sff_8472_aw_flags[] = {
+ { "Laser bias current high alarm", SFF_A2_ALRM_FLG, (1 << 3) },
+ { "Laser bias current low alarm",SFF_A2_ALRM_FLG, (1 << 2) },
+ { "Laser bias current high warning", SF
[PATCH v5 5/5] ethdev: format module EEPROM for SFF-8636
This patch implements format module EEPROM information for
SFF-8636 Rev 2.7
Signed-off-by: Robin Zhang
---
lib/ethdev/ethdev_sff_telemetry.c | 4 +
lib/ethdev/meson.build| 1 +
lib/ethdev/sff_8636.c | 775 ++
lib/ethdev/sff_8636.h | 592 +++
4 files changed, 1372 insertions(+)
create mode 100644 lib/ethdev/sff_8636.c
create mode 100644 lib/ethdev/sff_8636.h
diff --git a/lib/ethdev/ethdev_sff_telemetry.c
b/lib/ethdev/ethdev_sff_telemetry.c
index 2bfed792e0..9ff0b2eb4a 100644
--- a/lib/ethdev/ethdev_sff_telemetry.c
+++ b/lib/ethdev/ethdev_sff_telemetry.c
@@ -73,6 +73,10 @@ sff_port_module_eeprom_display(uint16_t port_id, struct
sff_item *items)
sff_8079_show_all(einfo.data, items);
sff_8472_show_all(einfo.data, items);
break;
+ case RTE_ETH_MODULE_SFF_8436:
+ case RTE_ETH_MODULE_SFF_8636:
+ sff_8636_show_all(einfo.data, einfo.length, items);
+ break;
default:
RTE_ETHDEV_LOG(NOTICE, "Unsupported module type: %u\n",
minfo.type);
break;
diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build
index 4d81a35c09..88ceeb12b9 100644
--- a/lib/ethdev/meson.build
+++ b/lib/ethdev/meson.build
@@ -15,6 +15,7 @@ sources = files(
'sff_common.c',
'sff_8079.c',
'sff_8472.c',
+'sff_8636.c',
)
headers = files(
diff --git a/lib/ethdev/sff_8636.c b/lib/ethdev/sff_8636.c
new file mode 100644
index 00..290b31e973
--- /dev/null
+++ b/lib/ethdev/sff_8636.c
@@ -0,0 +1,775 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Intel Corporation
+ *
+ * Implements SFF-8636 based QSFP+/QSFP28 Diagnostics Memory map.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "sff_common.h"
+#include "sff_8636.h"
+#include "ethdev_sff_telemetry.h"
+
+#define MAX_DESC_SIZE 42
+
+static struct sff_8636_aw_flags {
+ const char *str;/* Human-readable string, null at the end */
+ int offset; /* A2-relative address offset */
+ uint8_t value; /* Alarm is on if (offset & value) != 0. */
+} sff_8636_aw_flags[] = {
+ { "Laser bias current high alarm (Chan 1)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_1_HALARM) },
+ { "Laser bias current low alarm(Chan 1)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_1_LALARM) },
+ { "Laser bias current high warning (Chan 1)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_1_HWARN) },
+ { "Laser bias current low warning (Chan 1)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_1_LWARN) },
+
+ { "Laser bias current high alarm (Chan 2)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_2_HALARM) },
+ { "Laser bias current low alarm(Chan 2)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_2_LALARM) },
+ { "Laser bias current high warning (Chan 2)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_2_HWARN) },
+ { "Laser bias current low warning (Chan 2)",
+ SFF_8636_TX_BIAS_12_AW_OFFSET, (SFF_8636_TX_BIAS_2_LWARN) },
+
+ { "Laser bias current high alarm (Chan 3)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_3_HALARM) },
+ { "Laser bias current low alarm(Chan 3)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_3_LALARM) },
+ { "Laser bias current high warning (Chan 3)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_3_HWARN) },
+ { "Laser bias current low warning (Chan 3)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_3_LWARN) },
+
+ { "Laser bias current high alarm (Chan 4)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_4_HALARM) },
+ { "Laser bias current low alarm(Chan 4)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_4_LALARM) },
+ { "Laser bias current high warning (Chan 4)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_4_HWARN) },
+ { "Laser bias current low warning (Chan 4)",
+ SFF_8636_TX_BIAS_34_AW_OFFSET, (SFF_8636_TX_BIAS_4_LWARN) },
+
+ { "Module temperature high alarm",
+ SFF_8636_TEMP_AW_OFFSET, (SFF_8636_TEMP_HALARM_STATUS) },
+ { "Module temperature low alarm",
+ SFF_8636_TEMP_AW_OFFSET, (SFF_8636_TEMP_LALARM_STATUS) },
+ { "Module temperature high warning",
+ SFF_8636_TEMP_AW_OFFSET, (SFF_8636_TEMP_HWARN_STATUS) },
+ { "Module temperature low warning",
+ SFF_8636_TEMP_AW_OFFSET, (SFF_8636_TEMP_LWARN_STATUS) },
+
+ { "Module voltage high alarm",
+ SFF_8636_VCC_AW_OFFSET, (SFF_8636_VCC_HALARM_STATUS) },
+ { "Module voltage low alarm",
+
[PATCH] eventdev/timer_adapter: add telemetry support
Adds telemetry support to get timer adapter info and timer adapter
statistics.
Signed-off-by: Ankur Dwivedi
Reviewed-by: Jerin Jacob Kollanukkaran
---
lib/eventdev/rte_event_timer_adapter.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/lib/eventdev/rte_event_timer_adapter.c
b/lib/eventdev/rte_event_timer_adapter.c
index 7dc39386c9..e0d978d641 100644
--- a/lib/eventdev/rte_event_timer_adapter.c
+++ b/lib/eventdev/rte_event_timer_adapter.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "event_timer_adapter_pmd.h"
#include "eventdev_pmd.h"
@@ -1249,3 +1250,93 @@ static const struct event_timer_adapter_ops swtim_ops = {
.arm_tmo_tick_burst = swtim_arm_tmo_tick_burst,
.cancel_burst = swtim_cancel_burst,
};
+
+static int
+handle_ta_info(const char *cmd __rte_unused, const char *params,
+ struct rte_tel_data *d)
+{
+ struct rte_event_timer_adapter_info adapter_info;
+ struct rte_event_timer_adapter *adapter;
+ uint16_t adapter_id;
+ int ret;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ adapter_id = atoi(params);
+
+ if (adapter_id >= RTE_EVENT_TIMER_ADAPTER_NUM_MAX) {
+ EVTIM_LOG_ERR("Invalid timer adapter id %u", adapter_id);
+ return -EINVAL;
+ }
+
+ adapter = &adapters[adapter_id];
+
+ ret = rte_event_timer_adapter_get_info(adapter, &adapter_info);
+ if (ret < 0) {
+ EVTIM_LOG_ERR("Failed to get info for timer adapter id %u",
adapter_id);
+ return ret;
+ }
+
+ rte_tel_data_start_dict(d);
+ rte_tel_data_add_dict_u64(d, "timer_adapter_id", adapter_id);
+ rte_tel_data_add_dict_u64(d, "min_resolution_ns",
adapter_info.min_resolution_ns);
+ rte_tel_data_add_dict_u64(d, "max_tmo_ns", adapter_info.max_tmo_ns);
+ rte_tel_data_add_dict_u64(d, "event_dev_id",
adapter_info.conf.event_dev_id);
+ rte_tel_data_add_dict_u64(d, "socket_id", adapter_info.conf.socket_id);
+ rte_tel_data_add_dict_u64(d, "clk_src", adapter_info.conf.clk_src);
+ rte_tel_data_add_dict_u64(d, "timer_tick_ns",
adapter_info.conf.timer_tick_ns);
+ rte_tel_data_add_dict_u64(d, "nb_timers", adapter_info.conf.nb_timers);
+ rte_tel_data_add_dict_u64(d, "flags", adapter_info.conf.flags);
+
+ return 0;
+}
+
+static int
+handle_ta_stats(const char *cmd __rte_unused, const char *params,
+ struct rte_tel_data *d)
+{
+ struct rte_event_timer_adapter_stats stats;
+ struct rte_event_timer_adapter *adapter;
+ uint16_t adapter_id;
+ int ret;
+
+ if (params == NULL || strlen(params) == 0 || !isdigit(*params))
+ return -1;
+
+ adapter_id = atoi(params);
+
+ if (adapter_id >= RTE_EVENT_TIMER_ADAPTER_NUM_MAX) {
+ EVTIM_LOG_ERR("Invalid timer adapter id %u", adapter_id);
+ return -EINVAL;
+ }
+
+ adapter = &adapters[adapter_id];
+
+ ret = rte_event_timer_adapter_stats_get(adapter, &stats);
+ if (ret < 0) {
+ EVTIM_LOG_ERR("Failed to get stats for timer adapter id %u",
adapter_id);
+ return ret;
+ }
+
+ rte_tel_data_start_dict(d);
+ rte_tel_data_add_dict_u64(d, "timer_adapter_id", adapter_id);
+ rte_tel_data_add_dict_u64(d, "evtim_exp_count", stats.evtim_exp_count);
+ rte_tel_data_add_dict_u64(d, "ev_enq_count", stats.ev_enq_count);
+ rte_tel_data_add_dict_u64(d, "ev_inv_count", stats.ev_inv_count);
+ rte_tel_data_add_dict_u64(d, "evtim_retry_count",
stats.evtim_retry_count);
+ rte_tel_data_add_dict_u64(d, "adapter_tick_count",
stats.adapter_tick_count);
+
+ return 0;
+}
+
+RTE_INIT(ta_init_telemetry)
+{
+ rte_telemetry_register_cmd("/eventdev/ta_info",
+ handle_ta_info,
+ "Returns Timer adapter info. Parameter: Timer adapter id");
+
+ rte_telemetry_register_cmd("/eventdev/ta_stats",
+ handle_ta_stats,
+ "Returns Timer adapter stats. Parameter: Timer adapter id");
+}
--
2.28.0
RE: [PATCH v6 08/16] usertools: add support for virtio blk device
Hi Chenbo,
Thanks for your reply.
I will send out a new version, and put blk device into misc devices.
> -Original Message-
> From: Xia, Chenbo
> Sent: Monday, April 25, 2022 9:53 PM
> To: Pei, Andy ; dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Cao, Gang ; Liu,
> Changpeng ; david.march...@redhat.com
> Subject: RE: [PATCH v6 08/16] usertools: add support for virtio blk device
>
> > -Original Message-
> > From: Pei, Andy
> > Sent: Thursday, April 21, 2022 4:34 PM
> > To: dev@dpdk.org
> > Cc: Xia, Chenbo ; maxime.coque...@redhat.com;
> > Cao, Gang ; Liu, Changpeng
> >
> > Subject: [PATCH v6 08/16] usertools: add support for virtio blk device
> >
> > Add virtio blk device support to devbind.
> >
> > Signed-off-by: Andy Pei
> > ---
> > usertools/dpdk-devbind.py | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
> > index ace4627..cbe336f 100755
> > --- a/usertools/dpdk-devbind.py
> > +++ b/usertools/dpdk-devbind.py
> > @@ -14,6 +14,8 @@
> > from os.path import join as path_join
>
> Supporting it in this script or not, it should not be named as 'XXX_class'.
> And even may not be defined as new class. Maybe go to misc devices for
> now?
> I'd like to hear others' opinion.
>
> And Stephen commented about using driverctl, please reply to that.
>
> Thanks,
> Chenbo
>
> >
> > # The PCI base class for all devices
> > +virtio_blk_class = {'Class': '01', 'Vendor': "1af4", 'Device': '1001',
> > +'SVendor': '8086', 'SDevice': '0002'}
> > network_class = {'Class': '02', 'Vendor': None, 'Device': None,
> > 'SVendor': None, 'SDevice': None}
> > acceleration_class = {'Class': '12', 'Vendor': None, 'Device': None,
> > @@ -72,6 +74,7 @@ cn9k_ree = {'Class': '08', 'Vendor': '177d',
> > 'Device': 'a0f4',
> > 'SVendor': None, 'SDevice': None}
> >
> > +virtio_blk_devices = [virtio_blk_class]
> > network_devices = [network_class, cavium_pkx, avp_vnic, ifpga_class]
> > baseband_devices = [acceleration_class] crypto_devices =
> > [encryption_class, intel_processor_class] @@ -587,6 +590,9 @@ def
> > show_status():
> > Displays to the user what devices are bound to the igb_uio
> > driver, the
> > kernel driver or to no driver'''
> >
> > +if status_dev in ["virtio_blk", "all"]:
> > +show_device_status(virtio_blk_devices, "virtio_blk")
> > +
> > if status_dev in ["net", "all"]:
> > show_device_status(network_devices, "Network", if_field=True)
> >
> > @@ -746,6 +752,7 @@ def do_arg_actions():
> > if b_flag is not None:
> > clear_data()
> > # refresh if we have changed anything
> > +get_device_details(virtio_blk_devices)
> > get_device_details(network_devices)
> > get_device_details(baseband_devices)
> > get_device_details(crypto_devices)
> > @@ -769,6 +776,7 @@ def main():
> > parse_args()
> > check_modules()
> > clear_data()
> > +get_device_details(virtio_blk_devices)
> > get_device_details(network_devices)
> > get_device_details(baseband_devices)
> > get_device_details(crypto_devices)
> > --
> > 1.8.3.1
>
[PATCH] doc: update matching versions in ice guide
Add recommended matching list for ice PMD in DPDK 22.03. Cc: sta...@dpdk.org Signed-off-by: Qiming Yang --- doc/guides/nics/ice.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index a1780c46c3..6b903b9bbc 100644 --- a/doc/guides/nics/ice.rst +++ b/doc/guides/nics/ice.rst @@ -62,6 +62,8 @@ The detailed information can refer to chapter Tested Platforms/Tested NICs in re +---+---+-+---+--+---+ |21.11 | 1.7.16| 1.3.27 | 1.3.31 |1.3.7 | 3.1| +---+---+-+---+--+---+ + |22.03 | 1.8.3 | 1.3.28 | 1.3.35 |1.3.8 | 3.2| + +---+---+-+---+--+---+ Pre-Installation Configuration -- -- 2.17.1
[PATCH] doc: update matching versions in i40e guide
Add recommended matching list for i40e PMD in DPDK 21.05, 21.08, 21.11 and 22.03. Cc: sta...@dpdk.org Signed-off-by: Qiming Yang --- doc/guides/nics/i40e.rst | 16 1 file changed, 16 insertions(+) diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index ef91b3a1ac..0c5019e97e 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -101,6 +101,14 @@ For X710/XL710/XXV710, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |22.03 | 2.17.15 | 8.30 | + +--+---+--+ + |21.11 | 2.17.4| 8.30 | + +--+---+--+ + |21.08 | 2.15.9| 8.30 | + +--+---+--+ + |21.05 | 2.15.9| 8.30 | + +--+---+--+ |21.02 | 2.14.13 | 8.00 | +--+---+--+ |20.11 | 2.14.13 | 8.00 | @@ -148,6 +156,14 @@ For X722, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |22.03 | 2.17.15 | 5.50 | + +--+---+--+ + |21.11 | 2.17.4| 5.30 | + +--+---+--+ + |21.08 | 2.15.9| 5.15 | + +--+---+--+ + |21.05 | 2.15.9| 5.15 | + +--+---+--+ |21.02 | 2.14.13 | 5.00 | +--+---+--+ |20.11 | 2.13.10 | 5.00 | -- 2.17.1
Re: [PATCH v2] test/bpf: skip test if libpcap is unavailable
On Tue, Mar 22, 2022 at 11:50:33AM +, Ananyev, Konstantin wrote: > Acked-by: Konstantin Ananyev > Acked-by: Stephen Hemminger is there something more being requested here? the patch has been acked with no further comments for more than a month. this patch is blocking enablement of the UT for on windows CI runs. thanks.
