DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Verma, Shally" <Shally.Verma@cavium.com>
To: "dev@dpdk.org" <dev@dpdk.org>, "Trahe, Fiona" <fiona.trahe@intel.com>
Cc: "Athreya, Narayana Prasad" <NarayanaPrasad.Athreya@cavium.com>,
	"Challa, Mahipal" <Mahipal.Challa@cavium.com>
Subject: Re: [dpdk-dev] [RFC v2] lib: add compressdev API
Date: Mon, 27 Nov 2017 10:44:29 +0000	[thread overview]
Message-ID: <BY1PR0701MB11119E13000BE9EF52E84D14F0250@BY1PR0701MB1111.namprd07.prod.outlook.com> (raw)

Hi Fiona

Thanks for spec.  It looks good to move ahead for API proof-concepting however still need to address few key open points from rfc doc and others minor comments  (please see inline): 

A. new enum for operation types:
1. Add rte_comp_op_type 
........................................
enum rte_comp_op_type {
RTE_COMP_OP_STATELESS,
RTE_COMP_OP_STATEFUL
}

B. Change in rte_comp_op_pool_create () to input op_type so that required resources could be reserved for that op_type(please see inline more on this).

C. Call enque_burst() for stateless operations. And add a new dedicated API to handle stateful compression
static inline uint16_t rte_compdev_enqueue_stream().

We will add hash and other support as incremental patch on top of this once we align on these few open points.

For rest, please see inline.

> -----Original Message-----
> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
> Sent: 24 November 2017 22:26
> To: dev@dpdk.org; Verma, Shally <Shally.Verma@cavium.com>
> Cc: Challa, Mahipal <Mahipal.Challa@cavium.com>; Athreya, Narayana
> Prasad <NarayanaPrasad.Athreya@cavium.com>;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com
> Subject: [RFC v2] lib: add compressdev API
> 

// snip //
> +/**
> + * Compression Operation.
> + *
> + * This structure contains data relating to performing a compression
> + * operation on the referenced mbuf data buffers.
> + *
> + * All compression operations are Out-of-place (OOP) operations,
> + * as the size of the output data is different to the size of the input data.
> + *
> + * Comp operations are enqueued and dequeued in comp PMDs using the
> + * rte_compressdev_enqueue_burst() /
> rte_compressdev_dequeue_burst() APIs
> + */
> +struct rte_comp_op {
> +

[Shally] need one void *user to enable re-ordering at app if PMD services enqueued requests out of order (requirement from RFC doc)
	void *user;
	/**< user pointer. Set by app, opaque to PMD. Passed back in deque_burst.
                *   app can set it to its data to ensure operations could reorderd, if requests are processed out of order.
                *   Particularly useful for stateless operations
                */

//snip//

> +/**
> + * Creates an operation pool
> + *
> + * @param	name		pool name
> + * @param	nb_elts		number of elements in pool
> + * @param	cache_size	Number of elements to cache on lcore, see
> + *				*rte_mempool_create* for further details
> about
> + *				cache size
> + * @param	priv_size	Size of private data to allocate with each
> + *				operation
> + * @param	socket_id	Socket to allocate memory on
> + *
> + * @return
> + *  - On success pointer to mempool
> + *  - On failure NULL
> + */
> +extern struct rte_mempool *
> +rte_comp_op_pool_create(const char *name,
> +		unsigned nb_elts, unsigned cache_size, uint16_t priv_size,
> +		int socket_id);
> +

[Shally]  This can be modified to input op_type : Stateful/stateless. In such case, pool will be allocated large enough to provide additional memory (or other resources) needed by PMD for that operation such as state / history buffers et el.
So, the proposed API change is :
rte_comp_op_pool_create(const char *name, unsigned nb_elts,
                                                  unsigned cache_size, uint16_t priv_size,
                                                  rte_comp_op_type op_type,
                                                  int socket_id);

Since size of such resources can be different for each implementation, thus a PMD can expose new API in dev_ops that can  returns resources size requirement for op_type.

//snip//
> +
> +/**
> + * Allocate an operation from a mempool with default parameters set
> + *
> + * @param	mempool	operation mempool
> + *
> + * @returns
> + * - On success returns a valid rte_comp_op structure
> + * - On failure returns NULL
> + */
> +static inline struct rte_comp_op *
> +rte_comp_op_alloc(struct rte_mempool *mempool)
> +{

[Shally] rte_comp_op_type should be one of the input arg so that required resources can be reserved according to op_type 

> +	struct rte_comp_op *op = NULL;
> +	int retval;
> +
> +	retval = __rte_comp_op_raw_bulk_alloc(mempool, &op, 1);
> +	if (unlikely(retval != 1))
> +		return NULL;
> +
> +	__rte_comp_op_reset(op);
> +
> +	return op;
> +}
> +
> +
> +/**
> + * Bulk allocate operations from a mempool with default parameters set
> + *
> + * @param	mempool	comp operation mempool
> + * @param	ops	Array to place allocated operations
> + * @param	nb_ops	Number of operations to allocate
> + *
> + * @returns
> + * - nb_ops if the number of operations requested were allocated.
> + * - 0 if the requested number of ops are not available.
> + *   None are allocated in this case.
> + */
> +
> +static inline unsigned
> +rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
> +		struct rte_comp_op **ops, uint16_t nb_ops)
> +{

[Shally]  Similarly, should be extended to input rte_comp_op_type as one of the arg

> +	int i;
> +
> +	if (unlikely(__rte_comp_op_raw_bulk_alloc(mempool, ops, nb_ops)
> +			!= nb_ops))
> +		return 0;
> +
> +	for (i = 0; i < nb_ops; i++)
> +		__rte_comp_op_reset(ops[i]);
> +
> +	return nb_ops;
> +}

