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 55CC9A0540 for ; Wed, 6 Jul 2022 17:00:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D5FFB40687; Wed, 6 Jul 2022 17:00:05 +0200 (CEST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id 18C4B40156 for ; Wed, 6 Jul 2022 17:00:05 +0200 (CEST) Received: by mail-pf1-f178.google.com with SMTP id l124so4213869pfl.8 for ; Wed, 06 Jul 2022 08:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wU2RncwftWiMVrhtQfpZAug+I4e5eivD8KoFYpsu0i0=; b=Amo/gAXmboJUKIeZ6Kp7KdZq9XEjzT7S+6qN4eQbv6KT1el2XXjBlbkrpLg+TtMijZ 91W2xt/o2CawxdefpBTuwQDq5BpMsj5yogQdf/koqRWirey4Oz/T1XUg73FDf2WrVpIT Ni+avyVlpiVdQsHFM1WPb4CRytZJJj+31ajTpcsGqgn/Pq/24kZLBzK4BBGtIGlghh6F WGlsnN2EE8g38Cr8bKF1ES4nWcUzHCOABSgfzUKOQMEhPYyaiY+s9tJAuY814G2aK/Pz 8GlP6i/5CEkMK4VC4ZRxHrYYQUewmyDy+g6rbZoAsBcy5rJpOaxmoSUOIRTmOo2/Dalz flvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wU2RncwftWiMVrhtQfpZAug+I4e5eivD8KoFYpsu0i0=; b=YfA7V6t6u+MEpNyzXoNyoKfe7ip2+bwMRCTjCkyG9Hakz9Mgc2gkW/q1VeK+9XGk8z gLejf9+tCW0qnjVLP2TWEOHyZLPh5qky5z/jF6ZMDoU4lipuMCX+FL4tQszo/pk2AU19 7EsJlWlia/AdN1cKvPiW/TJ5KTtIJY6KbvjKEPpQU57fWpAbprPTkiZDmR2kRnjYasRd iHgmiURW6zxnXcYcy9QyjsIzy/+l3odjcdu5kb7c2cAsahqbJ8mc98P0OyyBbfEBn3VL Rq1EamWaRRg+DHbSfc0afgdjRoitHJnqobczXJhRReMsWTCjOWE7xd+pVkDWAGT0Dyo1 RRqQ== X-Gm-Message-State: AJIora8HkagQJDM+Skuod9jXfS1jmuheww/g/ZraUBSGZ2uJkLmwrTEj Y+EOfeZ0Yyx57eEGekQjepEOXd6ATG5kWlm7 X-Google-Smtp-Source: AGRyM1sIsFSaZpaSd6ADCBw3pRu/ZqfzqxQorUVT1Xq/bvprM0KGBC7yvBknuZJ+tXv747nasMcq6A== X-Received: by 2002:a63:1613:0:b0:411:51f0:eaf8 with SMTP id w19-20020a631613000000b0041151f0eaf8mr34038314pgl.62.1657119604162; Wed, 06 Jul 2022 08:00:04 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id h29-20020a056a00001d00b0051bb61c0eacsm3777605pfk.20.2022.07.06.08.00.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jul 2022 08:00:03 -0700 (PDT) Date: Wed, 6 Jul 2022 08:00:01 -0700 From: Stephen Hemminger To: Antonio Di Bacco Cc: =?UTF-8?B?R8OhYm9y?= LENCSE , users@dpdk.org Subject: Re: rte_eth_tx_burst() always returns 0 in tight loop Message-ID: <20220706080001.38ae3781@hermes.local> In-Reply-To: References: <2ca6fffa-05df-9882-34e9-6c13dc2cc28f@hit.bme.hu> MIME-Version: 1.0 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 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. >=20 > Anyway I wonder if this is the right approach. >=20 > Thx, > Antonio. >=20 > On Sun, Jul 3, 2022 at 10:19 PM G=C3=A1bor LENCSE wro= te: > > > > 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 been > > exhausted. > > > > Best regards, > > > > G=C3=A1bor > > > > > > 7/3/2022 5:57 PM keltez=C3=A9ssel, Antonio Di Bacco =C3=ADrta: =20 > > > I'm trying to send packets continuously in a tight loop with a burst > > > size of 8 and packets are 9600 bytes long. > > > If I don't insert a delay after the rte_eth_tx_burst it always return= s 0. > > > > > > What's the explanation of this behaviour ? > > > > > > Best regards, > > > Antonio. =20 > > =20 Which driver? How did you set the tx_free threshold. The driver will need to cleanup already transmitted packets.