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 2E6D8A0543 for ; Thu, 7 Jul 2022 16:31:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F35CD406B4; Thu, 7 Jul 2022 16:30:59 +0200 (CEST) Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com [209.85.160.44]) by mails.dpdk.org (Postfix) with ESMTP id 6EB904069D for ; Thu, 7 Jul 2022 16:30:58 +0200 (CEST) Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-f2a4c51c45so25501043fac.9 for ; Thu, 07 Jul 2022 07:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YlmWCk/Y4pWCGlWG5qu5ktQNX3/ZTrfOfWbg4bEqfh4=; b=AVxPLgiCPALkoUbbVXJvShlix4tlq9L/LbkPHLxwhprMVYt18BxG44l2a2kaWMolnB UVT+5otDv+ubD47R6rL5CZy5KnPwuRzzJorLY0HQQ5fOnTTo9DYdllS5THMcgTGtSaGP GXdRqqrBf/Xi+kGxwQid+5WNtZtDtRQVLZgXJvefQIKBsex/xI3T/IjqBa6FR/Kxn+45 1hJYmrYXQPERmmmVScL5O17fmeVieZrjGglDQaGCh5855Vk+Ki0wwXt8KxYCA7yGw3JH ey3qVNRL0bEL1QmRML9nqsWkqIdEhNe+Vp5Q0YVw3AA2Rjr3ruSgCHWqaWzcf6vZ8m20 mZzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YlmWCk/Y4pWCGlWG5qu5ktQNX3/ZTrfOfWbg4bEqfh4=; b=ZH+jQxihuAeQUij4DU0TMmEGqLm81vpvVQ9A1hg0h3QkTD/+HSVfZuyLCaWPEHGBME 6khnYuxO7bcNYIJvva49OCqVNaP2FI9K0vR+fOHBNcFt/rhMYTRcGG56HgAVv32oxQgC HUolcdXHNgeCwsYgHrNZbNKHVJ//qLhjYN4qp/EEUhJE12T/X0iwCkEoZRatMkcwsdWV wrQ9hKl9qpxZn2hlvTnwcJyYdrLfdYafiORlJfnsq7nL4PvDsGTUDbReNmG3SAZKU5CM OoekcqQ5jcpkEZz20tR5eKoW2j9IlD+L2fH87Z6WqViy9wXpDuW6wACvmODqWLncSYZK ivPg== X-Gm-Message-State: AJIora/m/xGANMhS/o7nXRUA131bi7ifKx2lUUIdcmP5VCWgpNCLnfou VoZUkQPTY0cKmKwIhr39Vj6iJn4L1jey1tc+c/s= X-Google-Smtp-Source: AGRyM1sOfspm7DOjoTvKi7yX2+U+XDpjjrHGjkaM5k7LF7uP4eBnkqtynprkFbGjVwuNuE2h0NusOP6LYG1n5GD7lHg= X-Received: by 2002:a05:6870:f203:b0:108:4a52:da42 with SMTP id t3-20020a056870f20300b001084a52da42mr3011769oao.59.1657204257749; Thu, 07 Jul 2022 07:30:57 -0700 (PDT) MIME-Version: 1.0 References: <2ca6fffa-05df-9882-34e9-6c13dc2cc28f@hit.bme.hu> <20220706080001.38ae3781@hermes.local> In-Reply-To: <20220706080001.38ae3781@hermes.local> From: Antonio Di Bacco Date: Thu, 7 Jul 2022 16:30:46 +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 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 to > > 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 w= rote: > > > > > > Dear Antonio, > > > > > > According to my experience, the rte_eth_tx_burst() function reports t= he > > > packets as "sent" (by a non-zero return value), when they are still i= n > > > 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_12= 8.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 o= f > > > the packets. I could only guess why. E.g. all its resources have been > > > 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 bur= st > > > > size of 8 and packets are 9600 bytes long. > > > > If I don't insert a delay after the rte_eth_tx_burst it always retu= rns 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.