//snip//

> +
> +/**
> + * Enqueue a burst of operations for processing on a compression device.
> + *
> + * The rte_compressdev_enqueue_burst() function is invoked to place
> + * comp operations on the queue *qp_id* of the device designated by
> + * its *dev_id*.
> + *
> + * The *nb_ops* parameter is the number of operations to process which
> are
> + * supplied in the *ops* array of *rte_comp_op* structures.
> + *
> + * The rte_compressdev_enqueue_burst() function returns the number of
> + * operations it actually enqueued for processing. A return value equal to
> + * *nb_ops* means that all packets have been enqueued.
> + *
> + * @param	dev_id		The identifier of the device.
> + * @param	qp_id		The index of the queue pair on which
> operations
> + *				are to be enqueued for processing. The value
> + *				must be in the range [0, nb_queue_pairs - 1]
> + *				previously supplied to
> + *				 *rte_compressdev_configure*.
> + * @param	ops		The address of an array of *nb_ops* pointers
> + *				to *rte_comp_op* structures which contain
> + *				the operations to be processed.
> + * @param	nb_ops		The number of operations to process.
> + *
> + * @return
> + * The number of operations actually enqueued on the device. The return
> + * value can be less than the value of the *nb_ops* parameter when the
> + * comp devices queue is full or if invalid parameters are specified in
> + * a *rte_comp_op*.

[Shally] To ensure invalid params, app should check for status value of 
returned_num+1 ops entry which should be set to INVALID_ARGS by PMD?

> + */
> +static inline uint16_t
> +rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> +		struct rte_comp_op **ops, uint16_t nb_ops)
> +{
> +	struct rte_compressdev *dev = &rte_compressdevs[dev_id];
> +
> +	return (*dev->enqueue_burst)(
> +			dev->data->queue_pairs[qp_id], ops, nb_ops);
> +}
> +
> +
> +/** compressdev session */
> +struct rte_comp_session {
> +	__extension__ void *sess_private_data[0];
> +	/**< Private session material */
> +};
> +
> +
> +/**
> + * Create symmetric comp session header (generic with no private data)
> + *

[Shally] Believe Symmetric is type from crypto

//snip//

Thanks
Shally

             reply	other threads:[~2017-11-27 10:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 10:44 Verma, Shally [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-11-24 16:56 Trahe, Fiona
2017-12-07  9:58 ` Verma, Shally
2017-12-11 18:22   ` Trahe, Fiona
2017-12-12  4:43     ` Verma, Shally

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=BY1PR0701MB11119E13000BE9EF52E84D14F0250@BY1PR0701MB1111.namprd07.prod.outlook.com \
    --to=shally.verma@cavium.com \
    --cc=Mahipal.Challa@cavium.com \
    --cc=NarayanaPrasad.Athreya@cavium.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@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).