From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1E09AA00C2 for ; 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 ; Mon, 26 Sep 2022 17:36:17 +0200 (CEST) Received: by mail-yb1-f180.google.com with SMTP id p69so8955711yba.0 for ; 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: <2ca6fffa-05df-9882-34e9-6c13dc2cc28f@hit.bme.hu> <20220706080001.38ae3781@hermes.local> In-Reply-To: From: Antonio Di Bacco Date: Mon, 26 Sep 2022 17:36:06 +0200 Message-ID: Subject: Re: rte_eth_tx_burst() always returns 0 in tight loop To: Stephen Hemminger Cc: =?UTF-8?Q?G=C3=A1bor_LENCSE?= , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > wrote: > > > > On Wed, 6 Jul 2022 09:21:28 +0200 > > Antonio Di Bacco 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 = 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.