-----Original Message----- From: Dmitry Eremin-Solenikov [mailto:[email protected]] Sent: 23 May 2017 20:54 To: Shally Verma <[email protected]>; [email protected] Cc: Challa, Mahipal <[email protected]>; Narayana, Prasad Athreya <[email protected]>; Verma, Shally <[email protected]> Subject: Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
On 22.05.2017 09:54, Shally Verma wrote: > Signed-off-by: Shally Verma <[email protected]> > Signed-off-by: Mahipal Challa <[email protected]> > +/** > + * Comp API operation return codes > + * > + */ > +typedef enum { > + /** Operation completed successfully*/ > + ODP_COMP_ERR_NONE, > + /** Invalid user data pointers*/ > + ODP_COMP_ERR_DATA_PTR, > + /** Invalid input data size*/ > + ODP_COMP_ERR_DATA_SIZE, > + /** Compression and/or hash Algo failure*/ > + ODP_COMP_ERR_ALGO_FAIL, > + /** Operation paused due to insufficient output buffer. > + * > + * This is not an error condition. On seeing this situation, > + * Implementation should maintain context of in-progress operation and > + * application should call packet processing API again with valid > + * output buffer but no other altercation to operation params Probably you've ment alteration here? Ya. My bad. Thanks for pointing that. > + * (odp_comp_op_param_t). > + * > + * if using async mode, application should either make sure to > + * provide sufficient output buffer size OR maintain relevant > + * context (or ordering) information with respect to each input packet > + * enqueued for processing > + * > + */ > + ODP_COMP_ERR_OUT_OF_SPACE, > + /** Error if operation has been requested in an invalid state */ > + ODP_COMP_ERR_INV_STATE, > + /** Error if API call does not input params or mode. */ > + ODP_COMP_ERR_NOT_SUPPORTED > +} odp_comp_err_t; [...] > +typedef struct odp_comp_capability_t { > + /** Maximum number of sessions*/ > + uint32_t max_sessions; > + > + /** Supported compression algorithms*/ > + odp_comp_algos_t comps; > + > + /** Supported hash algorithms*/ > + odp_comp_hash_algos_t hash; > + > + /** Support level for synchrnous operation mode (ODP_COMP_SYNC) > + * User should set odp_comp_session_param_t:mode based on > + * support level as indicated by this param. > + * true - mode supported, > + * false - mode not supported True/false part is no longer relevant Ack. Will rectify. > + */ > + odp_support_t sync; > + > + /** Support level for asynchrnous operation mode (ODP_COMP_ASYNC) > + * User should set odp_comp_session_param_t:mode param based on > + * support level as indicated by this param. > + * true - mode supported, > + * false - mode not supported Same Ack. > + * > + */ > + odp_support_t async; > +} odp_comp_capability_t; > + > +/** > + * Hash algorithm capabilities > + * > + */ > +typedef struct odp_comp_hash_alg_capability_t { > + /** Digest length in bytes */ > + uint32_t digest_len; > +} odp_comp_hash_alg_capability_t; > + > +/** > + * Compression algorithm capabilities > + * structure for each algorithm. > + * > + */ > +typedef struct odp_comp_alg_capability_t { > + /** Boolean indicating alg support dictionary load > + * > + * true: yes > + * false : no > + * > + * dictionary , if supported, consists of a pointer to character > + * array > + */ > + odp_bool_t support_dict; Can you switch to odp_support_t here? Ack. > +/** > + * Comp API algorithm specific parameters > + * > + */ > +typedef struct odp_comp_alg_param_t { > + struct comp_alg_def_param { > + /** compression level where > + ODP_COMP_LEVEL_MIN <= level <= ODP_COMP_LEVEL_MAX > + */ > + odp_comp_level_t level; > + /** huffman code to use */ > + odp_comp_huffman_code_t comp_code; > + } deflate; > + struct comp_alg_zlib_param { > + /** deflate algo params */ > + struct comp_alg_def_param def; > + } zlib; > +} odp_comp_alg_param_t; Would it be more logical to change this to union? No. I need this as structure as I can anticipate many other having deflate as one of the field. > + > +/** > + * Comp API data range specifier > + * > + */ > +typedef union odp_comp_data_t { > + struct odp_comp_pkt { > + /** Offset from beginning of input */ > + odp_packet_t packet; > + > + /** Length of data to operate on */ > + odp_packet_data_range_t data_range; > + } packet; > +} odp_comp_data_t; The plan is probably to support buf+len here? Yes. At later stage. Thanks Shally I have to think about this. -- With best wishes Dmitry
