From: Suraj R Gupta <surajrgupta@iith.ac.in>
To: Bev SCHWARTZ <bev.schwartz@raytheon.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] Significant performance degradation when using tx buffers rather than rte_eth_tx_burst
Date: Thu, 9 Jul 2020 02:12:20 +0530 [thread overview]
Message-ID: <CAMfGv3=pcbpyVfYyMeyg4pzb54+icBYV1zKoPAkxqXEzukKmLA@mail.gmail.com> (raw)
In-Reply-To: <DM3P110MB0524688C02177E5864CEB384EA670@DM3P110MB0524.NAMP110.PROD.OUTLOOK.COM>
Hi bev,
If my understanding is right, rte_eth_tx_burst transmits output packets
immediately with a specified number of packets.
While, 'rte_eth_tx_buffer' buffers the packet in the queue of the port,
the packets would be transmitted only when buffer is or
rte_eth_tx_buffer_flush is called.
Since you are buffering packets one by one and then you are calling flush,
this may have contributed to the delay.
Thanks and Regards
Suraj R Gupta
On Wed, Jul 8, 2020 at 10:53 PM Bev SCHWARTZ <bev.schwartz@raytheon.com>
wrote:
> I am writing a bridge using DPDK, where I have traffic read from one port
> transmitted to the other. Here is the core of the program, based on
> basicfwd.c.
>
> while (!force_quit) {
> nb_rx = rte_eth_rx_burst(rx_port, rx_queue, bufs, BURST_SIZE);
> for (i = 0; i < nb_rx; i++) {
> /* inspect packet */
> }
> nb_tx = rte_eth_tx_burst(tx_port, tx_queue, bufs, nb_rx);
> for (i = nb_tx; i < nb_rx; i++) {
> rte_pktmbuf_free(bufs[i]);
> }
> }
>
> (A bunch of error checking and such left out for brevity.)
>
> This worked great, I got bandwidth equivalent to using a Linux Bridge.
>
> I then tried using tx buffers instead. (Initialization code left out for
> brevity.) Here is the new loop.
>
> while (!force_quit) {
> nb_rx = rte_eth_rx_burst(rx_port, rx_queue, bufs, BURST_SIZE);
> for (i = 0; i < nb_rx; i++) {
> /* inspect packet */
> rte_eth_tx_buffer(tx_port, tx_queue, tx_buffer, bufs[i]);
> }
> rte_eth_tx_buffer_flush(tx_port, tx_queue, tx_buffer);
> }
>
> (Once again, error checking left out for brevity.)
>
> I am running this on 8 cores, each core has its own loop. (tx_buffer is
> created for each core.)
>
> If I have well balanced traffic across the cores, then my performance goes
> down, about 5% or so. If I have unbalanced traffic such as all traffic
> coming from a single flow, my performance goes down 80% from about 10 gbs
> to 2gbs.
>
> I want to stress that the ONLY thing that changed in this code is changing
> how I transmit packets. Everything else is the same.
>
> Any idea why this would cause such a degradation in bit rate?
>
> -Bev
--
Thanks and Regards
Suraj R Gupta
next prev parent reply other threads:[~2020-07-08 20:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 17:23 Bev SCHWARTZ
2020-07-08 20:42 ` Suraj R Gupta [this message]
2020-07-13 6:32 ` Manish Kumar
2020-07-13 17:18 ` Bev SCHWARTZ
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='CAMfGv3=pcbpyVfYyMeyg4pzb54+icBYV1zKoPAkxqXEzukKmLA@mail.gmail.com' \
--to=surajrgupta@iith.ac.in \
--cc=bev.schwartz@raytheon.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).