From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 1E09AA00C2
for <public@inbox.dpdk.org>; Mon, 26 Sep 2022 17:36:19 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id D61BE41133;
Mon, 26 Sep 2022 17:36:18 +0200 (CEST)
Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com
[209.85.219.180])
by mails.dpdk.org (Postfix) with ESMTP id ACFC34014F
for <users@dpdk.org>; Mon, 26 Sep 2022 17:36:17 +0200 (CEST)
Received: by mail-yb1-f180.google.com with SMTP id p69so8955711yba.0
for <users@dpdk.org>; Mon, 26 Sep 2022 08:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date;
bh=FXGxfJA4Op60nK9S/fdctR3w+EDXVlH8hOwfNYppoRM=;
b=A4rh6el6d0fk4wBJgJaZu0T4f6UcZDk5yz10pEchicDEmthTxVzvyVBztpvV52UN/7
mFouaz8ZHn1iq6XSVMrRoJJv1nUvKSvWO0p4abHz2aseHZpLlpymo+AdRhtapSp3ZaVZ
Ndo0NmBgQ7rGFmi2ckYXxtpmUjqpZbb1BweYz8pczef+zgbegsfk1gqfqRcTpMwuhX9F
n2T4SGDJG1wL12dpbLNu/95JWtWMoIPH9i6nXnaLT07t4XD7xuHGgcXdFoQ3LFbBVidK
/M17rkN+ABia6SQGwPYaVv9D5rwgPGK6cKE3sb62F4JyaF+rqmJ0VZo88W9fVzDwditt
mhfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date;
bh=FXGxfJA4Op60nK9S/fdctR3w+EDXVlH8hOwfNYppoRM=;
b=VzEkZMPUdhEzG2I30/0g8Vciu315TPEWGtdg5cxbHPf0ZuOwfjlKwiEEfpUjUB1CSg
al4TkhUQq1nfoVJ9Ed0+YngPnNvHl6KNNk1zjof3t4bl6pey6aHoVp4DA1DuMfBMNFcZ
43i47RNMHl1iBA2zv2orXfPFjKlWs0W+aJmENcKxc01Y3zPphCJENiNAsmhDJJ4Izm4u
1dM+2JZEM2lfVkxg51Ayv6K3TlHZl0t+/38Stmep/VOOKbXvCQwmRO9pGqkWJelNN6W4
K04BOsdpmMm+iWxuWXYYT1FBfHC8RDVs0jbOa0wjiJ7nVdr4KQqD+tSCIhnW7d+nCvxY
lHVw==
X-Gm-Message-State: ACrzQf1uaCtGQ1m1cbgKpfqMM2k6IqZ5MMStIfrw3UIAmAOIZi5BW5Uu
RlOyYmmMoAWxvk2ycUL8PXYahAD4CG1QR9AaYvo=
X-Google-Smtp-Source: AMsMyM44WPCeffopzlix2nBUErLTL91x2cxAPd4w5nnYBNqM2ccDPH4EinLHLcsMh6D6xAycNREXl4fQQNyLEKPF7lA=
X-Received: by 2002:a25:7e84:0:b0:6ae:c1d6:4346 with SMTP id
z126-20020a257e84000000b006aec1d64346mr21579652ybc.575.1664206577061; Mon, 26
Sep 2022 08:36:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAO8pfFnMXA71rweMs6j4eK3w0trkWqxHfe9Ek1kDT55v7r1MKQ@mail.gmail.com>
<2ca6fffa-05df-9882-34e9-6c13dc2cc28f@hit.bme.hu>
<CAO8pfFmv=f9+fGq26Vt5+t6WnaRV3YXu10_F=7mBoj50AphpdQ@mail.gmail.com>
<20220706080001.38ae3781@hermes.local>
<CAO8pfFmU4RDLo8cBPfRm_=UV+PommPij8uOUVLiFzHB8u6op8w@mail.gmail.com>
In-Reply-To: <CAO8pfFmU4RDLo8cBPfRm_=UV+PommPij8uOUVLiFzHB8u6op8w@mail.gmail.com>
From: Antonio Di Bacco <a.dibacco.ks@gmail.com>
Date: Mon, 26 Sep 2022 17:36:06 +0200
Message-ID: <CAO8pfFkmzbYrPLRnbEh8iqM8WCL_Y_8xYhB8e3XH_+GJyW+k8g@mail.gmail.com>
Subject: Re: rte_eth_tx_burst() always returns 0 in tight loop
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: =?UTF-8?Q?G=C3=A1bor_LENCSE?= <lencse@hit.bme.hu>, users@dpdk.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
<mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
<mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org
Is there any way to check if a TX queue is full before transmitting
using the rte_eth_rx_burst() or should I rely on the return value of
rte_eth_tx_burst()?
On Thu, Jul 7, 2022 at 4:30 PM Antonio Di Bacco <a.dibacco.ks@gmail.com> wr=
ote:
>
> I have an E810-C card with iavf-4.4.2.1 ice-1.8.8 drivers.
>
> My tx_free_threshold is 8 together with tx_rs_thresh.
>
> I have a tight loop sending BURSTs of 8 packets, each packet is 9014
> bytes long (8 packets take 6 usecs to be serialized).
> If I put the rte_delay_us_block to 7 then everything works fine, every
> cycle 8 packets are transmitted.
> If I lower the rte_delay_us_block to 1 usec, then I observe that the
> first FOR cycle is ok, nb_tx is 8 as expected, then, the second cycle
> prints a 7 while all subsequent cycles print Z (zero packets sent). I
> know that 1 usec delay is too small and I expect that no packets are
> transmitted for some cycles but I don't understand why I get an nb_tx
> set to 0 forever after the first two cycles.
>
> for (;;)
> {
> rte_spinlock_lock(&spinlock_conf[src_port]) ;
> const uint16_t nb_tx =3D rte_eth_tx_burst(src_port, 0, tx_bufs,
> BURST_SIZE);
> rte_spinlock_unlock(&spinlock_conf[src_port]);
>
> rte_delay_us_block(7); // tested with 1
>
> if (nb_tx =3D=3D 0)
> printf("Z");
> else if (nb_tx < BURST_SIZE)
> printf("nb_tx %d\n", nb_tx);
>
> tx +=3D nb_tx;
>
> if (unlikely(nb_tx < BURST_SIZE)) {
> uint16_t buf;
>
> for (buf =3D nb_tx; buf < BURST_SIZE; buf++)
> rte_pktmbuf_free(tx_bufs[buf]);
> }
> }
>
> On Wed, Jul 6, 2022 at 5:00 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Wed, 6 Jul 2022 09:21:28 +0200
> > Antonio Di Bacco <a.dibacco.ks@gmail.com> wrote:
> >
> > > I wonder why calling eth_dev_tx_burst in a tight loop doesn't allow t=
o
> > > write the packets into the transmit buffer. Only solution I found is
> > > to include a small delay after the tx_burst that is less than the
> > > estimated serialization time of the packet in order to be able to
> > > saturate the ethernet line.
> > >
> > > Anyway I wonder if this is the right approach.
> > >
> > > Thx,
> > > Antonio.
> > >
> > > On Sun, Jul 3, 2022 at 10:19 PM G=C3=A1bor LENCSE <lencse@hit.bme.hu>=
wrote:
> > > >
> > > > Dear Antonio,
> > > >
> > > > According to my experience, the rte_eth_tx_burst() function reports=
the
> > > > packets as "sent" (by a non-zero return value), when they are still=
in
> > > > the transmit buffer.
> > > >
> > > > (If you are interested in the details, you can see them in Section =
3.6.5
> > > > of this paper: http://www.hit.bme.hu/~lencse/publications/e104-b_2_=
128.pdf )
> > > >
> > > > Therefore, I think that the return value of 0 may mean that
> > > > rte_eth_tx_burst() can't even commit itself for the future delivery=
of
> > > > the packets. I could only guess why. E.g. all its resources have be=
en
> > > > exhausted.
> > > >
> > > > Best regards,
> > > >
> > > > G=C3=A1bor
> > > >
> > > >
> > > > 7/3/2022 5:57 PM keltez=C3=A9ssel, Antonio Di Bacco =C3=ADrta:
> > > > > I'm trying to send packets continuously in a tight loop with a b=
urst
> > > > > size of 8 and packets are 9600 bytes long.
> > > > > If I don't insert a delay after the rte_eth_tx_burst it always re=
turns 0.
> > > > >
> > > > > What's the explanation of this behaviour ?
> > > > >
> > > > > Best regards,
> > > > > Antonio.
> > > >
> >
> > Which driver? How did you set the tx_free threshold.
> > The driver will need to cleanup already transmitted packets.