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 5744DA034E for ; Wed, 22 Dec 2021 13:28:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D808C40040; Wed, 22 Dec 2021 13:28:42 +0100 (CET) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [152.66.248.44]) by mails.dpdk.org (Postfix) with ESMTP id B88B54003C for ; Wed, 22 Dec 2021 13:28:41 +0100 (CET) Received: from [192.168.1.146] (host-79-121-42-244.kabelnet.hu [79.121.42.244]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 1BMCSYvR076258 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 22 Dec 2021 13:28:40 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-244.kabelnet.hu [79.121.42.244] claimed to be [192.168.1.146] Content-Type: multipart/alternative; boundary="------------pV3kGPe7y0gBqfS6q0l9o61s" Message-ID: <36e7779e-b2e1-657e-da42-bf14bb34e29a@hit.bme.hu> Date: Wed, 22 Dec 2021 13:28:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Unexpected behavior when using mbuf pool with external buffers Content-Language: en-US To: users@dpdk.org References: From: =?UTF-8?Q?G=c3=a1bor_LENCSE?= In-Reply-To: X-Virus-Scanned: clamav-milter 0.103.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.244; helo=[192.168.1.146]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC-x.dcc-servers-Metrics: frogstar.hit.bme.hu; whitelist X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, AWL, HTML_MESSAGE autolearn=disabled version=3.4.1-frogstar X-Spam-Checker-Version: SpamAssassin 3.4.1-frogstar (2015-04-28) on frogstar.hit.bme.hu X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 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 This is a multi-part message in MIME format. --------------pV3kGPe7y0gBqfS6q0l9o61s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Michal, 12/22/2021 10:56 AM keltezéssel, Michał Niciejewski írta: >     auto tx_num = rte_eth_tx_burst(1, queue, mbufs.data(), rx_num); I suspect that the frame is sometimes simply not transmitted at high rates. The rte_eth_tx_burst() function reports the number of actually transmitted frames. I usually send a frame using the following loop: while ( !rte_eth_tx_burst(eth_id, 0, &pkt_mbuf, 1) )   ; > Did anyone have similar issues or know what could cause such behavior? I met a somewhat similar issue, when I implemented the first version of siitperf: https://github.com/lencsegabor/siitperf Then I was not aware of RFC 4814 yet, so I always transmitted the very same frame for throughput measurements, but I used a counter to be able to uniquely identify the test frames for packet delay variation measurement. I wanted to use the frame as a template and I modified its counter (and checksum) field after sending.  I have found that even if the rte_eth_tx_burst() function reported that the frame was sent, it was still in the buffer and I have rewritten its counter. (The receiver reported no frame with counter value 0, and 2 frames with the highest value of the counter.) To circumvent the problem, I used an array of frames and I modified always the next element (modulo array size). Best regards, Gábor --------------pV3kGPe7y0gBqfS6q0l9o61s Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear Michal,

12/22/2021 10:56 AM keltezéssel, Michał Niciejewski írta:
    auto tx_num = rte_eth_tx_burst(1, queue, mbufs.data(), rx_num);

I suspect that the frame is sometimes simply not transmitted at high rates.

The rte_eth_tx_burst() function reports the number of actually transmitted frames. I usually send a frame using the following loop:

while ( !rte_eth_tx_burst(eth_id, 0, &pkt_mbuf, 1) )
  ;

Did anyone have similar issues or know what could cause such behavior?

I met a somewhat similar issue, when I implemented the first version of siitperf: https://github.com/lencsegabor/siitperf

Then I was not aware of RFC 4814 yet, so I always transmitted the very same frame for throughput measurements, but I used a counter to be able to uniquely identify the test frames for packet delay variation measurement. I wanted to use the frame as a template and I modified its counter (and checksum) field after sending.  I have found that even if the rte_eth_tx_burst() function reported that the frame was sent, it was still in the buffer and I have rewritten its counter. (The receiver reported no frame with counter value 0, and 2 frames with the highest value of the counter.)
To circumvent the problem, I used an array of frames and I modified always the next element (modulo array size).

Best regards,

Gábor
--------------pV3kGPe7y0gBqfS6q0l9o61s--