From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Ahmed Mansour <ahmed.mansour@nxp.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Shally.Verma@cavium.com" <Shally.Verma@cavium.com>
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>,
"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API
Date: Mon, 26 Feb 2018 11:24:55 +0000 [thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B435893279DB@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <DB3PR0402MB38526FF01E8A29D9CA8D70F1E1C30@DB3PR0402MB3852.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Ahmed Mansour [mailto:ahmed.mansour@nxp.com]
> Sent: Saturday, February 24, 2018 1:17 AM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Shally.Verma@cavium.com
> 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,
>
> 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.
[Fiona] Would 10:30 GMT on Wednesday 28th Feb suit?
>
> 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.
> >
> > 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
> > */
> > 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.
[Fiona] The xform is there because I don't know yet what limitations may apply to the
pmd_stateless_data. If it has no limitation and once set up once on a device
can be attached simultaneously to any op sent to any qp on that device
then we don't need the xform. But I understood from Shally's earlier request for
setting up a stream on a stateless request that some resources are
allocated, so we may need to document some limitations.
In this case the xform may be a better path for PMDs which don't have the same
limitations.
> > 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-26 11:25 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 [this message]
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
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=348A99DA5F5B7549AA880327E580B435893279DB@IRSMSX101.ger.corp.intel.com \
--to=fiona.trahe@intel.com \
--cc=Ashish.Gupta@cavium.com \
--cc=Mahipal.Challa@cavium.com \
--cc=NarayanaPrasad.Athreya@cavium.com \
--cc=Shally.Verma@cavium.com \
--cc=Sunila.Sahu@cavium.com \
--cc=ahmed.mansour@nxp.com \
--cc=deepak.k.jain@intel.com \
--cc=dev@dpdk.org \
--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).