[PATCH v2] examples/vhost: fix launch failure with physical port
dpdk-vhost will fail to launch with a 40G i40e port because
there are not enough mbufs. This patch adds a new option
--total-num-mbufs, through which the user can set larger
mbuf pool to avoid this problem.
Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
examples/vhost/main.c | 83 +++
1 file changed, 29 insertions(+), 54 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 68afd398bb..d94fabb060 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -33,6 +33,8 @@
#define MAX_QUEUES 128
#endif
+#define NUM_MBUFS_DEFAULT 0x24000
+
/* the maximum number of external ports supported */
#define MAX_SUP_PORTS 1
@@ -61,6 +63,9 @@
#define DMA_RING_SIZE 4096
+/* number of mbufs in all pools - if specified on command-line. */
+static int total_num_mbufs = NUM_MBUFS_DEFAULT;
+
struct dma_for_vhost dma_bind[RTE_MAX_VHOST_DEVICE];
int16_t dmas_id[RTE_DMADEV_DEFAULT_MAX];
static int dma_count;
@@ -608,7 +613,8 @@ us_vhost_usage(const char *prgname)
" --tx-csum [0|1] disable/enable TX checksum offload.\n"
" --tso [0|1] disable/enable TCP segment offload.\n"
" --client register a vhost-user socket as client mode.\n"
- " --dmas register dma channel for specific vhost
device.\n",
+ " --dmas register dma channel for specific vhost
device.\n"
+ " --total-num-mbufs [0-N] set the number of mbufs to be
allocated in mbuf pools, the default value is 147456.\n",
prgname);
}
@@ -637,6 +643,8 @@ enum {
OPT_BUILTIN_NET_DRIVER_NUM,
#define OPT_DMAS"dmas"
OPT_DMAS_NUM,
+#define OPT_NUM_MBUFS "total-num-mbufs"
+ OPT_NUM_MBUFS_NUM,
};
/*
@@ -674,6 +682,8 @@ us_vhost_parse_args(int argc, char **argv)
NULL, OPT_BUILTIN_NET_DRIVER_NUM},
{OPT_DMAS, required_argument,
NULL, OPT_DMAS_NUM},
+ {OPT_NUM_MBUFS, required_argument,
+ NULL, OPT_NUM_MBUFS_NUM},
{NULL, 0, 0, 0},
};
@@ -801,6 +811,19 @@ us_vhost_parse_args(int argc, char **argv)
}
break;
+ case OPT_NUM_MBUFS_NUM:
+ ret = parse_num_opt(optarg, INT32_MAX);
+ if (ret == -1) {
+ RTE_LOG(INFO, VHOST_CONFIG,
+ "Invalid argument for total-num-mbufs
[0..N]\n");
+ us_vhost_usage(prgname);
+ return -1;
+ }
+
+ if (total_num_mbufs < ret)
+ total_num_mbufs = ret;
+ break;
+
case OPT_CLIENT_NUM:
client_mode = 1;
break;
@@ -1730,57 +1753,6 @@ sigint_handler(__rte_unused int signum)
exit(0);
}
-/*
- * While creating an mbuf pool, one key thing is to figure out how
- * many mbuf entries is enough for our use. FYI, here are some
- * guidelines:
- *
- * - Each rx queue would reserve @nr_rx_desc mbufs at queue setup stage
- *
- * - For each switch core (A CPU core does the packet switch), we need
- * also make some reservation for receiving the packets from virtio
- * Tx queue. How many is enough depends on the usage. It's normally
- * a simple calculation like following:
- *
- * MAX_PKT_BURST * max packet size / mbuf size
- *
- * So, we definitely need allocate more mbufs when TSO is enabled.
- *
- * - Similarly, for each switching core, we should serve @nr_rx_desc
- * mbufs for receiving the packets from physical NIC device.
- *
- * - We also need make sure, for each switch core, we have allocated
- * enough mbufs to fill up the mbuf cache.
- */
-static void
-create_mbuf_pool(uint16_t nr_port, uint32_t nr_switch_core, uint32_t mbuf_size,
- uint32_t nr_queues, uint32_t nr_rx_desc, uint32_t nr_mbuf_cache)
-{
- uint32_t nr_mbufs;
- uint32_t nr_mbufs_per_core;
- uint32_t mtu = 1500;
-
- if (mergeable)
- mtu = 9000;
- if (enable_tso)
- mtu = 64 * 1024;
-
- nr_mbufs_per_core = (mtu + mbuf_size) * MAX_PKT_BURST /
- (mbuf_size - RTE_PKTMBUF_HEADROOM);
- nr_mbufs_per_core += nr_rx_desc;
- nr_mbufs_per_core = RTE_MAX(nr_mbufs_per_core, nr_mbuf_cache);
-
- nr_mbufs = nr_queues * nr_rx_desc;
- nr_mbufs += nr_mbufs_per_core * nr_switch_core;
- nr_mbufs *= nr_port;
-
- mbuf_pool = rte_pktmbuf_pool_create("MBUF_POOL", nr_mbufs,
- nr_mbuf_cache, 0, mbuf_size,
- rte_socket_id());
Re: [PATCH v1] maintainers: add explicit maintainer for some bbdev PMDs
On Thu, Mar 03, 2022 at 10:51:38AM -0800, Nicolas Chautru wrote: > These were implicit from DPDK script but adding > separate reference to make it explicit > > Signed-off-by: Nicolas Chautru > --- > MAINTAINERS | 4 > 1 file changed, 4 insertions(+) > Thanks for this. It just means that someone looking for the driver name in the MAINTAINERS file will get a hit, rather than having to know that it's implicit in the top-level baseband directory. Acked-by: Bruce Richardson
RE: [PATCH v5] app/testpmd: add help messages for multi-process
Hi Minhu,
> -Original Message-
> From: Min Hu (Connor)
> Sent: Friday, March 4, 2022 2:27 PM
> To: dev@dpdk.org
> Cc: Huisong Li ; sta...@dpdk.org; Min Hu
> ; Li, Xiaoyun ; Singh, Aman
> Deep ; Zhang, Yuying
> ; Ajit Khaparde ;
> Andrew Rybchenko ; Yigit, Ferruh
>
> Subject: [PATCH v5] app/testpmd: add help messages for multi-process
>
> From: Huisong Li
>
> This patch adds help messages for multi-process.
> --num-procs , where N is the total number of symmetric_mp instances
> that will be run side-by-side to perform packet processing. This parameter is
> used to configure the appropriate number of receive queues on each
> network port.
>
> --proc-id , where n is a numeric value in the range 0 <= n < N (number of
> processes, specified above). This identifies which symmetric_mp instance is
> being run, so that each process can read a unique receive queue on each
> network port.
>
> Fixes: a550baf24af9 ("app/testpmd: support multi-process")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Huisong Li
> Signed-off-by: Min Hu (Connor)
Acked-by: Yuying Zhang
> ---
> v5:
> * delete space
> v4:
> * update description for parameters.
> v3,v2:
> * adjust the position of parameters.
> ---
> app/test-pmd/parameters.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> daf6a31b2b..6c4253ae61 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -61,6 +61,8 @@ usage(char* progname)
> "extended statistics to show. Used with --stats-period "
> "specified or interactive commands that show Rx/Tx statistics "
> "(i.e. 'show port stats').\n");
> + printf(" --num-procs: the total number of symmetric_mp instances
> that will be run side-by-side\n");
> + printf(" --proc-id: the id of the current process (id < num-procs) to
> +identify which symmetric_mp instance is being run\n");
> printf(" --nb-cores=N: set the number of forwarding cores "
> "(1 <= N <= %d).\n", nb_lcores);
> printf(" --nb-ports=N: set the number of forwarding ports "
> --
> 2.33.0
RE: [EXT] [PATCH] app/compress-perf: fix cyclecount enqueue ops allocation
> In cyclecount main_loop function, each iteration it tries to enqueue X ops,
> in case Y beginning of the ops array, to preserve ops order, and next Y ops are
> allocated for the next enqueue action, the allocation of the ops occures on
> the first Y entries in the array, when it should have skipped the first X-Y
> array entries and allocate the following Y entries.
>
> Fix the allocation by adding the correct offset.
>
> Fixes: 2695db95a147 ("test/compress: add cycle-count mode to perf tool")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> ---
> Acked-by: Matan Azrad ma...@nvidia.com
Please use proper syntax for acks.
Applied to dpdk-next-crypto
RE: [EXT] [PATCH] app/compress-perf: optimize ops pool allocation
> An array of the size of total operations needed for the de/compression is
> reserved for ops while enqueueing, although only first burst_size entries
> of the array are used.
>
> Reduce the size of the array allocated.
>
> Fixes: b68a82425da4 ("app/compress-perf: add performance measurement")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> ---
> Acked-by: Matan Azrad ma...@nvidia.com
Please use proper syntax for acks
Applied to dpdk-next-crypto
RE: [EXT] [PATCH V2] compress/mlx5: support out-of-space status
> When trying to dequeue, an OP may fail due to insufficient space for the
> OP output, the compressdev API defines out-of-space for OP status.
> The driver can detect out-of-space errors and report them to the user.
>
> Check if hw_error_syndrome specifies out-of-space and set the OP
> status accordingly.
> Also added an error message for a case of missing B-final flag.
>
> Fixes: f8c97babc9f4 ("compress/mlx5: add data-path functions")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> ---
> Acked-by: Matan Azrad
Applied to dpdk-next-crypto
RE: [EXT] [PATCH] app/compress-perf: fix socket ID type during init
> Socket ID is obtained by function rte_compressdev_socket_id, which
> returns it as integer, but is interpreted as unsigned byte integer.
>
> change type from uint8_t to int.
>
> Fixes: ed7dd94f7f66 ("compressdev: add basic device management")
> Cc: fiona.tr...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> Acked-by: Matan Azrad
Applied to dpdk-next-crypto
RE: [PATCH v2] examples/vhost: fix launch failure with physical port
> -Original Message-
> From: Ma, WenwuX
> Sent: Saturday, March 5, 2022 12:24 AM
> To: maxime.coque...@redhat.com; Xia, Chenbo ;
> dev@dpdk.org
> Cc: Hu, Jiayu ; Wang, Yinan ; He,
> Xingguang ; Ma, WenwuX ;
> sta...@dpdk.org
> Subject: [PATCH v2] examples/vhost: fix launch failure with physical port
>
> dpdk-vhost will fail to launch with a 40G i40e port because
> there are not enough mbufs. This patch adds a new option
> --total-num-mbufs, through which the user can set larger
> mbuf pool to avoid this problem.
>
> Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wenwu Ma
> ---
> examples/vhost/main.c | 83 +++
> 1 file changed, 29 insertions(+), 54 deletions(-)
Reviewed-by: Chenbo Xia
RE: [EXT] [PATCH] app/compress-perf: fix number of QPs to setup
> The number of QPs is limited by the number of cores, such that in
> case the user requests more QPs than possible, the number of QPs
> actually configured on the device is equal to the number of cores,
> but the app tries to setup the original number of QPs.
>
> Align the number of QPs setup'ed to the limited number.
>
> Fixes: 424dd6c8c1a8 ("app/compress-perf: add weak functions for multicore
> test")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> Acked-by: Matan Azrad
Applied to dpdk-next-crypto
[PATCH] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem: All mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated and are still sitting in the device's tx descriptor ring and other cores' mempool caches. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- drivers/net/bonding/rte_eth_bond_8023ad.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..f896195447 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,6 +1101,9 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } + cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? + 32 : RTE_MEMPOOL_CACHE_MAX_SIZ; + total_tx_desc = rte_lcore_count() * cache_size * 1.5; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? -- 2.32.0
RE: [RFC] ethdev: introduce protocol type based header split
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, March 4, 2022 12:16 AM
> To: Ding, Xuan
> Cc: tho...@monjalon.net; Yigit, Ferruh ;
> andrew.rybche...@oktetlabs.ru; dev@dpdk.org; viachesl...@nvidia.com;
> Zhang, Qi Z ; Yu, Ping ; Wang,
> YuanX
> Subject: Re: [RFC] ethdev: introduce protocol type based header split
>
> On Thu, 3 Mar 2022 06:01:36 +
> xuan.d...@intel.com wrote:
>
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > c2d1f9a972..6743648c22 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split {
> > struct rte_mempool *mp; /**< Memory pool to allocate segment from.
> */
> > uint16_t length; /**< Segment data length, configures split point. */
> > uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> > - uint32_t reserved; /**< Reserved field. */
> > + uint16_t proto;
> > + uint16_t reserved; /**< Reserved field. */
> > };
>
> This feature suffers from a common bad design pattern.
> You can't just start using reserved fields unless the previous versions
> enforced
> that the field was a particular value (usually zero).
Yes, agree, that's a mistake there is no document for the reserved field in the
previous release, and usually, it should be zero,
And I think one of the typical purposes of the reserved field is to make life
easy for new feature adding without breaking ABI.
So, should we just take the risk as I guess it might not be a big deal in real
cases?
Thanks
Qi
>
> There is no guarantee that application will initialize these reserved fields
> and
> now using them risks breaking the API/ABI. It looks like
>
> rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,
>
> Would have had to check in previous release.
>
> This probably has to wait until 22.11 next API release.
RE: [EXT] [PATCH] compressdev: fix size of socket ID in device data struct
> Socket ID is used and interpreted as integer, one of the possible
> values for socket id is -1 (SOCKET_ID_ANY).
> here socket_id is defined as unsigned 8 bit integer, so when putting
> -1, it is interpreted as 255, which causes allocation errors when
> trying to allocate from socket_id (255).
>
> change socket_id from unsigned 8 bit integer to integer.
>
> Fixes: ed7dd94f7f66 ("compressdev: add basic device management")
> Cc: fiona.tr...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Raja Zidane
> Acked-by: Matan Azrad
Applied to dpdk-next-crypto
Thanks.
RE: [EXT] [PATCH] crypto/qat: fix structurally dead code
> This patch fixes structurally dead code in QAT
> asym pmd.
>
> Coverity issue: 376563
> Fixes: ef2f4238a04d ("crypto/qat: refactor asymmetric session")
>
> Signed-off-by: Arek Kusztal
Applied to dpdk-next-crypto
RE: [PATCH v2] app/testpmd : fix testpmd quit error
Hi Wenxuan,
> -Original Message-
> From: Wu, WenxuanX
> Sent: Friday, March 4, 2022 10:37 AM
> To: Yang, Qiming ; Zhang, Qi Z
> ; Li, Xiaoyun ; Singh, Aman
> Deep ; Zhang, Yuying
>
> Cc: dev@dpdk.org
> Subject: [PATCH v2] app/testpmd : fix testpmd quit error
>
> From: wenxuan wu
>
> When testpmd use func get_eth_dev_info() while related resource had been
> released.
>
> Change the logic of func port_is_bonding_slave, this func
> eth_dev_info_get_print_err while pf is released would result in this error.
> Use ports instead to avoid this bug.
>
> Fixes: 0a0821bcf312 ("app/testpmd: remove most uses of internal ethdev
> array")
> Cc: sta...@dpdk.org
>
> Signed-off-by: wenxuan wu
> ---
> app/test-pmd/testpmd.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> e1da961311..37038c9183 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -3824,19 +3824,9 @@ void clear_port_slave_flag(portid_t slave_pid)
> uint8_t port_is_bonding_slave(portid_t slave_pid) {
> struct rte_port *port;
> - struct rte_eth_dev_info dev_info;
> - int ret;
>
> port = &ports[slave_pid];
> - ret = eth_dev_info_get_print_err(slave_pid, &dev_info);
> - if (ret != 0) {
> - TESTPMD_LOG(ERR,
> - "Failed to get device info for port id %d,"
> - "cannot determine if the port is a bonded slave",
> - slave_pid);
> - return 0;
> - }
> - if ((*dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) || (port-
> >slave_flag == 1))
> + if ((*port->dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) ||
> +(port->slave_flag == 1))
Is port->dev_info.dev_flags updated in time when the bonding status changes?
It may use eth_dev_info_get_print_err() to update dev_info of port.
> return 1;
> return 0;
> }
> --
> 2.25.1
RE: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, March 3, 2022 10:52 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
> Dabilpuram ; yux.ji...@intel.com;
> sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
>
> Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
>
> External Email
>
> --
> On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
> > Use dynamically allocated memory for storing soft expiry ring base
> > addresses which fixes the static assertion failure, as the size of
> > dynamic allocation depends on RTE_MAX_ETHPORTS which varies based on
> > the build config.
> >
>
> Hi Vamsi,
>
> "fix static assertion failure" is not enough descriptive.
> assertions already added to verify assumptions, and in this case it seems it
> failed, but what was actually wrong?
>
> Is it that allocated memory size for ring wrong? (this is what I got from
> commit log but I am not sure)
>
> Can you please describe what actually was wrong and fixed now?
>
Hi Ferruh,
Earlier sa_soft_exp_ring struct member was an array of pointers and it's size
is linked to num RTE_MAX_ETHPORTS,
and the whole struct size is confined and protected by size assertion. It
resulted in build failure with -Dmax_ethports=1024
option and assertion caught that failure. V2 fixes the issues by allocating the
required memory dynamically instead
of using array of pointers.
> > Bugzilla ID: 940
> > Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
> > notification") Cc:sta...@dpdk.org
> >
> > Reported-by: Wei Ling
> > Reported-by: Yu Jiang
> > Signed-off-by: Vamsi Attunuru
> > Signed-off-by: Srikanth Yalavarthi
> > ---
> > V2: Add bugzilla & reportee details, remove unused changes.
> > ---
RE: [PATCH] crypto/qat: fix smaller modulus cases for mod exp
> > Subject: [PATCH] crypto/qat: fix smaller modulus cases for mod exp
> >
> > This patches fixes not working cases when modulus is
> > smaller than other arguments.
> >
> > Fixes: 109755f0a427 ("crypto/qat: refactor asymmetric crypto functions")
> >
> > Signed-off-by: Arek Kusztal
> > ---
> Acked-by: Fan Zhang
Applied to dpdk-next-crypto
Thanks.
RE: [EXT] [dpdk-dev v2] crypto/qat: fix process type handling
> This patch fix the memory corruptions issue reported by
> coverity. The process type handling in QAT PMDs where only
> primary and secondary process are supported in qat build
> request.
>
> Coverity issue: 376551, 376570, 376534
> Fixes: b62d00d0d247 ("crypto/qat: rework burst data path")
>
> Signed-off-by: Kai Ji
Applied to dpdk-next-crypto
[PATCH] app/crypto-perf: add IPsec ops population routine
Ops population functions are called in datapath. Keeping it common for
PDCP & DOCSIS would mean ops population would have additional
conditional checks causing the throughput reported to be lower than what
the PMD is capable of.
Separate out routine for IPsec cases and split vector population and op
preparation into two loops to allow 2 rte_rdtsc_precise() calls to
capture cycles consumed for memcpying the vector. Checking the cycle
count from the loop would mean more calls to the same API.
Signed-off-by: Anoob Joseph
---
app/test-crypto-perf/cperf_ops.c | 90 +++
app/test-crypto-perf/cperf_test_latency.c | 2 +-
2 files changed, 70 insertions(+), 22 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 479c40e..8baee12 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -45,7 +45,8 @@ test_ipsec_vec_populate(struct rte_mbuf *m, const struct
cperf_options *options,
if ((options->aead_op == RTE_CRYPTO_AEAD_OP_ENCRYPT) ||
(options->cipher_op == RTE_CRYPTO_CIPHER_OP_ENCRYPT)) {
- memcpy(ip, test_vector->plaintext.data, m->data_len);
+ memcpy(ip, test_vector->plaintext.data,
+ sizeof(struct rte_ipv4_hdr));
ip->total_length = rte_cpu_to_be_16(m->data_len);
}
@@ -61,7 +62,6 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
uint16_t iv_offset __rte_unused, uint32_t *imix_idx,
uint64_t *tsc_start)
{
- uint64_t tsc_start_temp, tsc_end_temp;
uint16_t i;
for (i = 0; i < nb_ops; i++) {
@@ -79,27 +79,10 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
sym_op->m_src = (struct rte_mbuf *)((uint8_t *)ops[i] +
src_buf_offset);
- if (options->op_type == CPERF_PDCP ||
- options->op_type == CPERF_IPSEC) {
- /* In case of IPsec, headroom is consumed by PMD,
-* hence resetting it.
-*/
- sym_op->m_src->data_off = options->headroom_sz;
-
+ if (options->op_type == CPERF_PDCP) {
sym_op->m_src->buf_len = options->segment_sz;
sym_op->m_src->data_len = options->test_buffer_size;
sym_op->m_src->pkt_len = sym_op->m_src->data_len;
-
- if ((options->op_type == CPERF_IPSEC) &&
- (options->test_file == NULL) &&
- (options->test == CPERF_TEST_TYPE_THROUGHPUT)) {
- tsc_start_temp = rte_rdtsc_precise();
- test_ipsec_vec_populate(sym_op->m_src, options,
- test_vector);
- tsc_end_temp = rte_rdtsc_precise();
-
- *tsc_start += (tsc_end_temp - tsc_start_temp);
- }
}
if (options->op_type == CPERF_DOCSIS) {
@@ -135,8 +118,71 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
dst_buf_offset);
}
+ RTE_SET_USED(tsc_start);
+ RTE_SET_USED(test_vector);
+
+ return 0;
+}
+
+static int
+cperf_set_ops_security_ipsec(struct rte_crypto_op **ops,
+ uint32_t src_buf_offset __rte_unused,
+ uint32_t dst_buf_offset __rte_unused,
+ uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ const struct cperf_options *options,
+ const struct cperf_test_vector *test_vector,
+ uint16_t iv_offset __rte_unused, uint32_t *imix_idx,
+ uint64_t *tsc_start)
+{
+ struct rte_security_session *sec_sess =
+ (struct rte_security_session *)sess;
+ const uint32_t test_buffer_size = options->test_buffer_size;
+ const uint32_t headroom_sz = options->headroom_sz;
+ const uint32_t segment_sz = options->segment_sz;
+ uint64_t tsc_start_temp, tsc_end_temp;
+ uint16_t i = 0;
+
+ RTE_SET_USED(imix_idx);
+
+ for (i = 0; i < nb_ops; i++) {
+ struct rte_crypto_sym_op *sym_op = ops[i]->sym;
+ struct rte_mbuf *m = sym_op->m_src;
+
+ ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
+ rte_security_attach_session(ops[i], sec_sess);
+ sym_op->m_src = (struct rte_mbuf *)((uint8_t *)ops[i] +
+ src_buf_offset);
+
+ /* In case of IPsec, headroom is consumed by PMD,
+* hence resetting it.
+*/
+ m->data_off = headroom_sz;
+
+ m->buf_len = segment_sz;
+ m->data_len =
RE: [PATCH] app/crypto-perf: add IPsec ops population routine
> Subject: [PATCH] app/crypto-perf: add IPsec ops population routine > > Ops population functions are called in datapath. Keeping it common for > PDCP & DOCSIS would mean ops population would have additional > conditional checks causing the throughput reported to be lower than what > the PMD is capable of. > > Separate out routine for IPsec cases and split vector population and op > preparation into two loops to allow 2 rte_rdtsc_precise() calls to > capture cycles consumed for memcpying the vector. Checking the cycle > count from the loop would mean more calls to the same API. > > Signed-off-by: Anoob Joseph Acked-by: Akhil Goyal Seems to be a pretty straight forward change. Applied to dpdk-next-crypto Thanks.
Re: [PATCH v1] net/i40e: remove redundant number of packets check
On 3/4/2022 1:23 AM, Zhang, Qi Z wrote: -Original Message- From: Yigit, Ferruh Sent: Friday, March 4, 2022 12:44 AM To: Zhang, Qi Z ; Feifei Wang ; Xing, Beilei ; David Christensen ; Richardson, Bruce ; Ananyev, Konstantin ; Ruifeng Wang Cc: dev@dpdk.org; n...@arm.com; Honnappa Nagarahalli ; Thomas Monjalon ; David Marchand Subject: Re: [PATCH v1] net/i40e: remove redundant number of packets check On 3/3/2022 2:28 AM, Zhang, Qi Z wrote: -Original Message- From: Feifei Wang Sent: Thursday, March 3, 2022 9:54 AM To: Xing, Beilei ; David Christensen ; Richardson, Bruce ; Ananyev, Konstantin ; Ruifeng Wang Cc: dev@dpdk.org; n...@arm.com; Feifei Wang ; Honnappa Nagarahalli Subject: [PATCH v1] net/i40e: remove redundant number of packets check For i40e_xmit_pkts_vec_xx function, it checks nb_pkts to ensure nb_pkts does not cross rs_thresh. However, in i40e_xmit_fixed_burst_vec_xx function, this check will be performed again. To improve code, delete this redundant check. Suggested-by: Honnappa Nagarahalli Signed-off-by: Feifei Wang Reviewed-by: Ruifeng Wang Applied to dpdk-next-net-intel. Hi Qi, This patch is not acked by the i40e maintainers. And this is changing the datapath for the -rc3, two weeks before the release. Is it tested enough? What is the gain with this patch, I don't see any numbers in the commit log. If the gain is small, can we postpone this patch to next release instead of getting it for -rc3? The patch applied the same thing as below which I have reviewed. https://patchwork.dpdk.org/project/dpdk/patch/2022024818.8612-1-kathleen.cape...@arm.com/ I didn't see the risk of having it, and I will add a "reviewed-by" to avoid confusion, but if you think it's risky, we can still defer it to next-net. Code change looks simple, but risk is more theoretical to get a datapath code optimization close to the release, and Feifei reported that there is no visible performance gain. So I think safer to postpone to next release if you don't object.
Re: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
On 3/4/2022 10:20 AM, Vamsi Krishna Attunuru wrote:
-Original Message-
From: Ferruh Yigit
Sent: Thursday, March 3, 2022 10:52 PM
To: Vamsi Krishna Attunuru ; dev@dpdk.org
Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
Dabilpuram ; yux.ji...@intel.com;
sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
External Email
--
On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
Use dynamically allocated memory for storing soft expiry ring base
addresses which fixes the static assertion failure, as the size of
dynamic allocation depends on RTE_MAX_ETHPORTS which varies based on
the build config.
Hi Vamsi,
"fix static assertion failure" is not enough descriptive.
assertions already added to verify assumptions, and in this case it seems it
failed, but what was actually wrong?
Is it that allocated memory size for ring wrong? (this is what I got from
commit log but I am not sure)
Can you please describe what actually was wrong and fixed now?
Hi Ferruh,
Earlier sa_soft_exp_ring struct member was an array of pointers and it's size
is linked to num RTE_MAX_ETHPORTS,
and the whole struct size is confined and protected by size assertion. It
resulted in build failure with -Dmax_ethports=1024
option and assertion caught that failure. V2 fixes the issues by allocating the
required memory dynamically instead
of using array of pointers.
Thanks Vamsi for details,
I was expecting a new version of patch with updated commit log,
but to make patch for -rc3 I will update it in next-net according
above information
Bugzilla ID: 940
Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
notification") Cc:sta...@dpdk.org
Reported-by: Wei Ling
Reported-by: Yu Jiang
Signed-off-by: Vamsi Attunuru
Signed-off-by: Srikanth Yalavarthi
---
V2: Add bugzilla & reportee details, remove unused changes.
---
RE: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, March 4, 2022 4:46 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
> Dabilpuram ; yux.ji...@intel.com;
> sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
>
> Subject: Re: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> failure
>
> On 3/4/2022 10:20 AM, Vamsi Krishna Attunuru wrote:
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Thursday, March 3, 2022 10:52 PM
> >> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> >> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
> >> Dabilpuram ; yux.ji...@intel.com;
> >> sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
> >>
> >> Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> >> failure
> >>
> >> External Email
> >>
> >> -
> >> - On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
> >>> Use dynamically allocated memory for storing soft expiry ring base
> >>> addresses which fixes the static assertion failure, as the size of
> >>> dynamic allocation depends on RTE_MAX_ETHPORTS which varies based
> on
> >>> the build config.
> >>>
> >>
> >> Hi Vamsi,
> >>
> >> "fix static assertion failure" is not enough descriptive.
> >> assertions already added to verify assumptions, and in this case it
> >> seems it failed, but what was actually wrong?
> >>
> >> Is it that allocated memory size for ring wrong? (this is what I got
> >> from commit log but I am not sure)
> >>
> >> Can you please describe what actually was wrong and fixed now?
> >>
> > Hi Ferruh,
> >
> > Earlier sa_soft_exp_ring struct member was an array of pointers and
> > it's size is linked to num RTE_MAX_ETHPORTS, and the whole struct size
> > is confined and protected by size assertion. It resulted in build failure
> > with -
> Dmax_ethports=1024 option and assertion caught that failure. V2 fixes the
> issues by allocating the required memory dynamically instead
> > of using array of pointers.
> >
>
> Thanks Vamsi for details,
>
> I was expecting a new version of patch with updated commit log, but to
> make patch for -rc3 I will update it in next-net according above information
Sure, thanks Ferruh.
>
> >>> Bugzilla ID: 940
> >>> Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
> >>> notification") Cc:sta...@dpdk.org
> >>>
> >>> Reported-by: Wei Ling
> >>> Reported-by: Yu Jiang
> >>> Signed-off-by: Vamsi Attunuru
> >>> Signed-off-by: Srikanth Yalavarthi
> >>> ---
> >>> V2: Add bugzilla & reportee details, remove unused changes.
> >>> ---
> >
Re: [PATCH v2 1/2] net/ice: fix Tx offload path choice
On 3/4/2022 3:31 AM, Zhang, Qi Z wrote:
-Original Message-
From: Xu, Ting
Sent: Friday, March 4, 2022 11:19 AM
To: Liu, KevinX ; dev@dpdk.org
Cc: Yang, Qiming ; Zhang, Qi Z
; Yang, SteveX ; Yigit, Ferruh
; Liu, KevinX ; sta...@dpdk.org
Subject: RE: [PATCH v2 1/2] net/ice: fix Tx offload path choice
-Original Message-
From: Kevin Liu
Sent: Wednesday, December 29, 2021 5:37 PM
To: dev@dpdk.org
Cc: Yang, Qiming ; Zhang, Qi Z
; Yang, SteveX ; Yigit,
Ferruh ; Liu, KevinX ;
sta...@dpdk.org
Subject: [PATCH v2 1/2] net/ice: fix Tx offload path choice
Testpmd forwards packets in checksum mode that it needs to calculate
the checksum of each layer's protocol.
When setting the hardware calculates the outer UDP checksum and the
software calculates the outer IP checksum, the dev->tx_pkt_burst in
ice_set_tx_function is set to ice_xmit_pkts_vec_avx2.
The inner and outer UDP checksum of the tunnel packet after forwarding
is wrong.The dev->tx_pkt_burst should be set to ice_xmit_pkts.
The patch adds RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM to
ICE_TX_NO_VECTOR_FLAGS,set dev->tx_pkt_burst to ice_xmit_pkts.After
the tunnel packet is forwarded, the inner and outer UDP checksum is correct.
At the same time, the patch of "net/ice: fix Tx Checksum offload" will
cause interrupt errors in a special case that only inner IP and inner
UDP checksum are set for hardware calculation.The patch is updating
ICE_TX_NO_VECTOR_FLAGS, the problem can be solved, so I will restore
the code modification of that patch.
Fixes: 28f9002ab67f ("net/ice: add Tx AVX512 offload path")
Fixes: 295968d17407 ("ethdev: add namespace")
Fixes: 17c7d0f9d6a4 ("net/ice: support basic Rx/Tx")
Cc: sta...@dpdk.org
Signed-off-by: Kevin Liu
<...>
Acked-by: Ting Xu
Applied to dpdk-next-net-intel.
Converting Qi's implicit ack to explicit (as ice maintainer):
Reviewed-by: Qi Zhang
And updating it in next-net.
RE: [RFC] ethdev: introduce protocol type based header split
> From: Zhang, Qi Z [mailto:qi.z.zh...@intel.com]
> Sent: Friday, 4 March 2022 10.58
>
> > From: Stephen Hemminger
> > Sent: Friday, March 4, 2022 12:16 AM
> >
> > On Thu, 3 Mar 2022 06:01:36 +
> > xuan.d...@intel.com wrote:
> >
> > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index
> > > c2d1f9a972..6743648c22 100644
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split {
> > > struct rte_mempool *mp; /**< Memory pool to allocate segment
> from.
> > */
> > > uint16_t length; /**< Segment data length, configures split
> point. */
> > > uint16_t offset; /**< Data offset from beginning of mbuf data
> buffer. */
> > > - uint32_t reserved; /**< Reserved field. */
> > > + uint16_t proto;
> > > + uint16_t reserved; /**< Reserved field. */
> > > };
> >
> > This feature suffers from a common bad design pattern.
> > You can't just start using reserved fields unless the previous
> versions enforced
> > that the field was a particular value (usually zero).
>
> Yes, agree, that's a mistake there is no document for the reserved
> field in the previous release, and usually, it should be zero,
> And I think one of the typical purposes of the reserved field is to
> make life easy for new feature adding without breaking ABI.
> So, should we just take the risk as I guess it might not be a big deal
> in real cases?
>
In this specific case, I think it can be done with very low risk in real cases.
Assuming that splitting based on fixed length and protocol header parsing is
mutually exclusive, the PMDs can simply ignore the "proto" field (and log a
warning about it) if the length field is non-zero. This will provide backwards
compatibility with applications not zeroing out the 32 bit "reserved" field.
> Thanks
> Qi
>
>
>
> >
> > There is no guarantee that application will initialize these reserved
> fields and
> > now using them risks breaking the API/ABI. It looks like
> >
> > rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split
> *rx_seg,
> >
> > Would have had to check in previous release.
> >
> > This probably has to wait until 22.11 next API release.
RE: release candidate 22.03-rc2
> -Original Message- > From: Jiang, YuX > Sent: Thursday, March 3, 2022 12:13 PM > To: Jiang, YuX ; Thomas Monjalon > ; dev (dev@dpdk.org) > Cc: Devlin, Michelle ; Mcnamara, John > ; Yigit, Ferruh ; Sun, > QingX > Subject: RE: release candidate 22.03-rc2 > > > -Original Message- > > From: Jiang, YuX > > Sent: Tuesday, March 1, 2022 6:57 PM > > To: Thomas Monjalon ; dev (dev@dpdk.org) > > > > Cc: Devlin, Michelle ; Mcnamara, John > > ; Yigit, Ferruh ; > > Sun, QingX > > Subject: RE: release candidate 22.03-rc2 > > > > > -Original Message- > > > From: Thomas Monjalon > > > Sent: Monday, February 28, 2022 5:02 AM > > > To: annou...@dpdk.org > > > Subject: release candidate 22.03-rc2 > > > > > > A new DPDK release candidate is ready for testing: > > > https://git.dpdk.org/dpdk/tag/?id=v22.03-rc2 > > > > > > There are 306 new patches in this snapshot. > > > > > > Release notes: > > > https://doc.dpdk.org/guides/rel_notes/release_22_03.html > > > > > > Highlights of 22.03-rc2: > > > - ethdev flow API for templates and async operations > > > - Marvell GPIO driver for CNXK > > > > > > The driver features should be frozen now. > > > Please test and report issues on bugs.dpdk.org. > > > > > > DPDK 22.03-rc3 is expected in one week. > > > > > > Thank you everyone > > > > Update the test status for Intel part. Till now dpdk22.03-rc2 test execution > rate is 80%. No critical issue is found. > > # Basic Intel(R) NIC testing > * Build or compile: > *Build: cover the build test combination with latest GCC/Clang/ICC version > and the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, > RHEL8.5 etc. > - All test passed. > - One known issue https://bugs.dpdk.org/show_bug.cgi?id=928, use > "meson setup -Ddisable_drivers=event/cnxk" to build. > *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as > Ubuntu20.04 and RHEL8.4. > - All test done. > - One new bug https://bugs.dpdk.org/show_bug.cgi?id=939 is found. >> Rakesh Kudurumalla provides a patch, but we verify failed with > gcc10.3.0+kernel-5.8.0-48-generic on Ubuntu20.04. > > * PF(i40e, ixgbe): test scenarios including > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > - Execution rate is 80%. One new bug > https://bugs.dpdk.org/show_bug.cgi?id=944 is found. > > * VF(i40e, ixgbe): test scenarios including VF- > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > - Execution rate is 80%. > - One new bug about "vf_daemon/vf_mtu: VF setting MTU in DPDK then > send one packet ,VF0 can't receive and transmit packet", Intel dev is > investigating. > > * PF/VF(ice): test scenarios including Switch features/Package > Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible > Descriptor, etc. > - Execution rate is 90%. > - One new bug about "https://bugs.dpdk.org/show_bug.cgi?id=941 [dpdk- > 22.03] core dump when create fdir rule with bad arguments" is found. >> It has been fixed by patch > https://patchwork.dpdk.org/project/dpdk/patch/20220301224739.3072563- > 1-akozy...@nvidia.com/ > > * Intel NIC single core/NIC performance: test scenarios including PF/VF single > core performance test, RFC2544 Zero packet loss performance test, etc. > - All test passed. No big performance drop. > > * Power and IPsec: > * Power: test scenarios including bi-direction/Telemetry/Empty Poll > Lib/Priority Base Frequency, etc. > - All test passed. > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - > QAT&SW/FIB library, etc. > - All test done. > - One new bug about "Failure with testing crypto -ipsec-secgw with AUTH- > GMAC" is found. > > It has fix: > https://patches.dpdk.org/project/dpdk/patch/20220301134133.1886839-1- > radu.nico...@intel.com/ > > # 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. One new bug https://bugs.dpdk.org/show_bug.cgi?id=940 is > found. > * Cryptodev: > *Function test: test scenarios including Cryptodev API testing/CompressDev > ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. > - Execution rate is 20%. One new bug about "Failed to run > cryptodev_qat_asym_autotest" is found. Intel dev is investigating. > *Performance test: test scenarios including Thoughput Performance > /Cryptodev Latency, etc. > - Execution rate is 20%. > > BRs > Yu Jiang Update the test status for Intel part. Till now dpdk22.03-rc2 test is almost finished. No critical issue is found. # Basic Intel(R) NIC testing * Build or compile: *Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, RHEL8.5 etc. - All test passed. - One known issue https://bugs.dpdk.org/show_bug.cgi?id=928, use "meson setup -Ddisable_drivers=event/cnxk" to ICC build. *Compile: cover the CFLAGE
[PATCH 1/3] net/qede: fix Tx callback completion routine
Tx completion routine was first incrementing no. of free slots in Tx
ring and then freeing corresponding mbufs in bulk. In some situations
no. of mbufs freed were less than no. of Tx ring slots freed. This
caused TX ring to get into an inconsistent state and ultimately
application fails to transmit further traffic.
The fix first updates Tx ring SW consumer index, then increments Tx ring
free slot no. and finally frees the mbuf, this is done in a single
iteration of loop.
Fixes: 2c41740bf19e ("net/qede: get consumer index once")
Fixes: 4996b959cde6 ("net/qede: free packets in bulk")
Cc: sta...@dpdk.org
Signed-off-by: Devendra Singh Rawat
Signed-off-by: Rasesh Mody
---
drivers/net/qede/qede_rxtx.c | 79 +++-
1 file changed, 33 insertions(+), 46 deletions(-)
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 911bb1a260..0c52568180 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -885,68 +885,55 @@ qede_tx_queue_start(struct rte_eth_dev *eth_dev, uint16_t
tx_queue_id)
}
static inline void
-qede_process_tx_compl(__rte_unused struct ecore_dev *edev,
- struct qede_tx_queue *txq)
+qede_free_tx_pkt(struct qede_tx_queue *txq)
{
- uint16_t hw_bd_cons;
- uint16_t sw_tx_cons;
- uint16_t remaining;
- uint16_t mask;
struct rte_mbuf *mbuf;
uint16_t nb_segs;
uint16_t idx;
- uint16_t first_idx;
-
- rte_compiler_barrier();
- rte_prefetch0(txq->hw_cons_ptr);
- sw_tx_cons = ecore_chain_get_cons_idx(&txq->tx_pbl);
- hw_bd_cons = rte_le_to_cpu_16(*txq->hw_cons_ptr);
-#ifdef RTE_LIBRTE_QEDE_DEBUG_TX
- PMD_TX_LOG(DEBUG, txq, "Tx Completions = %u\n",
- abs(hw_bd_cons - sw_tx_cons));
-#endif
-
- mask = NUM_TX_BDS(txq);
- idx = txq->sw_tx_cons & mask;
- remaining = hw_bd_cons - sw_tx_cons;
- txq->nb_tx_avail += remaining;
- first_idx = idx;
-
- while (remaining) {
- mbuf = txq->sw_tx_ring[idx];
- RTE_ASSERT(mbuf);
+ idx = TX_CONS(txq);
+ mbuf = txq->sw_tx_ring[idx];
+ if (mbuf) {
nb_segs = mbuf->nb_segs;
- remaining -= nb_segs;
-
- /* Prefetch the next mbuf. Note that at least the last 4 mbufs
-* that are prefetched will not be used in the current call.
-*/
- rte_mbuf_prefetch_part1(txq->sw_tx_ring[(idx + 4) & mask]);
- rte_mbuf_prefetch_part2(txq->sw_tx_ring[(idx + 4) & mask]);
-
PMD_TX_LOG(DEBUG, txq, "nb_segs to free %u\n", nb_segs);
-
while (nb_segs) {
+ /* It's like consuming rxbuf in recv() */
ecore_chain_consume(&txq->tx_pbl);
+ txq->nb_tx_avail++;
nb_segs--;
}
-
- idx = (idx + 1) & mask;
+ rte_pktmbuf_free(mbuf);
+ txq->sw_tx_ring[idx] = NULL;
+ txq->sw_tx_cons++;
PMD_TX_LOG(DEBUG, txq, "Freed tx packet\n");
- }
- txq->sw_tx_cons = idx;
-
- if (first_idx > idx) {
- rte_pktmbuf_free_bulk(&txq->sw_tx_ring[first_idx],
- mask - first_idx + 1);
- rte_pktmbuf_free_bulk(&txq->sw_tx_ring[0], idx);
} else {
- rte_pktmbuf_free_bulk(&txq->sw_tx_ring[first_idx],
- idx - first_idx);
+ ecore_chain_consume(&txq->tx_pbl);
+ txq->nb_tx_avail++;
}
}
+static inline void
+qede_process_tx_compl(__rte_unused struct ecore_dev *edev,
+ struct qede_tx_queue *txq)
+{
+ uint16_t hw_bd_cons;
+#ifdef RTE_LIBRTE_QEDE_DEBUG_TX
+ uint16_t sw_tx_cons;
+#endif
+
+ hw_bd_cons = rte_le_to_cpu_16(*txq->hw_cons_ptr);
+ /* read barrier prevents speculative execution on stale data */
+ rte_rmb();
+
+#ifdef RTE_LIBRTE_QEDE_DEBUG_TX
+ sw_tx_cons = ecore_chain_get_cons_idx(&txq->tx_pbl);
+ PMD_TX_LOG(DEBUG, txq, "Tx Completions = %u\n",
+ abs(hw_bd_cons - sw_tx_cons));
+#endif
+ while (hw_bd_cons != ecore_chain_get_cons_idx(&txq->tx_pbl))
+ qede_free_tx_pkt(txq);
+}
+
static int qede_drain_txq(struct qede_dev *qdev,
struct qede_tx_queue *txq, bool allow_drain)
{
--
2.18.2
[PATCH 2/3] net/qede: fix Rx callback
qede_alloc_rx_bulk_mbufs was trimming the no. of requested mbufs count
to QEDE_MAX_BULK_ALLOC_COUNT. The RX callback was ignorant of this
trimming and it was always resetting the no. of empty RX BD ring
slots to 0. This resulted in RX BD ring getting into an inconsistent
state and ultimately the application fails to receive any traffic.
The fix trims the no. of requested mbufs count before making call to
qede_alloc_rx_bulk_mbufs. After qede_alloc_rx_bulk_mbufs returns
successfully, the no. of empty RX BD ring slots are decremented by the
correct count.
Fixes: 8f2312474529 ("net/qede: fix performance bottleneck in Rx path")
Cc: sta...@dpdk.org
Signed-off-by: Devendra Singh Rawat
Signed-off-by: Rasesh Mody
---
drivers/net/qede/qede_rxtx.c | 68
1 file changed, 31 insertions(+), 37 deletions(-)
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 0c52568180..02fa1fcaa1 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -38,48 +38,40 @@ static inline int qede_alloc_rx_buffer(struct qede_rx_queue
*rxq)
static inline int qede_alloc_rx_bulk_mbufs(struct qede_rx_queue *rxq, int
count)
{
+ void *obj_p[QEDE_MAX_BULK_ALLOC_COUNT] __rte_cache_aligned;
struct rte_mbuf *mbuf = NULL;
struct eth_rx_bd *rx_bd;
dma_addr_t mapping;
int i, ret = 0;
uint16_t idx;
- uint16_t mask = NUM_RX_BDS(rxq);
-
- if (count > QEDE_MAX_BULK_ALLOC_COUNT)
- count = QEDE_MAX_BULK_ALLOC_COUNT;
idx = rxq->sw_rx_prod & NUM_RX_BDS(rxq);
- if (count > mask - idx + 1)
- count = mask - idx + 1;
-
- ret = rte_mempool_get_bulk(rxq->mb_pool, (void **)&rxq->sw_rx_ring[idx],
- count);
-
+ ret = rte_mempool_get_bulk(rxq->mb_pool, obj_p, count);
if (unlikely(ret)) {
PMD_RX_LOG(ERR, rxq,
"Failed to allocate %d rx buffers "
"sw_rx_prod %u sw_rx_cons %u mp entries %u free %u",
- count,
- rxq->sw_rx_prod & NUM_RX_BDS(rxq),
- rxq->sw_rx_cons & NUM_RX_BDS(rxq),
+ count, idx, rxq->sw_rx_cons & NUM_RX_BDS(rxq),
rte_mempool_avail_count(rxq->mb_pool),
rte_mempool_in_use_count(rxq->mb_pool));
return -ENOMEM;
}
for (i = 0; i < count; i++) {
- rte_prefetch0(rxq->sw_rx_ring[(idx + 1) & NUM_RX_BDS(rxq)]);
- mbuf = rxq->sw_rx_ring[idx & NUM_RX_BDS(rxq)];
+ mbuf = obj_p[i];
+ if (likely(i < count - 1))
+ rte_prefetch0(obj_p[i + 1]);
+ idx = rxq->sw_rx_prod & NUM_RX_BDS(rxq);
+ rxq->sw_rx_ring[idx] = mbuf;
mapping = rte_mbuf_data_iova_default(mbuf);
rx_bd = (struct eth_rx_bd *)
ecore_chain_produce(&rxq->rx_bd_ring);
rx_bd->addr.hi = rte_cpu_to_le_32(U64_HI(mapping));
rx_bd->addr.lo = rte_cpu_to_le_32(U64_LO(mapping));
- idx++;
+ rxq->sw_rx_prod++;
}
- rxq->sw_rx_prod = idx;
return 0;
}
@@ -1544,25 +1536,26 @@ qede_recv_pkts_regular(void *p_rxq, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts)
uint8_t bitfield_val;
#endif
uint8_t offset, flags, bd_num;
-
+ uint16_t count = 0;
/* Allocate buffers that we used in previous loop */
if (rxq->rx_alloc_count) {
- if (unlikely(qede_alloc_rx_bulk_mbufs(rxq,
-rxq->rx_alloc_count))) {
+ count = rxq->rx_alloc_count > QEDE_MAX_BULK_ALLOC_COUNT ?
+ QEDE_MAX_BULK_ALLOC_COUNT : rxq->rx_alloc_count;
+
+ if (unlikely(qede_alloc_rx_bulk_mbufs(rxq, count))) {
struct rte_eth_dev *dev;
PMD_RX_LOG(ERR, rxq,
- "New buffer allocation failed,"
- "dropping incoming packetn");
+ "New buffers allocation failed,"
+ "dropping incoming packets\n");
dev = &rte_eth_devices[rxq->port_id];
- dev->data->rx_mbuf_alloc_failed +=
- rxq->rx_alloc_count;
- rxq->rx_alloc_errors += rxq->rx_alloc_count;
+ dev->data->rx_mbuf_alloc_failed += count;
+ rxq->rx_alloc_errors += count;
return 0;
}
qede_update_rx_prod(qdev, rxq);
- rxq->rx_alloc_count = 0;
+ rxq->rx_alloc_count -= count;
}
hw_comp_cons = rte_le_to_cpu_16(*rxq->hw_cons_ptr);
@@ -173
[PATCH 3/3] net/qede: fix max Rx pktlen calculation
size of CRC is not added to max_rx_pktlen, due to this bigger sized
packets(size 1480, 1490 1500) are being dropped.
This fix adds RTE_ETHER_CRC_LEN to max_rx_pktlen.
Fixes: 1bb4a528c41f ("ethdev: fix max Rx packet length")
Cc: sta...@dpdk.org
Signed-off-by: Devendra Singh Rawat
Signed-off-by: Rasesh Mody
---
drivers/net/qede/qede_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 02fa1fcaa1..c35585f5fd 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -235,7 +235,7 @@ qede_rx_queue_setup(struct rte_eth_dev *dev, uint16_t qid,
dev->data->rx_queues[qid] = NULL;
}
- max_rx_pktlen = dev->data->mtu + RTE_ETHER_HDR_LEN;
+ max_rx_pktlen = dev->data->mtu + RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN;
/* Fix up RX buffer size */
bufsz = (uint16_t)rte_pktmbuf_data_room_size(mp) - RTE_PKTMBUF_HEADROOM;
--
2.18.2
Re: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
On 3/4/2022 10:20 AM, Vamsi Krishna Attunuru wrote:
-Original Message-
From: Ferruh Yigit
Sent: Thursday, March 3, 2022 10:52 PM
To: Vamsi Krishna Attunuru ; dev@dpdk.org
Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
Dabilpuram ; yux.ji...@intel.com;
sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
External Email
--
On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
Use dynamically allocated memory for storing soft expiry ring base
addresses which fixes the static assertion failure, as the size of
dynamic allocation depends on RTE_MAX_ETHPORTS which varies based on
the build config.
Hi Vamsi,
"fix static assertion failure" is not enough descriptive.
assertions already added to verify assumptions, and in this case it seems it
failed, but what was actually wrong?
Is it that allocated memory size for ring wrong? (this is what I got from
commit log but I am not sure)
Can you please describe what actually was wrong and fixed now?
Hi Ferruh,
Earlier sa_soft_exp_ring struct member was an array of pointers and it's size
is linked to num RTE_MAX_ETHPORTS,
and the whole struct size is confined and protected by size assertion. It
resulted in build failure with -Dmax_ethports=1024
option and assertion caught that failure. V2 fixes the issues by allocating the
required memory dynamically instead
of using array of pointers.
just to double check if I got it right,
The failing assertion is:
PLT_STATIC_ASSERT(sizeof(struct nix_inl_dev) <= ROC_NIX_INL_MEM_SZ);
Technically you can calculate the 'ROC_NIX_INL_MEM_SZ' as a function
of 'RTE_MAX_ETHPORTS' and that would work (although need to calculate
size for proper cache alignment).
But instead you prefer to convert array to function pointer to fix
the struct size and make it independent from the configured
'RTE_MAX_ETHPORTS' config.
And I assume current magic number for the 'ROC_NIX_INL_MEM_SZ' is
calculated based on max memory requirement of the cn9k & cn10k:
#define ROC_NIX_INL_MEM_SZ (1280)
If so it can be better to describe 'ROC_NIX_INL_MEM_SZ' as what
it is calculated from, like following but it is up to you:
max(sizeof(x), sizeof(y)) ...
Bugzilla ID: 940
Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
notification") Cc:sta...@dpdk.org
Reported-by: Wei Ling
Reported-by: Yu Jiang
Signed-off-by: Vamsi Attunuru
Signed-off-by: Srikanth Yalavarthi
---
V2: Add bugzilla & reportee details, remove unused changes.
---
[Bug 949] net/mlx5: errors when sending from extbuf pool
https://bugs.dpdk.org/show_bug.cgi?id=949 Bug ID: 949 Summary: net/mlx5: errors when sending from extbuf pool Product: DPDK Version: 21.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: bme...@sarao.ac.za Target Milestone: --- Created attachment 193 --> https://bugs.dpdk.org/attachment.cgi?id=193&action=edit Example code Given the lack of documentation it's likely that I'm just holding it wrong, but I'm having trouble when trying to transmit segmented packets where one of the segments is from a pool created with rte_pktmbuf_pool_create_extbuf. I've reduced my test to the attached program. The test builds and transmits multicast UDP (IPv4) frames. The L2-L4 headers are in a regular mbuf, chained to a separate mbuf holding the payload. If the USE_EXTERNAL define at the top is changed to 0, the payload mbuf is a boring standard mbuf, and everything works and I can receive the packets on another machine. When USE_EXTERNAL=1, a single huge page is allocated with mmap, then used to back the mempool for payloads (via rte_pktmbuf_pool_create_extbuf). In this case, I get a whole bunch of files written with names like dpdk_mlx5_port_0_txq_0_index_0_1383899876, reporting CQ and SQ errors, and I don't receive the packets (and the tx ethtool counters don't go up). -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH] vhost: use colon in version.map
On 3/3/2022 11:32 AM, Xia, Chenbo wrote: -Original Message- From: Peng Yu Sent: Tuesday, February 15, 2022 1:56 PM To: dev@dpdk.org Cc: Peng Yu ; Ray Kinsella ; Maxime Coquelin ; Xia, Chenbo Subject: [PATCH] vhost: use colon in version.map The punctuation after the `global` keyword should be colon, not semicolon. The default gcc linker accepts both colon and semicolon, but the gold linker will report syntax error if we use semicolon after the `global` keyword. Signed-off-by: Peng Yu Reviewed-by: Chenbo Xia Applied to dpdk-next-net/main, thanks.
RE: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion failure
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, March 4, 2022 6:44 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
> Dabilpuram ; yux.ji...@intel.com;
> sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
>
> Subject: Re: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> failure
>
> On 3/4/2022 10:20 AM, Vamsi Krishna Attunuru wrote:
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Thursday, March 3, 2022 10:52 PM
> >> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> >> Cc: Jerin Jacob Kollanukkaran ; Nithin Kumar
> >> Dabilpuram ; yux.ji...@intel.com;
> >> sta...@dpdk.org; Wei Ling ; Srikanth Yalavarthi
> >>
> >> Subject: [EXT] Re: [PATCH v2 1/1] common/cnxk: fix static assertion
> >> failure
> >>
> >> External Email
> >>
> >> -
> >> - On 3/2/2022 1:46 PM, Vamsi Attunuru wrote:
> >>> Use dynamically allocated memory for storing soft expiry ring base
> >>> addresses which fixes the static assertion failure, as the size of
> >>> dynamic allocation depends on RTE_MAX_ETHPORTS which varies based
> on
> >>> the build config.
> >>>
> >>
> >> Hi Vamsi,
> >>
> >> "fix static assertion failure" is not enough descriptive.
> >> assertions already added to verify assumptions, and in this case it
> >> seems it failed, but what was actually wrong?
> >>
> >> Is it that allocated memory size for ring wrong? (this is what I got
> >> from commit log but I am not sure)
> >>
> >> Can you please describe what actually was wrong and fixed now?
> >>
> > Hi Ferruh,
> >
> > Earlier sa_soft_exp_ring struct member was an array of pointers and
> > it's size is linked to num RTE_MAX_ETHPORTS, and the whole struct size
> > is confined and protected by size assertion. It resulted in build failure
> > with -
> Dmax_ethports=1024 option and assertion caught that failure. V2 fixes the
> issues by allocating the required memory dynamically instead
> > of using array of pointers.
> >
>
> just to double check if I got it right,
>
> The failing assertion is:
> PLT_STATIC_ASSERT(sizeof(struct nix_inl_dev) <= ROC_NIX_INL_MEM_SZ);
>
Yes.
> Technically you can calculate the 'ROC_NIX_INL_MEM_SZ' as a function of
> 'RTE_MAX_ETHPORTS' and that would work (although need to calculate size
> for proper cache alignment).
>
> But instead you prefer to convert array to function pointer to fix the struct
> size and make it independent from the configured 'RTE_MAX_ETHPORTS'
> config.
>
Correct.
>
> And I assume current magic number for the 'ROC_NIX_INL_MEM_SZ' is
> calculated based on max memory requirement of the cn9k & cn10k:
> #define ROC_NIX_INL_MEM_SZ (1280)
>
> If so it can be better to describe 'ROC_NIX_INL_MEM_SZ' as what it is
> calculated from, like following but it is up to you:
> max(sizeof(x), sizeof(y)) ...
>
correct, I will check the better approach upon the usage.
> >>> Bugzilla ID: 940
> >>> Fixes: d26185716d3f ("net/cnxk: support outbound soft expiry
> >>> notification") Cc:sta...@dpdk.org
> >>>
> >>> Reported-by: Wei Ling
> >>> Reported-by: Yu Jiang
> >>> Signed-off-by: Vamsi Attunuru
> >>> Signed-off-by: Srikanth Yalavarthi
> >>> ---
> >>> V2: Add bugzilla & reportee details, remove unused changes.
> >>> ---
> >
[Bug 950] Windows DPDK L2fwd- Receiving packets out of sequence
https://bugs.dpdk.org/show_bug.cgi?id=950 Bug ID: 950 Summary: Windows DPDK L2fwd- Receiving packets out of sequence Product: DPDK Version: 21.11 Hardware: Other OS: Windows Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: cagnibu...@vusra.com Target Milestone: --- I am validating DPDK receive functionality & for this I'm shooting a pcap externally & added code in l2fwd to dump received packets to pcap, the l2fwd dumped pcap have all the packets from shooter but some of them are not in sequence. Shooter is already validated. Out of order packets are random. For the first run I saw 3 out of order packets and on the second run there were 6 packets out of order. NIC used : Mellanox Connectx-6Dx l2fwd arguments : dpdk-l2fwd.exe -l 1,2 -n 1 -- -p 0x3 -q 1 -P. Link of the pcap used : https://wiki.wireshark.org/uploads/__moin_import__/attachments/SampleCaptures/tcp-ecn-sample.pcap Also opened a thread on this issue on stack overflow link:https://stackoverflow.com/questions/71307805/windows-dpdk-l2fwd-receiving-packets-out-of-sequence -- You are receiving this mail because: You are the assignee for the bug.
[PATCH] net/cnxk: fix error when compiled for x86
fix error when compiled for x86 platform when compiled
with optimization flag enabled
error: ‘str’ may be used uninitialized in this function
error: ‘frag_ptr’ may be used uninitialized in this function
Bugzilla ID: 939
Fixes: b526599020ef ("net/cnxk: fix build with GCC 12")
Cc: sta...@dpdk.org
Reported-by: Ferruh Yigit
Signed-off-by: Rakesh Kudurumalla
---
drivers/net/cnxk/cn10k_rx.h| 5 +++--
drivers/net/cnxk/cnxk_ethdev_mtr.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cnxk/cn10k_rx.h b/drivers/net/cnxk/cn10k_rx.h
index 7f219e5ddd..e4f5a553a6 100644
--- a/drivers/net/cnxk/cn10k_rx.h
+++ b/drivers/net/cnxk/cn10k_rx.h
@@ -146,7 +146,8 @@ nix_sec_attach_frags(const struct cpt_parse_hdr_s *hdr,
uint32_t offset = hdr->w2.fi_offset;
union nix_rx_parse_u *frag_rx;
struct cpt_frag_info_s *finfo;
- uint64_t *frag_ptr, ol_flags;
+ uint64_t *frag_ptr = NULL;
+ uint64_t ol_flags;
uint16_t frag_size;
uint16_t rlen;
uint64_t *wqe;
@@ -276,8 +277,8 @@ nix_sec_reassemble_frags(const struct cpt_parse_hdr_s *hdr,
uint64_t cq_w1,
union nix_rx_parse_u *frag_rx;
struct cpt_frag_info_s *finfo;
struct rte_mbuf *head, *mbuf;
+ uint64_t *frag_ptr = NULL;
rte_iova_t *inner_iova;
- uint64_t *frag_ptr;
uint16_t frag_size;
uint64_t *wqe;
diff --git a/drivers/net/cnxk/cnxk_ethdev_mtr.c
b/drivers/net/cnxk/cnxk_ethdev_mtr.c
index c8183aa12d..02803bdf75 100644
--- a/drivers/net/cnxk/cnxk_ethdev_mtr.c
+++ b/drivers/net/cnxk/cnxk_ethdev_mtr.c
@@ -288,7 +288,7 @@ cnxk_nix_mtr_profile_delete(struct rte_eth_dev *eth_dev,
uint32_t profile_id,
static int
update_mtr_err(uint32_t act_color, struct rte_mtr_error *error, bool action)
{
- const char *str;
+ const char *str = NULL;
switch (act_color) {
case RTE_COLOR_GREEN:
if (action) {
--
2.25.1
Re: [PATCH] net/kni: initialize rte_kni_conf to 0 before using it
On 3/3/2022 2:18 AM, Harold Huang wrote:
When kni driver calls eth_kni_start to start device, some fields such as
min_mtu and max_mtu of rte_kni_conf are not initialized. It will cause
kni_ioctl_create create a kni netdevice with a random min_mtu and max_mtu
value. This is unexpected and sometimes we could not change the kni
device mtu with ip link command.
Fixes: ff1e35fb5f83 ("kni: calculate MTU from mbuf size")
Cc: sta...@dpdk.org
Signed-off-by: Harold Huang
---
drivers/net/kni/rte_eth_kni.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
index c428caf441..ba58d9dbae 100644
--- a/drivers/net/kni/rte_eth_kni.c
+++ b/drivers/net/kni/rte_eth_kni.c
@@ -124,7 +124,7 @@ eth_kni_start(struct rte_eth_dev *dev)
struct pmd_internals *internals = dev->data->dev_private;
uint16_t port_id = dev->data->port_id;
struct rte_mempool *mb_pool;
- struct rte_kni_conf conf;
+ struct rte_kni_conf conf = { 0 };
This is causing build error [1], updated in next-net [2] to fix.
Normally '{ 0 }' should be universal zero-initializer, but I guess
it fails because of old compiler version:
gcc 4.8.5 "cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)"
[1]
FAILED: drivers/a715181@@tmp_rte_net_kni@sta/net_kni_rte_eth_kni.c.o
../drivers/net/kni/rte_eth_kni.c: In function 'eth_kni_start':
../drivers/net/kni/rte_eth_kni.c:127:9:
error: missing braces around initializer [-Werror=missing-braces]
struct rte_kni_conf conf = { 0 };
^
[2]
struct rte_kni_conf conf = {{0}};
const char *name = dev->device->name + 4; /* remove net_ */
mb_pool = internals->rx_queues[0].mb_pool;
Re: [PATCH v2] examples/vhost: fix launch failure with physical port
On 3/4/2022 9:51 AM, Xia, Chenbo wrote:
-Original Message-
From: Ma, WenwuX
Sent: Saturday, March 5, 2022 12:24 AM
To: maxime.coque...@redhat.com; Xia, Chenbo ;
dev@dpdk.org
Cc: Hu, Jiayu ; Wang, Yinan ; He,
Xingguang ; Ma, WenwuX ;
sta...@dpdk.org
Subject: [PATCH v2] examples/vhost: fix launch failure with physical port
dpdk-vhost will fail to launch with a 40G i40e port because
there are not enough mbufs. This patch adds a new option
--total-num-mbufs, through which the user can set larger
mbuf pool to avoid this problem.
Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
examples/vhost/main.c | 83 +++
1 file changed, 29 insertions(+), 54 deletions(-)
Reviewed-by: Chenbo Xia
Applied to dpdk-next-net/main, thanks.
Re: [PATCH v5] app/testpmd: add help messages for multi-process
On 3/4/2022 6:26 AM, Min Hu (Connor) wrote:
From: Huisong Li
This patch adds help messages for multi-process.
--num-procs , where N is the total number of symmetric_mp instances
that will be run side-by-side to perform packet processing. This parameter
is used to configure the appropriate number of receive queues on each
network port.
--proc-id , where n is a numeric value in the range 0 <= n < N (number
of processes, specified above). This identifies which symmetric_mp instance
is being run, so that each process can read a unique receive queue on each
network port.
Fixes: a550baf24af9 ("app/testpmd: support multi-process")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
---
v5:
* delete space
v4:
* update description for parameters.
v3,v2:
* adjust the position of parameters.
---
app/test-pmd/parameters.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index daf6a31b2b..6c4253ae61 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -61,6 +61,8 @@ usage(char* progname)
"extended statistics to show. Used with --stats-period "
"specified or interactive commands that show Rx/Tx statistics "
"(i.e. 'show port stats').\n");
+ printf(" --num-procs: the total number of symmetric_mp instances that will
be run side-by-side\n");
I am not exactly sure what is 'symmetric' in 'symmetric_mp' here,
there is a sample application with this name but I guess 'symmetric'
is related to that sample functionality.
Would you mind if I change 'symmetric_mp' with 'multi-process'
while applying?
+ printf(" --proc-id: the id of the current process (id < num-procs) to
identify which symmetric_mp instance is being run\n");
printf(" --nb-cores=N: set the number of forwarding cores "
"(1 <= N <= %d).\n", nb_lcores);
printf(" --nb-ports=N: set the number of forwarding ports "
[PATCH] devtools/cocci: change boolean negation to bitwise negation
Combining boolean operator with bitwise operator is suspicious. When this happens, it has a chance that the bitwise negation operation is mistakenly written as a boolean negation operation. This script is used to find this kind of problems. example: if (x & !BITS_MASK) changed to: if (x & ~BITS_MASK) The idea came from a demo script in coccinelle website: https://coccinelle.gitlabpages.inria.fr/website/rules/notand.html Signed-off-by: Weiguo Li --- devtools/cocci/bitwise_negation.cocci | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 devtools/cocci/bitwise_negation.cocci diff --git a/devtools/cocci/bitwise_negation.cocci b/devtools/cocci/bitwise_negation.cocci new file mode 100644 index 00..78fc677e4e --- /dev/null +++ b/devtools/cocci/bitwise_negation.cocci @@ -0,0 +1,18 @@ +// +// The bitwise negation operation is easy to be mistakenly written as a boolean +// negation operation, this script is used to find this kind of problem. +// +// Note: If it is confirmed to be a boolean negation operation, it is recommended +// that change & to && to avoid false positives. +// +@@ expression E; constant C; @@ +( + !E & !C +| +- !E & C ++ !(E & C) +| +- E & !C ++ E & ~C +) + -- 2.25.1
Re: [PATCH v5] app/testpmd: add help messages for multi-process
On 3/4/2022 9:11 AM, Zhang, Yuying wrote:
Hi Minhu,
-Original Message-
From: Min Hu (Connor)
Sent: Friday, March 4, 2022 2:27 PM
To: dev@dpdk.org
Cc: Huisong Li ; sta...@dpdk.org; Min Hu
; Li, Xiaoyun ; Singh, Aman
Deep ; Zhang, Yuying
; Ajit Khaparde ;
Andrew Rybchenko ; Yigit, Ferruh
Subject: [PATCH v5] app/testpmd: add help messages for multi-process
From: Huisong Li
This patch adds help messages for multi-process.
--num-procs , where N is the total number of symmetric_mp instances
that will be run side-by-side to perform packet processing. This parameter is
used to configure the appropriate number of receive queues on each
network port.
--proc-id , where n is a numeric value in the range 0 <= n < N (number of
processes, specified above). This identifies which symmetric_mp instance is
being run, so that each process can read a unique receive queue on each
network port.
Fixes: a550baf24af9 ("app/testpmd: support multi-process")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
Acked-by: Yuying Zhang
Updated 'symmetric_mp' -> 'multi-process', with this change
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
Re: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure
On 3/3/2022 1:22 PM, Wu, WenxuanX wrote:
moved down, please don't top post
-Original Message-
From: Wu, WenxuanX
Sent: 2022年2月23日 19:33
To: Li, Xiaoyun ; Yigit, Ferruh
; dev@dpdk.org
Cc: Wu, WenxuanX ; sta...@dpdk.org
Subject: [PATCH v2 2/2] app/testpmd:fix testpmd quit failure
From: wenxuan wu
When testpmd start ed with 1 pf and 2 vfs, testpmd quited while vfs were
still alive would result in failure. Root cause is that pf had been released
already but vfs were still accessing by func rte_eth_dev_info_get, which
would result in heap-free-after-use error.
By quitting our ports in reverse order to avoid this.And the order is
guaranteed that vf are created after pfs.
Fixes: d3a274ce9dee ("app/testpmd: handle SIGINT and SIGTERM")
Cc: sta...@dpdk.org
Signed-off-by: wenxuan wu
---
app/test-pmd/testpmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
e1da961311..698b6d8cc4 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3384,12 +3384,12 @@ pmd_test_exit(void) #endif
if (ports != NULL) {
no_link_check = 1;
- RTE_ETH_FOREACH_DEV(pt_id) {
+ RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
printf("\nStopping port %d...\n", pt_id);
fflush(stdout);
stop_port(pt_id);
}
- RTE_ETH_FOREACH_DEV(pt_id) {
+ RTE_ETH_FOREACH_DEV_REVERSE(pt_id) {
printf("\nShutting down port %d...\n", pt_id);
fflush(stdout);
close_port(pt_id);
--
2.25.1
I found this meaning in DPDK testplan.
Note that currently hot-plugging of representor ports is not supported so all
the required representors must be specified on the creation of the PF or the
trusted VF.
When testpmd is started with pf and vf representors, the order of representor
is determined on creation. So it is guaranteed that ,pf is beneath the vf
representors, we implemented in a reverse way is acceptable just at present,
depends on when the hot-plugging of representor is supported.
The patch mentions from PF and VFs, and now you are referring
to port representor.
Is the problem related to VF or port representor.
For both, VF and port reporesentor should be closed before
PF, that part is OK. My comment is if reversing port id
traverse will fix the issue or do we need more complex
solution.
Like have APIs to get VF and representor ports from a given
port id, and free them first.
Re: [PATCH v2] app/testpmd : fix testpmd quit error
On 3/4/2022 2:37 AM, wenxuanx...@intel.com wrote:
From: wenxuan wu
When testpmd use func get_eth_dev_info() while related resource
had been released.
Is 'eth_dev_info_get_print_err()' fails at this stage?
What resource is released, the 'slave_port' itself?
And there may be another logic wrong, it shouldn't try
to detect if a released port is bonding port or not.
Change the logic of func port_is_bonding_slave, this func
eth_dev_info_get_print_err while pf is released would result
in this error. Use ports instead to avoid this bug.
This relies to application level stored value to decide about
port, not sure if this is reliable.
Fixes: 0a0821bcf312 ("app/testpmd: remove most uses of internal ethdev array")
Cc: sta...@dpdk.org
Signed-off-by: wenxuan wu
---
app/test-pmd/testpmd.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index e1da961311..37038c9183 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3824,19 +3824,9 @@ void clear_port_slave_flag(portid_t slave_pid)
uint8_t port_is_bonding_slave(portid_t slave_pid)
{
struct rte_port *port;
- struct rte_eth_dev_info dev_info;
- int ret;
port = &ports[slave_pid];
- ret = eth_dev_info_get_print_err(slave_pid, &dev_info);
- if (ret != 0) {
- TESTPMD_LOG(ERR,
- "Failed to get device info for port id %d,"
- "cannot determine if the port is a bonded slave",
- slave_pid);
- return 0;
- }
- if ((*dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) ||
(port->slave_flag == 1))
+ if ((*port->dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) ||
(port->slave_flag == 1))
return 1;
return 0;
}
Re: [PATCH] net/tap: do not include l2 header in gso size when compared with mtu
On 2/28/2022 8:27 AM, Harold Huang wrote:
The gso size is calculated with all of the headers and payload. As a
result, the l2 header should not be included when comparing gso size
with mtu.
Fixes: 050316a88313 ("net/tap: support TSO (TCP Segment Offload)")
Cc: sta...@dpdk.org
Signed-off-by: Harold Huang
---
drivers/net/tap/rte_eth_tap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index f1b48cae82..2b561d232c 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -731,7 +731,7 @@ pmd_tx_burst(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
mbuf_in->l4_len;
tso_segsz = mbuf_in->tso_segsz + hdrs_len;
if (unlikely(tso_segsz == hdrs_len) ||
- tso_segsz > *txq->mtu) {
+ tso_segsz > *txq->mtu + mbuf_in->l2_len) {
txq->stats.errs++;
break;
}
update emails for Ophir & Raslan.
Hi Ophir, since original code is from you can you please
help on review?
Re: [PATCH] app/testpmd: fix issue with memory leaks when quit testpmd
On 3/1/2022 2:06 AM, Ke Zhang wrote:
when dpdk is compiled in ASan, there is a memory leaks after
quit testpmd if set mcast_addr, this patch fix this issue.
Error info as following:
ERROR: LeakSanitizer: detected memory leaksDirect leak of
192 byte(s)
0 0x7f6a2e0aeffe in __interceptor_realloc
(/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
1 0x565361eb340f in mcast_addr_pool_extend
../app/test-pmd/config.c:5162
2 0x565361eb3556 in mcast_addr_pool_append
../app/test-pmd/config.c:5180
3 0x565361eb3aae in mcast_addr_add
../app/test-pmd/config.c:5243
Signed-off-by: Ke Zhang
---
app/test-pmd/testpmd.c | 12
1 file changed, 12 insertions(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index fe2ce19f99..fa7f80fdf7 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2742,6 +2742,8 @@ start_port(portid_t pid)
continue;
}
+ port->mc_addr_pool = NULL;
+
User can do consecutive start / stop / start / ..
Won't user expect the previous allocated and set MAC address
to be valid after this?
What about to free the 'port->mc_addr_pool' in close()
instead of stop()?
if (port->need_reconfig > 0) {
struct rte_eth_conf dev_conf;
int k;
@@ -3065,6 +3067,16 @@ stop_port(portid_t pid)
if (eth_dev_stop_mp(pi) != 0)
RTE_LOG(ERR, EAL, "rte_eth_dev_stop failed for port
%u\n",
pi);
+ /*
+* free the pool of multicast addresses. If it is NULL,
+* it means there is no mc addr.Make sure the mc_addr_pool
+* is NULL at port init.
+*/
+ if (port->mc_addr_pool != NULL) {
+ free(port->mc_addr_pool);
+ port->mc_addr_pool = NULL;
+ }
+ port->mc_addr_nb = 0;
will it work to use 'port->mc_addr_nb' to detect if the
'port->mc_addr_pool' pointer is valid
if (port->mc_addr_nb) {
free(port->mc_addr_pool);
port->mc_addr_pool = NULL;
port->mc_addr_nb = 0;
}
if (port->port_status == RTE_PORT_HANDLING)
port->port_status = RTE_PORT_STOPPED;
Re: [RFC] ethdev: introduce protocol type based header split
On Fri, 4 Mar 2022 09:58:11 +
"Zhang, Qi Z" wrote:
> > -Original Message-
> > From: Stephen Hemminger
> > Sent: Friday, March 4, 2022 12:16 AM
> > To: Ding, Xuan
> > Cc: tho...@monjalon.net; Yigit, Ferruh ;
> > andrew.rybche...@oktetlabs.ru; dev@dpdk.org; viachesl...@nvidia.com;
> > Zhang, Qi Z ; Yu, Ping ; Wang,
> > YuanX
> > Subject: Re: [RFC] ethdev: introduce protocol type based header split
> >
> > On Thu, 3 Mar 2022 06:01:36 +
> > xuan.d...@intel.com wrote:
> >
> > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > > c2d1f9a972..6743648c22 100644
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split {
> > > struct rte_mempool *mp; /**< Memory pool to allocate segment from.
> > */
> > > uint16_t length; /**< Segment data length, configures split point. */
> > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> > > - uint32_t reserved; /**< Reserved field. */
> > > + uint16_t proto;
> > > + uint16_t reserved; /**< Reserved field. */
> > > };
> >
> > This feature suffers from a common bad design pattern.
> > You can't just start using reserved fields unless the previous versions
> > enforced
> > that the field was a particular value (usually zero).
>
> Yes, agree, that's a mistake there is no document for the reserved field in
> the previous release, and usually, it should be zero,
> And I think one of the typical purposes of the reserved field is to make life
> easy for new feature adding without breaking ABI.
> So, should we just take the risk as I guess it might not be a big deal in
> real cases?
There is a cost/benefit tradeoff here. Although HW vendors would like to enable
more features, it really is not that much of an impact to wait until next LTS
for users.
Yes, the API/ABI rules are restrictive, but IMHO it is about learning how to
handle SW upgrades in a more user friendly manner. It was hard for the Linux
kernel to learn how to do this, but after 10 years they mostly have it right.
If this were a bug (especially a security bug), then the rules could be lifted.
[PATCH 1/3] port: support packet mirroring
Add packet clone operation to the output ports in order to support
packet mirroring.
Signed-off-by: Cristian Dumitrescu
---
lib/pipeline/rte_swx_pipeline.c | 2 ++
lib/pipeline/rte_swx_pipeline_internal.h | 1 +
lib/port/rte_swx_port.h | 15 ++
lib/port/rte_swx_port_ethdev.c | 29
lib/port/rte_swx_port_fd.c | 29
lib/port/rte_swx_port_ring.c | 28 +++
lib/port/rte_swx_port_source_sink.c | 35
7 files changed, 139 insertions(+)
diff --git a/lib/pipeline/rte_swx_pipeline.c b/lib/pipeline/rte_swx_pipeline.c
index 8c4670e111..bde20c5660 100644
--- a/lib/pipeline/rte_swx_pipeline.c
+++ b/lib/pipeline/rte_swx_pipeline.c
@@ -423,6 +423,7 @@ rte_swx_pipeline_port_out_type_register(struct
rte_swx_pipeline *p,
CHECK(ops->create, EINVAL);
CHECK(ops->free, EINVAL);
CHECK(ops->pkt_tx, EINVAL);
+ CHECK(ops->pkt_clone_tx, EINVAL);
CHECK(ops->stats_read, EINVAL);
CHECK(!port_out_type_find(p, name), EEXIST);
@@ -509,6 +510,7 @@ port_out_build(struct rte_swx_pipeline *p)
struct port_out_runtime *out = &p->out[port->id];
out->pkt_tx = port->type->ops.pkt_tx;
+ out->pkt_clone_tx = port->type->ops.pkt_clone_tx;
out->flush = port->type->ops.flush;
out->obj = port->obj;
}
diff --git a/lib/pipeline/rte_swx_pipeline_internal.h
b/lib/pipeline/rte_swx_pipeline_internal.h
index da3e88bfa8..6ccd9948fa 100644
--- a/lib/pipeline/rte_swx_pipeline_internal.h
+++ b/lib/pipeline/rte_swx_pipeline_internal.h
@@ -104,6 +104,7 @@ TAILQ_HEAD(port_out_tailq, port_out);
struct port_out_runtime {
rte_swx_port_out_pkt_tx_t pkt_tx;
+ rte_swx_port_out_pkt_clone_tx_t pkt_clone_tx;
rte_swx_port_out_flush_t flush;
void *obj;
};
diff --git a/lib/port/rte_swx_port.h b/lib/port/rte_swx_port.h
index ecf109d2ca..e305a580fe 100644
--- a/lib/port/rte_swx_port.h
+++ b/lib/port/rte_swx_port.h
@@ -147,6 +147,18 @@ typedef void
(*rte_swx_port_out_pkt_tx_t)(void *port,
struct rte_swx_pkt *pkt);
+/**
+ * Output port packet clone and transmit
+ *
+ * @param[in] port
+ * Output port handle.
+ * @param[in] pkt
+ * Packet to be transmitted.
+ */
+typedef void
+(*rte_swx_port_out_pkt_clone_tx_t)(void *port,
+ struct rte_swx_pkt *pkt);
+
/**
* Output port flush
*
@@ -188,6 +200,9 @@ struct rte_swx_port_out_ops {
/** Packet transmission. Must be non-NULL. */
rte_swx_port_out_pkt_tx_t pkt_tx;
+ /** Packet clone transmission. Must be non-NULL. */
+ rte_swx_port_out_pkt_clone_tx_t pkt_clone_tx;
+
/** Flush. May be NULL. */
rte_swx_port_out_flush_t flush;
diff --git a/lib/port/rte_swx_port_ethdev.c b/lib/port/rte_swx_port_ethdev.c
index 18d1c0b5db..a9101e805d 100644
--- a/lib/port/rte_swx_port_ethdev.c
+++ b/lib/port/rte_swx_port_ethdev.c
@@ -264,6 +264,34 @@ writer_pkt_tx(void *port, struct rte_swx_pkt *pkt)
__writer_flush(p);
}
+static void
+writer_pkt_clone_tx(void *port, struct rte_swx_pkt *pkt)
+{
+ struct writer *p = port;
+ struct rte_mbuf *m = pkt->handle;
+
+ TRACE("[Ethdev TX port %u queue %u] Pkt %d (%u bytes at offset %u)
(clone)\n",
+ (uint32_t)p->params.port_id,
+ (uint32_t)p->params.queue_id,
+ p->n_pkts - 1,
+ pkt->length,
+ pkt->offset);
+ if (TRACE_LEVEL)
+ rte_hexdump(stdout, NULL, &pkt->pkt[pkt->offset], pkt->length);
+
+ m->pkt_len = pkt->length;
+ m->data_len = (uint16_t)pkt->length;
+ m->data_off = (uint16_t)pkt->offset;
+ rte_mbuf_refcnt_update(m, 1);
+
+ p->stats.n_pkts++;
+ p->stats.n_bytes += pkt->length;
+
+ p->pkts[p->n_pkts++] = m;
+ if (p->n_pkts == (int)p->params.burst_size)
+ __writer_flush(p);
+}
+
static void
writer_flush(void *port)
{
@@ -308,6 +336,7 @@ struct rte_swx_port_out_ops rte_swx_port_ethdev_writer_ops
= {
.create = writer_create,
.free = writer_free,
.pkt_tx = writer_pkt_tx,
+ .pkt_clone_tx = writer_pkt_clone_tx,
.flush = writer_flush,
.stats_read = writer_stats_read,
};
diff --git a/lib/port/rte_swx_port_fd.c b/lib/port/rte_swx_port_fd.c
index 51bcd3bb7b..1806772c04 100644
--- a/lib/port/rte_swx_port_fd.c
+++ b/lib/port/rte_swx_port_fd.c
@@ -249,6 +249,34 @@ writer_pkt_tx(void *port, struct rte_swx_pkt *pkt)
__writer_flush(p);
}
+static void
+writer_pkt_clone_tx(void *port, struct rte_swx_pkt *pkt)
+{
+ struct writer *p = port;
+ struct rte_mbuf *m = pkt->handle;
+
+ TRACE("[FD %u] Pkt %u (%u bytes at offset %u) (clone)\n",
+ (uint32_t)p->params.fd,
+ p->n_pkts - 1,
+ pkt->leng
[PATCH 2/3] pipeline: support packet mirroring
The packet mirroring is configured through slots and sessions, with
the number of slots and sessions set at init.
The new "mirror" instruction assigns one of the existing sessions to a
specific slot, which results in scheduling a mirror operation for the
current packet to be executed later at the time the packet is either
transmitted or dropped.
Several copies of the same input packet can be mirrored to different
output ports by using multiple slots.
Signed-off-by: Cristian Dumitrescu
---
lib/pipeline/rte_swx_ctl.h | 36 +
lib/pipeline/rte_swx_pipeline.c | 192 +++
lib/pipeline/rte_swx_pipeline.h | 30
lib/pipeline/rte_swx_pipeline_internal.h | 68
lib/pipeline/version.map | 2 +
5 files changed, 328 insertions(+)
diff --git a/lib/pipeline/rte_swx_ctl.h b/lib/pipeline/rte_swx_ctl.h
index ed752ad5eb..71dd19e16f 100644
--- a/lib/pipeline/rte_swx_ctl.h
+++ b/lib/pipeline/rte_swx_ctl.h
@@ -41,6 +41,12 @@ struct rte_swx_ctl_pipeline_info {
/** Number of input ports. */
uint32_t n_ports_out;
+ /** Number of packet mirroring slots. */
+ uint32_t n_mirroring_slots;
+
+ /** Number of packet mirroring sessions. */
+ uint32_t n_mirroring_sessions;
+
/** Number of actions. */
uint32_t n_actions;
@@ -655,6 +661,36 @@ rte_swx_ctl_pipeline_learner_stats_read(struct
rte_swx_pipeline *p,
const char *learner_name,
struct rte_swx_learner_stats *stats);
+/*
+ * Packet mirroring API.
+ */
+
+/** Packet mirroring session parameters. */
+struct rte_swx_pipeline_mirroring_session_params {
+ /** Output port ID. */
+ uint32_t port_id;
+};
+
+/**
+ * Packet mirroring session set
+ *
+ * @param[in] p
+ * Pipeline handle.
+ * @param[in] session_id
+ * Packet mirroring session ID.
+ * @param[in] params
+ * Packet mirroring session parameters.
+ * @return
+ * 0 on success or the following error codes otherwise:
+ * -EINVAL: Invalid argument;
+ * -EEXIST: Pipeline was already built successfully.
+ */
+__rte_experimental
+int
+rte_swx_ctl_pipeline_mirroring_session_set(struct rte_swx_pipeline *p,
+ uint32_t session_id,
+ struct rte_swx_pipeline_mirroring_session_params *params);
+
/*
* Table Update API.
*/
diff --git a/lib/pipeline/rte_swx_pipeline.c b/lib/pipeline/rte_swx_pipeline.c
index bde20c5660..7cf6dd1fb6 100644
--- a/lib/pipeline/rte_swx_pipeline.c
+++ b/lib/pipeline/rte_swx_pipeline.c
@@ -556,6 +556,81 @@ port_out_free(struct rte_swx_pipeline *p)
}
}
+/*
+ * Packet mirroring.
+ */
+int
+rte_swx_pipeline_mirroring_config(struct rte_swx_pipeline *p,
+ struct rte_swx_pipeline_mirroring_params
*params)
+{
+ CHECK(p, EINVAL);
+ CHECK(params, EINVAL);
+ CHECK(params->n_slots, EINVAL);
+ CHECK(params->n_sessions, EINVAL);
+ CHECK(!p->build_done, EEXIST);
+
+ p->n_mirroring_slots = rte_align32pow2(params->n_slots);
+ if (p->n_mirroring_slots > 64)
+ p->n_mirroring_slots = 64;
+
+ p->n_mirroring_sessions = rte_align32pow2(params->n_sessions);
+
+ return 0;
+}
+
+static void
+mirroring_build_free(struct rte_swx_pipeline *p)
+{
+ uint32_t i;
+
+ for (i = 0; i < RTE_SWX_PIPELINE_THREADS_MAX; i++) {
+ struct thread *t = &p->threads[i];
+
+ /* mirroring_slots. */
+ free(t->mirroring_slots);
+ t->mirroring_slots = NULL;
+ }
+
+ /* mirroring_sessions. */
+ free(p->mirroring_sessions);
+ p->mirroring_sessions = NULL;
+}
+
+static void
+mirroring_free(struct rte_swx_pipeline *p)
+{
+ mirroring_build_free(p);
+}
+
+static int
+mirroring_build(struct rte_swx_pipeline *p)
+{
+ uint32_t i;
+
+ if (!p->n_mirroring_slots || !p->n_mirroring_sessions)
+ return 0;
+
+ for (i = 0; i < RTE_SWX_PIPELINE_THREADS_MAX; i++) {
+ struct thread *t = &p->threads[i];
+
+ /* mirroring_slots. */
+ t->mirroring_slots = calloc(p->n_mirroring_slots,
sizeof(uint32_t));
+ if (!t->mirroring_slots)
+ goto error;
+ }
+
+ /* mirroring_sessions. */
+ p->mirroring_sessions = calloc(p->n_mirroring_sessions, sizeof(struct
mirroring_session));
+ if (!p->mirroring_sessions)
+ goto error;
+
+ return 0;
+
+error:
+ mirroring_build_free(p);
+ return -ENOMEM;
+}
+
/*
* Extern object.
*/
@@ -1655,6 +1730,56 @@ instr_drop_exec(struct rte_swx_pipeline *p)
instr_rx_exec(p);
}
+/*
+ * mirror.
+ */
+static int
+instr_mirror_translate(struct rte_swx_pipeline *p,
+ struct action *action,
+ char **tokens,
+ int n_tokens,
+ struct instruction *instr,
+
[PATCH 3/3] examples/pipeline: support packet mirroring
Add CLI commands for packet mirroring.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Yogesh Jangra
---
examples/pipeline/cli.c | 154
1 file changed, 154 insertions(+)
diff --git a/examples/pipeline/cli.c b/examples/pipeline/cli.c
index edae63dae6..e983cdd21d 100644
--- a/examples/pipeline/cli.c
+++ b/examples/pipeline/cli.c
@@ -2697,6 +2697,131 @@ cmd_pipeline_stats(char **tokens,
}
}
+static const char cmd_pipeline_mirror_help[] =
+"pipeline mirror slots sessions \n";
+
+static void
+cmd_pipeline_mirror(char **tokens,
+ uint32_t n_tokens,
+ char *out,
+ size_t out_size,
+ void *obj)
+{
+ struct rte_swx_pipeline_mirroring_params params;
+ struct pipeline *p;
+ int status;
+
+ if (n_tokens != 7) {
+ snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
+ return;
+ }
+
+ if (strcmp(tokens[0], "pipeline")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "pipeline");
+ return;
+ }
+
+ p = pipeline_find(obj, tokens[1]);
+ if (!p) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "pipeline_name");
+ return;
+ }
+
+ if (strcmp(tokens[2], "mirror")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "mirror");
+ return;
+ }
+
+ if (strcmp(tokens[3], "slots")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "slots");
+ return;
+ }
+
+ if (parser_read_uint32(¶ms.n_slots, tokens[4])) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "n_slots");
+ return;
+ }
+
+ if (strcmp(tokens[5], "sessions")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "sessions");
+ return;
+ }
+
+ if (parser_read_uint32(¶ms.n_sessions, tokens[6])) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "n_sessions");
+ return;
+ }
+
+ status = rte_swx_pipeline_mirroring_config(p->p, ¶ms);
+ if (status) {
+ snprintf(out, out_size, "Command failed!\n");
+ return;
+ }
+}
+
+static const char cmd_pipeline_mirror_session_help[] =
+"pipeline mirror session port \n";
+
+static void
+cmd_pipeline_mirror_session(char **tokens,
+ uint32_t n_tokens,
+ char *out,
+ size_t out_size,
+ void *obj)
+{
+ struct rte_swx_pipeline_mirroring_session_params params;
+ struct pipeline *p;
+ uint32_t session_id;
+ int status;
+
+ if (n_tokens != 7) {
+ snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
+ return;
+ }
+
+ if (strcmp(tokens[0], "pipeline")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "pipeline");
+ return;
+ }
+
+ p = pipeline_find(obj, tokens[1]);
+ if (!p || !p->ctl) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "pipeline_name");
+ return;
+ }
+
+ if (strcmp(tokens[2], "mirror")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "mirror");
+ return;
+ }
+
+ if (strcmp(tokens[3], "session")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "session");
+ return;
+ }
+
+ if (parser_read_uint32(&session_id, tokens[4])) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "session_id");
+ return;
+ }
+
+ if (strcmp(tokens[5], "port")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND, "port");
+ return;
+ }
+
+ if (parser_read_uint32(¶ms.port_id, tokens[6])) {
+ snprintf(out, out_size, MSG_ARG_INVALID, "port_id");
+ return;
+ }
+
+ status = rte_swx_ctl_pipeline_mirroring_session_set(p->p, session_id,
¶ms);
+ if (status) {
+ snprintf(out, out_size, "Command failed!\n");
+ return;
+ }
+}
+
static const char cmd_thread_pipeline_enable_help[] =
"thread pipeline enable\n";
@@ -2837,6 +2962,8 @@ cmd_help(char **tokens,
"\tpipeline meter set\n"
"\tpipeline meter stats\n"
"\tpipeline stats\n"
+ "\tpipeline mirror\n"
+ "\tpipeline mirror session\n"
"\tthread pipeline enable\n"
"\tthread pipeline disable\n\n");
return;
@@ -3056,6 +3183,19 @@ cmd_help(char **tokens,
return;
}
+ if (!strcmp(tokens[0], "pipeline") &&
+ (n_tokens == 2) && !strcmp(tokens[1], "mirror")) {
+ snprintf(out, out_size, "\n%s\n", cmd_pipeline_mirror_help);
+ return;
+ }
+
+ if (!strcmp(tokens[0], "pipeline") &&
+ (n_tokens == 3) && !strcmp(tokens[1], "mirror")
+
regarding Intel E810
Hi All, I am using Intel E810 with DPDK v20.11, with ethernet ports bound to DPDK(vfio-pci). Running DPDK software libraries within a secure-enclave(Intel SGX technology) sandbox environment, and running into an issue during rte_eal_init invocation. During launch of DPDK application(examples/packet_ordering), when rte_eal_init gets called, it results in a probe of ethernet devices,which invokes ICE(Intel E810 NIC) Poll-Mode-Driver(PMD) apis. When ICE PMD driver sends command to NIC(Network Interface Card),to get firmware version, it times out in this api-> ice_sq_send_cmd_nolock(). Question-> Can someone point me to any Intel documentation for E810, that describes how ICE PMD(or any software driver) can communicate with E810 NIC's firmware, like what registers to write the command, and how to check for the response from firmware. Question-> Also, is there any other alternate way(other than ethtool), to check if firmware received the command, and what was the status of the last command processed by firmware. Note: Even if there is a way to check firmware command status thro ethtool, I cant use ethtool,since ports are bound to DPDK. Thanks, Sudha
IXGBE LSC IRQ issue
Hello, We recently ran into an issue with DPDK 20.11 for the IXGBE driver operating in 10G BASE-T mode. We have been able to replicate this behavior using dpdk-testpmd and do not see any recent/pertinent updates, so we are hopeful someone may be able to advise based on the information provided below. On the surface, based on our investigation, it would appear the current link-down transition logic does not correctly preserve IRQ mask configurations, specifically LSC, when a link partner causes some sort of slow or bounced link down event. Background: We recently started using a new 3rd party traffic generator card for testing our application. We found when using this card in 10G BASE-T mode and toggling link up/down, it would correctly cause our application to detect the port to be down in our DPDK design. However, the link down event handling by the DPDK IXGBE driver appears to permanently disable its LSC IRQ detection on the first port down event such that any subsequent link up or down events from the external test card on this port would no longer be detected. The only way to restore link up was to restart the DPDK port in our design (stop/start). Having looked at this a bit, we switched over to the classic testpmd application and observed the exact same behavior. Here is the data we believe you would find interesting: NIC in question: # lspci -D -nn | grep -F [0200] | grep 552 :03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T [8086:15ad] :03:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T [8086:15ad] # dpdk-devbind.py -s | grep 552 :03:00.0 'Ethernet Connection X552/X557-AT 10GBASE-T 15ad' drv=vfio-pci unused=uio_pci_generic :03:00.1 'Ethernet Connection X552/X557-AT 10GBASE-T 15ad' drv=vfio-pci unused=uio_pci_generic We made the following debug logging changes to try an capture interesting data to share: diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index 5a30c39593..75a9f9163b 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -4497,7 +4497,7 @@ ixgbe_dev_interrupt_get_status(struct rte_eth_dev *dev) /* read-on-clear nic registers here */ eicr = IXGBE_READ_REG(hw, IXGBE_EICR); -PMD_DRV_LOG(DEBUG, "eicr %x", eicr); +PMD_DRV_LOG(ERR, "eicr %x", eicr); intr->flags = 0; @@ -4614,7 +4613,7 @@ ixgbe_dev_interrupt_action(struct rte_eth_dev *dev) } } -PMD_DRV_LOG(DEBUG, "enable intr immediately"); +PMD_DRV_LOG(ERR, "enable intr immediately, mask: 0x%08x, orig: 0x%08x, flags: 0x%08x", intr->mask, intr->mask_original, intr->flags); ixgbe_enable_intr(dev); return 0; @@ -4648,7 +4647,9 @@ ixgbe_dev_interrupt_delayed_handler(void *param) ixgbe_disable_intr(hw); -eicr = IXGBE_READ_REG(hw, IXGBE_EICR); + eicr = IXGBE_READ_REG(hw, IXGBE_EICR); + PMD_DRV_LOG(ERR, "in delay func: eicr 0x%08x", eicr); + PMD_DRV_LOG(ERR, "enable intr delayed, mask: 0x%08x, orig: 0x%08x, flags: 0x%08x", intr->mask, intr->mask_original, intr->flags); if (eicr & IXGBE_EICR_MAILBOX) ixgbe_pf_mbx_process(dev); With the above "log-err" additions, we have provided the following results. The first set of data below was generated using an older 3rd party traffic generator card to provide "good" results that show the IXGBE driver working correctly. Following that are the non-working (bad) logging results for the new traffic generator card. Both 3rd party cards correctly transition between down and up states. ## # good sequence, both down detection and then up detection ## # port transition from up to down <27>1 2022-03-05T00:12:11.415436+00:00 - - ixgbe_dev_interrupt_get_status(): eicr 10 <27>1 2022-03-05T00:12:11.415489+00:00 - - ixgbe_dev_interrupt_action(): enable intr immediately, mask: 0x0220, orig: 0x0230, flags: 0x0001 <27>1 2022-03-05T00:12:11.425448+00:00 - - ixgbe_dev_interrupt_get_status(): eicr 200 <27>1 2022-03-05T00:12:11.446191+00:00 - - ixgbe_dev_interrupt_action(): enable intr immediately, mask: 0x0220, orig: 0x0230, flags: 0x <27>1 2022-03-05T00:12:15.415600+00:00 - - ixgbe_dev_interrupt_delayed_handler(): in delay func: eicr 0x <27>1 2022-03-05T00:12:15.415655+00:00 - - ixgbe_dev_interrupt_delayed_handler(): enable intr delayed, mask: 0x0220, orig: 0x0230, flags: 0x # port transition from down to up <27>1 2022-03-05T00:12:33.856734+00:00 - - ixgbe_dev_interrupt_get_status(): eicr 200 <27>1 2022-03-05T00:12:33.877463+00:00 - - ixgbe_dev_interrupt_action(): enable intr immediately, mask: 0x0230, orig: 0x, flags: 0x <27>1 2022-03-05T00:12:34.203274+00:00 - - ixgbe_dev_interrupt_get_status(): eicr 1
[PATCH v2] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem: All mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated and are still sitting in the device's tx descriptor ring and other cores' mempool caches. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- v2: * Fixed compile issues. --- drivers/net/bonding/rte_eth_bond_8023ad.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..831c7dc6ab 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,6 +1101,9 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } + cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? + 32 : RTE_MEMPOOL_CACHE_MAX_SIZE; + total_tx_desc = rte_lcore_count() * cache_size * 1.5; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? -- 2.32.0
[PATCH v3] net/bonding: another fix to LACP mempool size
The following log message may appear after a slave is idle(or nearly idle) for a few minutes:"PMD: Failed to allocate LACP packet from pool". And bond mode 4 negotiation may fail. Problem: All mbufs from a slave' private pool(used exclusively for transmitting LACPDUs) have been allocated and are still sitting in the device's tx descriptor ring and other cores' mempool caches. Solution: Ensure that each slave'tx (LACPDU) mempool owns more than n-tx-queues * n-tx-descriptor + fwd_core_num * per-core-mmempool-flush-threshold mbufs. Note that the LACP tx machine fuction is the only code that allocates from a slave's private pool. It runs in the context of the interrupt thread, and thus it has no mempool cache of its own. Signed-off-by: Gaoxiang Liu --- v2: * Fixed compile issues. v3: * delete duplicate code. --- drivers/net/bonding/rte_eth_bond_8023ad.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index ca50583d62..d73038b018 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, uint32_t total_tx_desc; struct bond_tx_queue *bd_tx_q; uint16_t q_id; + uint32_t cache_size; /* Given slave mus not be in active list */ RTE_ASSERT(find_slave_by_id(internals->active_slaves, @@ -1100,11 +1101,12 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, total_tx_desc += bd_tx_q->nb_tx_desc; } + cache_size = RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? + 32 : RTE_MEMPOOL_CACHE_MAX_SIZE; + total_tx_desc = rte_lcore_count() * cache_size * 1.5; snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, - 0, element_size, socket_id); + cache_size, 0, element_size, socket_id); /* Any memory allocation failure in initialization is critical because * resources can't be free, so reinitialization is impossible. */ -- 2.32.0
