DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Sungho Hong <maverickjin88@gmail.com>
Cc: users@dpdk.org
Subject: Re: [dpdk-users] low performance of send and receiving single message in RTE_RING
Date: Fri, 31 Aug 2018 13:09:33 -0700	[thread overview]
Message-ID: <20180831130933.699f9f39@xeon-e3> (raw)
In-Reply-To: <CAK8vx=jdwNw0dozfoqs+c61jWrHKh7Xr8x6Gd6Z5Pr72fxxEnQ@mail.gmail.com>

On Fri, 31 Aug 2018 12:55:22 -0700
Sungho Hong <maverickjin88@gmail.com> wrote:

> Hello, DPDK-users,
> 
> I am wondering whether there is a good explanation for high latency caused
> by rte_ring when testing the round-trip latency using 1 burst in (tx rx
> queue).
> 
> I have tested the performance using two nodes (client and server)
> and calculated the elapsed latency of the round-trip of single pingpong.
> The latency is calculated on two different test-cases
> 1. elapsed latency of send and receive directly from rx tx queue.
> 2. elapsed latency of send and receive from rte_ring.
> 
> 
> Latency with direct tx rx queue with 1 burst
> When I send a single messages (512, 1024, 4096 bytes) (1 burst for each
> request) and receive 1 burst of response from the remote server.
> the latency is approximately 4 ~ 8 microseconds.
> 
> 
> RTE_RING Latency with 1 burst
> When I use rte_ring to send and receive data from client and server, the
> latency increases like crazy which is 59 microseconds to 100 microseconds.
> 
> 
> RTE_RING Latency with 10 bursts
> When I use bursts for example (10 messages per request)
> and calculate the elapsed latency by dividing the total elapsed time with
> the total ping-pong messages (total-latency)/(total ping-pong received
> messages).
> I could get a very good performance using rte_ring 7 ~ 10 microseconds.
> 
> 
> I was wondering whether someone can tell me what I should look at in order
> to decrease the latency of RTE_RING.
> Because even though I don't use multiple bursts, the latency should be low.

The ring itself should have no visible latency. It comes down to how the producer
and consumer are signaling each other and process scheduling.

      reply	other threads:[~2018-08-31 20:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 19:55 Sungho Hong
2018-08-31 20:09 ` Stephen Hemminger [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=20180831130933.699f9f39@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=maverickjin88@gmail.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).