Hi Akhil,
It is possible the user don't know how many ops to dequeue.
For example in VPP crypto up to 64 buffers (vnet_crypto_async_frame_elt_t) are
wrapped into the following data structure
typedef struct
{
CLIB_CACHE_LINE_ALIGN_MARK (cacheline0);
vnet_crypto_async_frame_state_t state;
vnet_crypto_async_op_id_t op:8;
u16 n_elts;
vnet_crypto_async_frame_elt_t elts[VNET_CRYPTO_FRAME_SIZE];
u32 buffer_indices[VNET_CRYPTO_FRAME_SIZE];
u16 next_node_index[VNET_CRYPTO_FRAME_SIZE];
u32 enqueue_thread_index;
} vnet_crypto_async_frame_t;
Instead of passing vnet_crypto_async_frame_elt_t Pointer as metadata to
cryptodev, we have to pass vnet_crypto_async_frame_t pointer into cryptodev.
The callback function helps parse the first dequeued metadata to get n_elts and
will dequeue that many ops.
But in case we cannot dequeue the whole frame, passing the number of ops not
dequeued yet in the next dequeue_burst operation should help us to dequeue the
whole frame. In this case we only have to cache up to 1 frame pointer for half
dequeued frame.
As the patch stated this should help cover both cases for user either dequeue
the wrapped data structure with multiple buffers, or dequeue a burst of packets
- hence giving people more flexibility.
Regards,
Fan
> -----Original Message-----
> From: Akhil Goyal <gak...@marvell.com>
> Sent: Tuesday, April 13, 2021 11:20 AM
> To: Zhang, Roy Fan <roy.fan.zh...@intel.com>; dev@dpdk.org
> Subject: RE: [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue
> API
>
> 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.zh...@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
