From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 57395A0096 for ; Wed, 8 May 2019 15:04:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C533734F0; Wed, 8 May 2019 15:04:03 +0200 (CEST) Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by dpdk.org (Postfix) with ESMTP id 44D172C2B for ; Wed, 8 May 2019 15:04:02 +0200 (CEST) Received: by mail-lf1-f67.google.com with SMTP id w23so14469306lfc.9 for ; Wed, 08 May 2019 06:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C+oqzl2bOC8/3GUQyTCKNq3axxqSbY6Wr9tfz9klmtI=; b=rbplFfUnJikwtiUeMsm6+QoQa8Ya4ix1+hYnr49MeU00y7Np9UzOmCvaFZ5HYDxlfG WjqQUchtWajEvX2uDGXL0QiBahKCAJFmVdgaAvXR3Biw8699ucQ+9pVr6vgYu5DuiLjT +aIee2JKS9DslJ0juTkxunyVNsgBa5cJhPeLjuv3hCJMKXR1grcVHQUBjYXtcN270mom KJoBW9bIMDbrIzzNRqVsD9FQk1tfzZink1Hg3XcXM0i5+Di9GUAhOwWsT6FWHL4EhiRb Pn3ajbnQkho4hvAv2Neq3MyfyZnRaaL73hgyslCS5qq+yC1jyaPj/dfp643jNUNb2GJz BBbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C+oqzl2bOC8/3GUQyTCKNq3axxqSbY6Wr9tfz9klmtI=; b=d+086bymQIZE0Jxy95xPAxU5bhOWZqRAuJS1tRUI6YIKkX0SXNeDZZwssd+1+2+AiM fpaRqCJ6pKUPrjGNxb3qu3mET68J+S8hezs2Vn0GTuLmzp81kY2fS+XM/61TRC1K6UxM rna6fwfQRc92+/H5c21uuny3wUmCNPW446NgHgXDD+WgtuFs4IT4H8nIK1kEJRLj2jTf ImMdAneKd67NKKtcNXJTPvS0QyI2f29ymo1zrkCNtggusLlOQhv7CkLHg44OFwBmkWf2 Y0IoWu2K/yFOOA/UIPyOGCMHAkxnngMs74nFBGWIwaeYUW+Zwrny9YHTFY7cyZcJtd4i d57A== X-Gm-Message-State: APjAAAWWTJV4rTbQrAinsVQfVfoNjf7UFFDftWHZ85ziLtohbVHXb8+m r0rH8Q3OIf4zkTtAqFJUjBxP9k1gbd8yHbmoIv4= X-Google-Smtp-Source: APXvYqzS1UqdQqPy09RAwRIFbQFbkz1i6topTJHwSH5ASxGGSSbkuBwbKHwDhbk7Pf89JTogdMDZ7kGzXIHpomgedkA= X-Received: by 2002:a05:6512:309:: with SMTP id t9mr20025370lfp.103.1557320641664; Wed, 08 May 2019 06:04:01 -0700 (PDT) MIME-Version: 1.0 References: <1B492CED-5816-4A43-B7DD-4EFA4F58631D@mellanox.com> In-Reply-To: From: Arvind Narayanan Date: Wed, 8 May 2019 08:03:50 -0500 Message-ID: To: Andrew Bainbridge Cc: Yongseok Koh , users Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Issue with mlx5_rxtx.c while calling rte_eth_tx_burst() in DPDK 18.11 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" I will try using testpmd, and get back. Thanks. Since my packets are single segment, as Yongseok suggested - I tried commenting out the asserts. By doing this, the tx descriptors would get depleted and would halt all tx completely. But if packets are sent slowly by reducing traffic-generator's transmission speed, there is no problem. What does "vectorized TX bursts" mean? Does executing consecutive tx_burst calls (where each call is sending out ~64 mbufs) qualify as vectorized tx burst? I tried finding information about this online, but couldn't find anything useful. I see a bunch of runtime config params for vectorized tx in mlx5. Arvind On Wed, May 8, 2019 at 4:26 AM Andrew Bainbridge wrote: > testpmd calls rte_eth_tx_burst() in a loop. Does it fail? I suspect not. > If not, then you can gradually transform testpmd until it looks like your > code that fails. The loop in question is in txonly.c. > > You need a command line something like this for the test: > testpmd -- --forward-mode=txonly --stats-period 1 > > -----Original Message----- > From: users On Behalf Of Arvind Narayanan > Sent: 05 May 2019 00:07 > To: Yongseok Koh > Cc: users > Subject: Re: [dpdk-users] Issue with mlx5_rxtx.c while calling > rte_eth_tx_burst() in DPDK 18.11 > > It passes __rte_mbuf_sanity_check. rte_mbuf_check() is not available in > dpdk 18.02. > I debugged when the assertion failed and double checked all the mbuf's > pkt_len and data_len. All seems fine. > Yes, in my case its simple, all mbufs are single segment. > > Is there some bound on the number of tx calls we can do consecutively using > mlx5 driver? > Its like if I do a lot of tx calls consecutively (e.g. ~10 to 20 calls to > rte_eth_tx_burst() with each call sending out a burst of ~64 mbufs), I > face this problem otherwise I don't. > > Thoughts? > > Arvind > > On Tue, Apr 23, 2019 at 6:45 PM Yongseok Koh wrote: > > > > > > On Apr 21, 2019, at 9:59 PM, Arvind Narayanan > > > > > wrote: > > > > > > I am running into a weird problem when using rte_eth_tx_burst() > > > using > > mlx5 > > > in dpdk 18.11, running on Ubuntu 18.04 LTS (using Mellanox Connect > > > X5 > > 100G > > > EN). > > > > > > Here is a simplified snippet. > > > > > > ================== > > > #define MAX_BATCHES 64 > > > #define MAX_BURST_SIZE 64 > > > > > > struct batch { > > > struct rte_mbuf *mbufs[MAX_BURST_SIZE]; // array of packets > > > int num_mbufs; // num of mbufs > > > int queue; // outgoing tx_queue > > > int port; // outgoing port > > > } > > > > > > struct batch * batches[MAX_BATCHES]; > > > > > > /* dequeue a number of batches */ > > > int batch_count = rte_ring_sc_dequeue_bulk(some_rte_ring, (void **) > > > &(batches), MAX_BATCHES, NULL); > > > > > > /* transmit out all pkts from every batch */ if (likely(batch_count > > > > 0)) { > > > for (i = 0; i < batch_count; i++) { > > > ret = rte_eth_tx_burst(batches[i]->port, batches[i]->queue, > > (struct > > > rte_mbuf **) batches[i]->mbufs, > > > batches[i]->num_mbufs); > > > } > > > } > > > > > > ================== > > > > > > At rte_eth_tx_burst(), I keep getting an error saying: > > > myapp: /home/arvind/dpdk/drivers/net/mlx5/mlx5_rxtx.c:1652: uint16_t > > > txq_burst_empw(struct mlx5_txq_data *, struct rte_mbuf **, uint16_t): > > > Assertion `length == DATA_LEN(buf)' failed. > > > OR > > > myapp: /home/arvind/dpdk/drivers/net/mlx5/mlx5_rxtx.c:1609: uint16_t > > > txq_burst_empw(struct mlx5_txq_data *, struct rte_mbuf **, uint16_t): > > > Assertion `length == DATA_LEN(buf)' failed. > > > > > > I have debugged and ensured all the mbuf counts (at least in my > > > code) are good. All the memory references to the mbufs also look > > > good. However, I > > am > > > not sure why Mellanox driver would complain. > > > > > > I have also tried to play with mlx5_rxtx.c by changing above lines > > > to something like assert(length == pkts_n); // pkts_n is an argument > > > passed to the func. > > > Didn't help. > > > > > > Any thoughts? > > > > Hi, > > > > Does your mbuf pass rte_mbuf_check()? > > That complaint is regarding mismatch between m->pkt_len and m->data_len. > > If the mbuf is single segment packet (m->nb_segs == 1, m->next == > > NULL), > > m->pkt_len should be same as m->data_len. > > > > That assert() ins't strictly needed in the txq_burst_empw() though. > > > > > > Thanks, > > Yongseok >