<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Dear Michal, 12/22/2021 10:56 AM keltezéssel, Michał Niciejewski írta: <blockquote type="cite" cite="mid:CA+xtTg0xThxPwuKnMrCZR+dqxSpv86bTW3wNok69Q7bfDzSukw@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> auto tx_num = rte_eth_tx_burst(1, queue, mbufs.data(), rx_num); </div> </blockquote> 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) ) ; <blockquote type="cite" cite="mid:CA+xtTg0xThxPwuKnMrCZR+dqxSpv86bTW3wNok69Q7bfDzSukw@mail.gmail.com"> <div dir="ltr">Did anyone have similar issues or know what could cause such behavior? </div> </blockquote> I met a somewhat similar issue, when I implemented the first version of siitperf: <a class="moz-txt-link-freetext" href="https://github.com/lencsegabor/siitperf">https://github.com/lencsegabor/siitperf</a> 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 </body> </html>