From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Doherty, Declan" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation
Date: Tue, 4 Apr 2017 15:11:27 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D897478023A7@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20170403105302.9685-1-akhil.goyal@nxp.com>
Hi Akhil,
> -----Original Message-----
> From: akhil.goyal@nxp.com [mailto:akhil.goyal@nxp.com]
> Sent: Monday, April 03, 2017 11:53 AM
> To: dev@dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo; Akhil Goyal
> Subject: [PATCH] test/test: improve dequeue logic for crypto operation
>
> From: Akhil Goyal <akhil.goyal@nxp.com>
>
> While enqueue/dequeue operations in test_perf_aes_sha,
> the underlying implementation may not be able to dequeue
> the same number of buffers as enqueued. So, it may be
> necessary to perform more dequeue operations if the gap
> is more than pparams->burst_size * NUM_MBUF_SETS.
>
> Other algos may also need to update the logic if required.
>
In which way this patch improves the dequeue logic?
Is it improving the performance somehow? From what I see, it is unlikely that you are going to
experience the problem, as the internal ring is PERF_NUM_OPS_INFLIGHT, which is 128,
higher than pparams->burst_size * NUM_MBUF_SETS, which is 256.
And even if you do meet that problem, then you would be reusing mbufs,
but that is OK as we are not verifying the output.
Thanks,
Pablo
next prev parent reply other threads:[~2017-04-04 15:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 10:53 akhil.goyal
2017-04-04 15:11 ` De Lara Guarch, Pablo [this message]
2017-04-20 10:48 ` Akhil Goyal
2017-04-26 9:38 ` De Lara Guarch, Pablo
2017-04-26 9:53 ` Akhil Goyal
2017-04-26 10:42 ` De Lara Guarch, Pablo
2017-04-26 11:02 ` Akhil Goyal
2017-05-02 7:22 ` De Lara Guarch, Pablo
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=E115CCD9D858EF4F90C690B0DCB4D897478023A7@IRSMSX108.ger.corp.intel.com \
--to=pablo.de.lara.guarch@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=declan.doherty@intel.com \
--cc=dev@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).