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.
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.
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.
*/
}
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
