Re: [dpdk-dev] [EXT] [dpdk-dev v2] cryptodev: change raw data path dequeue API

["Zhang, Roy Fan" <roy.fan.zhang@intel.com>]

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 <gakhil@marvell.com>
> Sent: Tuesday, April 13, 2021 11:20 AM
> To: Zhang, Roy Fan <roy.fan.zhang@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.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