DPDK usage discussions
 help / color / mirror / Atom feed
From: Pierre Laurent <pierre.laurent@emutex.com>
To: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] rte_eth_tx_burst duplicate packets
Date: Mon, 28 Jan 2019 19:16:27 +0000	[thread overview]
Message-ID: <ed71d575-78ec-7132-27b8-4e6301db1b72@emutex.com> (raw)
In-Reply-To: <CAM-kPquh6ZnHo2iZX75FxV_ixCZCv7Vz2jsyTkH4J2eYtGW9Vw@mail.gmail.com>


Please be more precise when you mention 2 loops and describe only 1. I 
can only guess what you are doing,


Please look at the following pseudo-code with 2 loops, which I guess is 
close to what you might have not shown in your description.

The second time you would execute the outer loop, you might be 
incrementing something in the payload of packets that have not been 
transmitted, thus creating some pseudo error count less than the TX 
queue size (which I guess is 1024 in your code), and getting the feeling 
that too many packets with the same udp counter are received.


while (1)  // outer loop

{

       *ptr_udp ++;  /* increment something at some place in udp payload 
somewhere in the packets to transmit */

      for (i = 0; i < 800000; i++) {   // inner loop

          sent = 0;

          tx = 10;

          /* increment refcount for each packet to transmit before 
transmitting them */

         for (j = 0; j < tx; j++) {

                rte_mbuf_refcnt_update(tx_pkt[j], 1);

           }

          /* enqueue 10 packets, depending on queue size, they might be 
help a long time in tx queue */

          while (sent != tx) {

                sent +=  rte_eth_tx_burst(id, 0, &pkts[sent], tx - sent);

          }   /* here many packets are still enqueued in tx queue, not 
yet read read by the NIC */

       } /* here many packets are still enqueued in tx queue, not yet 
read read by the NIC */

}


Before you increment a counter in packets which you do not know if they 
are transmitted, you should check they are effectively transmitted by 
checking the reference count  has reached a  value low enough (probably 
1 in your code, I can only guess)

One of the many ways to check it and wait for transmission of packets in 
the previous loop is  would look as the following additional code, at 
the start or end of the outer loop

        for (j = 0; j < tx; j++) {

                while (rte_mbuf_refcnt_read(tx_pkt[j]) != 1)   { /* busy 
wait, this packet is not transmitted yet */   }

       }




Pierre


On 23/01/2019 07:16, Peter Balint wrote:
> Hi,
>
> I am just writing my first a traffic generator code.
> The program sends predefined quantity of frames(Ethernet/IP/UDP) in each
> seconds. It use 2 loops 1 for seconds the other for the packets in each
> second.
>
> for sending I use a while loop
>
>                  sent=0;
>                  while (sent==0){
>                      sent = rte_eth_tx_burst(eth_id, 0, &pkts, 1);
>
>                  }
> for reviving
> recv = rte_eth_rx_burst(eth_id, 0, pktr_burst2, 10);
>
> in the initialization phase I put the packet in the mbuf. In the UDP data
> filed is a counter which increasing in every second(with this I would like
> to identify the possible packet drops er sec bases)
>
> with lower load the program works fine but close to 100% of performance
>
> Forward frames sent: 8000000
> Forward frames received: 8000336
> Reverse frames sent: 8000000
> Reverse frames received: 7990793
>
>
>
> Results  in 1 sec sent 800000  recvd  799972 and difference -28
> Results  in 2 sec sent 800000  recvd  799888 and difference -112
> Results  in 3 sec sent 800000  recvd  800000 and difference 0
> Results  in 4 sec sent 800000  recvd  800000 and difference 0
> Results  in 5 sec sent 800000  recvd  800000 and difference 0
> Results  in 6 sec sent 800000  recvd  800000 and difference 0
> Results  in 7 sec sent 800000  recvd  800120 and difference 120
> Results  in 8 sec sent 800000  recvd  799880 and difference -120
> Results  in 9 sec sent 800000  recvd  800000 and difference 0
> Results  in 10 sec sent 800000  recvd  800476 and difference 476
>
> It received more packets than sent.
>
> Are there any solution to fix this issue?
>
>
> Many Thanks,
>
> Peter

-- 
Emutex Limited, Roselawn House, National Technology Park, Limerick, V94 6R68, Ireland.
Phone: +353 (0)61 514496 Ext# 814, Web: www.emutex.com.


      parent reply	other threads:[~2019-01-28 19:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23  7:16 Peter Balint
2019-01-28 11:07 ` Nutman, Richard
2019-01-28 19:16 ` Pierre Laurent [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed71d575-78ec-7132-27b8-4e6301db1b72@emutex.com \
    --to=pierre.laurent@emutex.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).