From: Akhil Goyal <gakhil@marvell.com>
To: Fan Zhang <roy.fan.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue API
Date: Tue, 13 Apr 2021 10:19:52 +0000 [thread overview]
Message-ID: <MW2PR18MB2284108AE5F082668F349A52D84F9@MW2PR18MB2284.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20210331172038.1718973-1-roy.fan.zhang@intel.com>
Hi Fan,
> This patch changes the experimental raw data path dequeue burst API.
> Originally the API enforces the user to provide callback function
> to get maximum dequeue count. This change gives the user one more
> option to pass directly the expected dequeue count.
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> ---
> app/test/test_cryptodev.c | 8 +-------
> doc/guides/rel_notes/release_21_05.rst | 3 +++
> drivers/crypto/qat/qat_sym_hw_dp.c | 21 ++++++++++++++++++---
> lib/librte_cryptodev/rte_cryptodev.c | 5 +++--
> lib/librte_cryptodev/rte_cryptodev.h | 8 ++++++++
> 5 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
> index f91debc168..a910547423 100644
> --- a/app/test/test_cryptodev.c
> +++ b/app/test/test_cryptodev.c
> @@ -162,12 +162,6 @@ ceil_byte_length(uint32_t num_bits)
> return (num_bits >> 3);
> }
>
> -static uint32_t
> -get_raw_dp_dequeue_count(void *user_data __rte_unused)
> -{
> - return 1;
> -}
> -
> static void
> post_process_raw_dp_op(void *user_data, uint32_t index __rte_unused,
> uint8_t is_op_success)
> @@ -345,7 +339,7 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t
> qp_id,
> n = n_success = 0;
> while (count++ < MAX_RAW_DEQUEUE_COUNT && n == 0) {
> n = rte_cryptodev_raw_dequeue_burst(ctx,
> - get_raw_dp_dequeue_count,
> post_process_raw_dp_op,
> + NULL, 1, post_process_raw_dp_op,
> (void **)&ret_op, 0, &n_success,
> &dequeue_status);
> if (dequeue_status < 0) {
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 8e686cc627..943f1596c5 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -130,6 +130,9 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* cryptodev: the function ``rte_cryptodev_raw_dequeue_burst`` is added a
> + parameter ``max_nb_to_dequeue`` to give user a more flexible dequeue
> control.
> +
Shouldn't we remove the callback completely?
What is the use case of having 2 different methods of passing a
Simple dequeue count?
Why do we need such flexibility?
Regards,
Akhil
next prev parent reply other threads:[~2021-04-13 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 11:14 [dpdk-dev] " Fan Zhang
2021-03-31 17:20 ` [dpdk-dev] [dpdk-dev v2] " Fan Zhang
2021-04-13 10:19 ` Akhil Goyal [this message]
2021-04-15 10:14 ` [dpdk-dev] [EXT] " Zhang, Roy Fan
2021-04-15 14:45 ` Akhil Goyal
2021-04-16 10:12 ` Akhil Goyal
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=MW2PR18MB2284108AE5F082668F349A52D84F9@MW2PR18MB2284.namprd18.prod.outlook.com \
--to=gakhil@marvell.com \
--cc=dev@dpdk.org \
--cc=roy.fan.zhang@intel.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).