DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	"dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] eventdev: sw rx adapter enqueue caching
Date: Tue, 7 May 2019 12:03:28 +0000	[thread overview]
Message-ID: <5C45143B-6A87-4837-A095-4FFE5A9EAE87@nokia.com> (raw)
Message-ID: <20190507120328.fjmmRLbPdSTMN_xKfk6n_XyTsZg1M-7ESCSYyhWzwl0@z> (raw)
In-Reply-To: <37fcfbf6-fcc3-8af4-0494-95e561881e17@lysator.liu.se>



On 7 May 2019, at 15:01, Mattias Rönnblom <hofors@lysator.liu.se<mailto:hofors@lysator.liu.se>> wrote:



On 2019-05-07 13:12, Honnappa Nagarahalli wrote:

Hi,

The SW eventdev rx adapter has an internal enqueue buffer 'rx_adapter-
event_enqueue_buffer', which stores packets received from the NIC until at
least BATCH_SIZE (=32) packets have been received before enqueueing them
to eventdev. For example in case of validation testing, where often a small
number of specific test packets is sent to the NIC, this causes a lot of
problems. One would always have to transmit at least BATCH_SIZE test
packets before anything can be received from eventdev. Additionally, if the rx
packet rate is slow this also adds a considerable amount of additional delay.

Looking at the rx adapter API and sw implementation code there doesn’t
seem to be a way to disable this internal caching. In my opinion this
“functionality" makes testing sw rx adapter so cumbersome that either the
implementation should be modified to enqueue the cached packets after a
while (some performance penalty) or there should be some method to
disable caching. Any opinions how this issue could be fixed?
At the minimum, I would think there should be a compile time option.
From a use case perspective, I think it falls under latency vs throughput considerations. If there is a latency sensitive application, it might not want to wait till 32 packets are received.

From what I understood from Matias Elo and also after a quick glance in the code, the unlucky packets will be buffered indefinitely, in case the system goes idle. This is totally unacceptable (both in production and validation), in my opinion, and should be filed as a bug.


Indeed, this is what happens. I’ll create a bug report to track this issue.



  parent reply	other threads:[~2019-05-07 12:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07  9:52 Elo, Matias (Nokia - FI/Espoo)
2019-05-07  9:52 ` Elo, Matias (Nokia - FI/Espoo)
2019-05-07 11:12 ` Honnappa Nagarahalli
2019-05-07 11:12   ` Honnappa Nagarahalli
2019-05-07 12:01   ` Mattias Rönnblom
2019-05-07 12:01     ` Mattias Rönnblom
2019-05-07 12:03     ` Elo, Matias (Nokia - FI/Espoo) [this message]
2019-05-07 12:03       ` Elo, Matias (Nokia - FI/Espoo)
2019-05-07 12:13       ` Jerin Jacob Kollanukkaran
2019-05-07 12:13         ` Jerin Jacob Kollanukkaran
2019-05-09 11:24       ` Rao, Nikhil
2019-05-09 11:24         ` Rao, Nikhil
2019-05-09 15:02         ` Elo, Matias (Nokia - FI/Espoo)
2019-05-09 15:02           ` Elo, Matias (Nokia - FI/Espoo)
2019-05-07 11:56 ` Mattias Rönnblom
2019-05-07 11:56   ` Mattias Rönnblom

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=5C45143B-6A87-4837-A095-4FFE5A9EAE87@nokia.com \
    --to=matias.elo@nokia.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=hofors@lysator.liu.se \
    --cc=nd@arm.com \
    /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).