From: Peter Keereweer <peterkeereweer@hotmail.com>
To: "users@dpdk.org" <users@dpdk.org>
Subject: [dpdk-users] What to do after rte_eth_tx_burst: free or send again remaining packets?
Date: Sat, 28 Jan 2017 19:57:04 +0000 [thread overview]
Message-ID: <DB6PR1001MB1416AC3F6FF8FE6F82EA1F35C0490@DB6PR1001MB1416.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <DB6PR1001MB14167842D49F0751FC93ADD9C0490@DB6PR1001MB1416.EURPRD10.PROD.OUTLOOK.COM>
Hi!
Currently I'am running some tests with the Load Balancer Sample Application. I'm testing the Load Balancer Sample Application by sending packets with pktgen.
I have a setup of 2 servers with each server containing a Intel 10Gbe 82599 NIC (connected to each other). I have configured the Load Balancer application to use 1 core for RX, 1 worker core and 1 TX core. The TX core sends all packets back to the pktgen application.
With the pktgen I send 1024 UDP packets to the Load Balancer. Every packet processed by the worker core will be printed to the screen (I added this code by myself). If I send 1024 UDP packets, 1008 ( = 7 x 144) packets will be printed to the screen. This is correct, because the RX core reads packets with a burst size of 144. So if I send 1024 packets, I expect 1008 packets back in the pktgen application. But surprisingly I only receive 224 packets instead of 1008 packets. After some research I found that that 224 packets is not just a random number, its 7 x 32 (= 224). So if the RX reads 7 x 144 packets, I get back 7 x 32 packets. After digging into the code from the Load Balancer application I found in 'runtime.c' in the 'app_lcore_io_tx' function this code :
n_pkts = rte_eth_tx_burst(
port,
0,
lp->tx.mbuf_out[port].array,
(uint16_t) n_mbufs);
...
if (unlikely(n_pkts < n_mbufs)) {
uint32_t k;
for (k = n_pkts; k < n_mbufs; k ++) {
struct rte_mbuf *pkt_to_free = lp->tx.mbuf_out[port].array[k];
rte_pktmbuf_free(pkt_to_free);
}
}
What I understand from this code is that n_mbufs 'packets' are send with 'rte_eth_tx_burst' function. This function returns n_pkts, the number of packets that are actually send. If the actual number of packets send is smaller then n_mbufs (packets ready for send given to the rte_eth_tx_burst) then all remaining packets, which are not send, are freed. In de the Load Balancer application, n_mbufs is equal to 144. But in my case 'rte_eth_tx_burst' returns the value 32, and not 144. So 32 packets are actually send and the remaining packets (144 - 32 = 112) are freed. This is the reason why I get 224 (7 x 32) packets back instead of 1008 (= 7 x 144).
But the question is: why are the remaining packets freed instead of trying to send them again? If I look into the 'pktgen.c', there is a function '_send_burst_fast' where all remaining packets are trying to be send again (in a while loop until they are all send) instead of freeing them (see code below) :
static __inline__ void
_send_burst_fast(port_info_t *info, uint16_t qid)
{
struct mbuf_table *mtab = &info->q[qid].tx_mbufs;
struct rte_mbuf **pkts;
uint32_t ret, cnt;
cnt = mtab->len;
mtab->len = 0;
pkts = mtab->m_table;
if (rte_atomic32_read(&info->port_flags) & PROCESS_TX_TAP_PKTS) {
while (cnt > 0) {
ret = rte_eth_tx_burst(info->pid, qid, pkts, cnt);
pktgen_do_tx_tap(info, pkts, ret);
pkts += ret;
cnt -= ret;
}
} else {
while(cnt > 0) {
ret = rte_eth_tx_burst(info->pid, qid, pkts, cnt);
pkts += ret;
cnt -= ret;
}
}
}
Why is this while loop (sending packets until they have all been send) not implemented in the 'app_lcore_io_tx' function in the Load Balancer application? That would make sense right? It looks like that the Load Balancer application makes an assumption that if not all packets have been send, the remaining packets failed during the sending proces and should be freed.
I hope someone can help me with this questions. Thank you in advance!!
Peter
next parent reply other threads:[~2017-01-28 19:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DB6PR1001MB14167842D49F0751FC93ADD9C0490@DB6PR1001MB1416.EURPRD10.PROD.OUTLOOK.COM>
2017-01-28 19:57 ` Peter Keereweer [this message]
2017-01-28 22:43 ` Wiles, Keith
2017-01-30 16:02 ` Peter Keereweer
2017-01-30 20:55 ` Wiles, Keith
2017-02-02 6:29 ` Peter Keereweer
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=DB6PR1001MB1416AC3F6FF8FE6F82EA1F35C0490@DB6PR1001MB1416.EURPRD10.PROD.OUTLOOK.COM \
--to=peterkeereweer@hotmail.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).