From: "Verma, Shally" <Shally.Verma@cavium.com>
To: Ahmed Mansour <ahmed.mansour@nxp.com>,
"Trahe, Fiona" <fiona.trahe@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Athreya, Narayana Prasad" <NarayanaPrasad.Athreya@cavium.com>,
"Gupta, Ashish" <Ashish.Gupta@cavium.com>,
"Sahu, Sunila" <Sunila.Sahu@cavium.com>,
"Challa, Mahipal" <Mahipal.Challa@cavium.com>,
"Jain, Deepak K" <deepak.k.jain@intel.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Roy Pledge <roy.pledge@nxp.com>,
Youri Querry <youri.querry_1@nxp.com>
Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API
Date: Tue, 27 Feb 2018 05:53:37 +0000 [thread overview]
Message-ID: <MWHPR0701MB364183B1F3D3E0AE0B5FF83CF0C00@MWHPR0701MB3641.namprd07.prod.outlook.com> (raw)
In-Reply-To: <DB3PR0402MB3852AB6E2BB21C85FE9E6B15E1C10@DB3PR0402MB3852.eurprd04.prod.outlook.com>
>-----Original Message-----
>From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com]
>Sent: 27 February 2018 03:05
>To: Verma, Shally <Shally.Verma@cavium.com>; Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org
>Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>;
>Gupta, Ashish <Ashish.Gupta@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Challa, Mahipal
><Mahipal.Challa@cavium.com>; Jain, Deepak K <deepak.k.jain@intel.com>; Hemant Agrawal <hemant.agrawal@nxp.com>; Roy
>Pledge <roy.pledge@nxp.com>; Youri Querry <youri.querry_1@nxp.com>
>Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API
>
>> Hi Fiona, Ahmed
>>> Hi Fiona,
>>>
>>> Thanks for starting this discussion. In the current API the user must
>>> make 12 API calls just to get information to compress. Maybe there is a
>>> way to simplify. At least for some use cases (stateless). I think a call
>>> sometime next week would be good to help clarify coalesce some of the
>>> complexity.
>>>
>>> I added specific comments inline.
>>>
>>> Thanks,
>>>
>>> Ahmed
>>>
>>> On 2/21/2018 2:12 PM, Trahe, Fiona wrote:
>>>> We've been struggling with the idea of session in compressdev.
>>>>
>>>> Is it really a session?
>>>> - It's not in the same sense as cryptodev where it's used to hold a key, and maps to a Security Association.
>>>> - It's a set of immutable data that is needed with the op and stream to perform the operation.
>>>> - It inherited from cryptodev the ability to be set up for multiple driver types and used across any
>>>> devices of those types. For stateful ops this facility can't be used.
>>>> For stateless we don't think it's important, and think it's unlikely to be used.
>>>> - Drivers use it to prepare private data, set up resources, do pre-work, so there's
>>>> less work to be done on the data path. Initially we didn't have a stream, we do now,
>>>> this may be a better alternative place for that work.
>>>> So we've been toying with the idea of getting rid of the session.
>>> [Ahmed] In our proprietary API the stream and session are one. A session
>>> holds many properties like the op-type, instead of having this
>>> information in the op itself. This way we lower the per op setup cost.
>>> This also allows rapid reuse of stateful infrastructure, once a stream
>>> is closed on a stateful session, the next op (stream) on this session
>>> reuses the stateful storage. Obviously if a stream is in "pause mode" on
>>> a session, all following ops that may be unrelated to this
>>> stream/session must also wait until this current stream is closed or
>>> aborted before the infrastructure can be reused.
>>>> We also struggle with the idea of setting up a stream for stateless ops.
>>>> - Well, really I just think the name is misleading, i.e. there's no problem with setting
>>>> up some private PMD data to use with stateless operations, just calling it a
>>>> stream doesn't seem right.
>>> [Ahmed] I agree. The op has all the necessary information to process it
>>> in the current API? Both the stream and the op are one time use. We
>>> can't attach multiple similar ops to a single stream/session and rely on
>>> their properties to simplify op setup, so why the hassle.
>> [Shally] As per my knowledge, session came with idea in DPDK, if system has multiple devices setup to do similar jobs then
>application can fan out ops to any of them for load-balancing. Though it is not possible for stateful ops but it still can work for stateless.
>If there's an application which only have stateless ops to process then I see this is still useful feature to support.
>[Ahmed] Is there an advantage to exposing load balancing to the user? I
>do not see load balancing as a feature within itself. Can the PMD take
>care of this? I guess a system that has
[Shally] I assume idea was to leverage multiple PMDs that are available in system (say QAT+SW ZLIB) and I believe matter of load-balancing came out of one of the earlier discussion with Fiona on RFC v1. http://dev.dpdk.narkive.com/CHS5l01B/dpdk-dev-rfc-v1-doc-compression-api-for-dpdk#post3
So, I wait for her comments on this. But in any case, with changed notion too it looks achievable to me, if so is desired.
>> In current proposal, stream logically represent data and hold its specific information and session is generic information that can be
>applied on multiple data. If we want to combine stream and session. Then one way to look at this is:
>>
>> "let application only allocate and initialize session with rte_comp_xform (and possibly op type) information so that PMD can do one-
>time setup and allocate enough resources. Once attached to op, cannot be reused until that op is fully processed. So, if app has 16
>data elements to process in a burst, it will setup 16 sessions."
>[Ahmed] Why not allow multiple inflight stateless ops with the same
>session? Stateless by definition guarantees that the resources used to
>work on one up will be free after the op is processed. That means that
>even if an op fails to process correctly on a session, it will have no
>effect on the next op since there is not interdependence. This assumes
>that the resources are shareable between hardware instances for
>stateless. That is not a bad assumption since hardware should not need
>more than the data of the op itself to work on a statelss op.
[Shally] multiple ops in-flight can connect to same session but I assume you agree then they cannot execute in parallel i.e. only one op at-a-time can use session here? And as far as I understand your PMD works this way. Your HW execute one op at-a-time from queue?!
>> This is same as what Ahmed suggested. For a particular load-balancing case suggested above, If application want, can initialize
>different sessions on multiple devices with same xform so that each is prepared to process ops. Application can then fanout stateless
>ops to multiple devices for load-balancing but then it would need to keep map of device & a session map.
>>
>> If this sound feasible, then I too believe we can rather get rid of either and keep one (possibly session but am open with stream as
>well).
>> However, regardless of case whether we live with name stream or session, I don't see much deviation from current API spec except
>description and few modifications/additions as identified.
>> So, then I see it as:
>>
>> - A stream(or session whichever name is chosen) can be used with only one-op at-a-time
>> - It can be re-used when previously attached op is processed
>> - if it is stream then currently it is allocated from PMD managed pool whereas Sessions are allocated from application created
>mempool.
>> In either of case, I would expect to review pool management API
>>
>> With this in mind, below are few of my comments
>>
>>>> So putting above thoughts together I want to propose:
>>>> - Removal of the session and all associated APIs.
>>>> - Passing in one of three data types in the rte_comp_op
>>>>
>>>> union {
>>>> struct rte_comp_xform *xform;
>>>> /**< Immutable compress/decompress params */
>>>> void *pmd_stateless_data;
>>>> /**< Stateless private PMD data derived from an rte_comp_xform
>>>> * rte_comp_stateless_data_init() must be called on a device
>>>> * before sending any STATELESS operations. If the PMD returns a non-NULL
>>>> * value the handle must be attached to subsequent STATELESS operations.
>>>> * If a PMD returns NULL, then the xform should be passed directly to each op
>>>> */
>> [Shally] It sounds like stateless_data_init() nothing more than a replacement of session_init().
>> So, this is needed neither if we retain session concept nor if we retain stream concept ( rte_comp_stream_create() with
>op_type: stateless can serve same purpose).
>> It should be sufficient to provide either stream (or session) pointer.
>>
>>>> void *stream;
>>>> /* Private PMD data derived initially from an rte_comp_xform, which holds state
>>>> * and history data and evolves as operations are processed.
>>>> * rte_comp_stream_create() must be called on a device for all STATEFUL
>>>> * data streams and the resulting stream attached
>>>> * to the one or more operations associated with the data stream.
>>>> * All operations in a stream must be sent to the same device.
>>>> */
>>>> }
>>> [Ahmed] I like this setup, but I am not sure in what cases the xform
>>> immutable would be used. I understand the other two.
>> [Shally] my understanding is xform will be mapped by PMD to its internally managed stream(or session data structure). And then we
>can remove STATEFUL reference here and just say stream(or session) it belongs to. However, This condition still apply:
>> *All operations that belong to same stream must be sent to the same device.*
>>
>>>> Notes:
>>>> 1. Internally if a PMD wants to use the exact same data structure for both it can do,
>>>> just on the API I think it's better if they're named differently with
>>>> different comments.
>>>> 2. I'm not clear of the constraints if any, which attach to the pmd_stateless_data
>>>> For our PMD it would only hold immutable data as the session did, and so
>>>> could be attached to many ops in parallel.
>>>> Is this true for all PMDs or are there constraints which should be called out?
>>>> Is it limited to a specific device, qp, or to be used on one op at a time?
>>>> 3. Am open to other naming suggestions, just trying to capture the essence
>>>> of these data structs better than our current API does.
>>>>
>>>> We would put some more helper fns and structure around the above code if people
>>>> are in agreement, just want to see if the concept flies before going further?
>>>>
>>>> Fiona
>>>>
>>>>
>>>>
>>
next prev parent reply other threads:[~2018-02-27 5:53 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 18:25 Fiona Trahe
2018-02-04 14:18 ` Thomas Monjalon
2018-02-21 19:11 ` Trahe, Fiona
2018-02-24 1:17 ` Ahmed Mansour
2018-02-26 11:24 ` Trahe, Fiona
2018-02-26 19:15 ` Ahmed Mansour
2018-02-27 5:48 ` Verma, Shally
2018-02-26 11:25 ` Verma, Shally
2018-02-26 21:35 ` Ahmed Mansour
2018-02-27 5:53 ` Verma, Shally [this message]
2018-02-28 18:39 ` Trahe, Fiona
2018-03-01 6:58 ` Verma, Shally
2018-03-01 14:41 ` Trahe, Fiona
2018-03-02 0:55 ` Ahmed Mansour
2018-03-02 9:53 ` Trahe, Fiona
2018-03-02 19:48 ` Ahmed Mansour
2018-03-05 14:32 ` Verma, Shally
2018-03-06 23:33 ` Ahmed Mansour
2018-03-03 0:52 ` Ahmed Mansour
2018-02-04 14:24 ` Thomas Monjalon
2018-03-23 18:08 ` Trahe, Fiona
2018-03-24 1:02 ` Thomas Monjalon
2018-03-26 11:44 ` Trahe, Fiona
2018-03-27 16:04 ` [dpdk-dev] [PATCH v2 0/3] implement compression API Fiona Trahe
2018-04-06 18:04 ` [dpdk-dev] [PATCH v3 00/13] Implement " Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 01/13] compressdev: add basic device management Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 02/13] compressdev: add queue pair management Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 03/13] compressdev: add compression specific data Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 04/13] compressdev: add enqueue/dequeue functions Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 05/13] compressdev: add operation management Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 06/13] compressdev: support stateless operations Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 07/13] compressdev: support stateful operations Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 08/13] compressdev: support hash operations Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 09/13] compressdev: add device feature flags Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 10/13] compressdev: add compression service " Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 11/13] compressdev: add device stats Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 12/13] compressdev: add device capabilities Pablo de Lara
2018-04-06 18:05 ` [dpdk-dev] [PATCH v3 13/13] compressdev: get device id from name Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 00/13] Implement compression API Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 01/13] compressdev: add basic device management Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 02/13] compressdev: add queue pair management Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 03/13] compressdev: add compression specific data Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 04/13] compressdev: add enqueue/dequeue functions Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 05/13] compressdev: add operation management Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 06/13] compressdev: support stateless operations Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 07/13] compressdev: support stateful operations Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 08/13] compressdev: support hash operations Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 09/13] compressdev: add device feature flags Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 10/13] compressdev: add compression service " Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 11/13] compressdev: add device stats Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 12/13] compressdev: add device capabilities Pablo de Lara
2018-04-08 12:58 ` [dpdk-dev] [PATCH v4 13/13] compressdev: get device id from name Pablo de Lara
2018-03-27 16:04 ` [dpdk-dev] [PATCH v2 1/3] compressdev: add structs and enum for compression service Fiona Trahe
2018-03-27 16:04 ` [dpdk-dev] [PATCH v2 2/3] compressdev: implement API Fiona Trahe
2018-03-27 16:04 ` [dpdk-dev] [PATCH v2 3/3] doc: update doxy and release note for compressdev Fiona Trahe
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 00/13] Implement compression API Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 01/13] compressdev: add basic device management Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 02/13] compressdev: add queue pair management Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 03/13] compressdev: add compression specific data Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 04/13] compressdev: add enqueue/dequeue functions Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 05/13] compressdev: add operation management Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 06/13] compressdev: support stateless operations Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 07/13] compressdev: support stateful operations Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 08/13] compressdev: support hash operations Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 09/13] compressdev: add device feature flags Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 10/13] compressdev: add compression service " Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 11/13] compressdev: add device stats Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 12/13] compressdev: add device capabilities Pablo de Lara
2018-04-13 18:18 ` [dpdk-dev] [PATCH v5 13/13] compressdev: get device id from name Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 00/14] Implement compression API Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 01/14] compressdev: add basic device management Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 02/14] compressdev: add queue pair management Pablo de Lara
2018-05-04 2:48 ` Verma, Shally
2018-05-04 8:43 ` Trahe, Fiona
2018-05-14 7:53 ` Verma, Shally
2018-05-14 8:04 ` De Lara Guarch, Pablo
2018-05-14 8:16 ` Verma, Shally
2018-05-14 8:30 ` De Lara Guarch, Pablo
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 03/14] compressdev: add compression specific data Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 04/14] compressdev: add enqueue/dequeue functions Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 05/14] compressdev: add operation management Pablo de Lara
2018-04-27 13:23 ` [dpdk-dev] [PATCH v6 06/14] compressdev: support stateless operations Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 07/14] compressdev: support stateful operations Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 08/14] compressdev: support hash operations Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 09/14] compressdev: add device feature flags Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 10/14] compressdev: add compression service " Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 11/14] compressdev: add device stats Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 12/14] compressdev: add device capabilities Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 13/14] compressdev: get device id from name Pablo de Lara
2018-04-27 13:24 ` [dpdk-dev] [PATCH v6 14/14] doc: add compressdev library guide Pablo de Lara
2018-05-08 21:25 ` [dpdk-dev] [PATCH v6 00/14] Implement compression API 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=MWHPR0701MB364183B1F3D3E0AE0B5FF83CF0C00@MWHPR0701MB3641.namprd07.prod.outlook.com \
--to=shally.verma@cavium.com \
--cc=Ashish.Gupta@cavium.com \
--cc=Mahipal.Challa@cavium.com \
--cc=NarayanaPrasad.Athreya@cavium.com \
--cc=Sunila.Sahu@cavium.com \
--cc=ahmed.mansour@nxp.com \
--cc=deepak.k.jain@intel.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=roy.pledge@nxp.com \
--cc=youri.querry_1@nxp.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).