* Re: [dpdk-users] rte_eth_tx_burst duplicate packets
2019-01-23 7:16 [dpdk-users] rte_eth_tx_burst duplicate packets Peter Balint
@ 2019-01-28 11:07 ` Nutman, Richard
2019-01-28 19:16 ` Pierre Laurent
1 sibling, 0 replies; 3+ messages in thread
From: Nutman, Richard @ 2019-01-28 11:07 UTC (permalink / raw)
To: users
It seems you are receiving in bursts of 10, but for sending you only send 1 packet at a time.
Send batches of packets to rte_eth_tx_burst to improve sending efficiency.
>
> 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
**********************************************************************
DISCLAIMER:
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [dpdk-users] rte_eth_tx_burst duplicate packets
2019-01-23 7:16 [dpdk-users] rte_eth_tx_burst duplicate packets Peter Balint
2019-01-28 11:07 ` Nutman, Richard
@ 2019-01-28 19:16 ` Pierre Laurent
1 sibling, 0 replies; 3+ messages in thread
From: Pierre Laurent @ 2019-01-28 19:16 UTC (permalink / raw)
To: users
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.
^ permalink raw reply [flat|nested] 3+ messages in thread