[dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config

[Trahe, Fiona]

Hi Joseph,

> -----Original Message-----
> From: Anoob Joseph [mailto:anoobj at marvell.com]
> Sent: Thursday, January 17, 2019 9:40 AM
> To: Akhil Goyal <akhil.goyal at nxp.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Trahe,
> Fiona <fiona.trahe at intel.com>
> Cc: Anoob Joseph <anoobj at marvell.com>; Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Narayana
> Prasad Raju Athreya <pathreya at marvell.com>; Shally Verma <shallyv at marvell.com>; dev at dpdk.org
> Subject: [PATCH] doc: announce ABI change for cryptodev config
> 
> Add new field ff_enable in rte_cryptodev_config. This enables
> applications to control the features enabled on the crypto device.
> 
> Proposed new layout:
> 
> /** Crypto device configuration structure */
> struct rte_cryptodev_config {
>     int socket_id;            /**< Socket to allocate resources on */
>     uint16_t nb_queue_pairs;
>     /**< Number of queue pairs to configure on device */
> +   uint64_t ff_enable;
> +   /**< Feature flags to be enabled on the device. Only the features set
> +    * on rte_cryptodev_info.feature_flags are allowed to be set.
> +    */
> };
> 
> For eth devices, rte_eth_conf.rx_mode.offloads and
> rte_eth_conf.tx_mode.offloads fields are used by applications to
> control the offloads enabled on the eth device. This proposal adds a
> similar ability for the crypto device.
[Fiona] I'm unfamiliar with eth config so can you explain a bit more how this works?
e.g. if a crypto device's info says it supports  
RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING
RTE_CRYPTODEV_FF_CPU_AESNI
RTE_CRYPTODEV_FF_SECURITY
RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT
these things are all already enabled.
Is the param a way to disable some of them?
If so, it would be better to call it ff_disable.
And to limit it to the subset of features that it makes sense to disable.
i.e. why would an application disable chaining or any of the SGL flags? It would just add extra cycles
in the PMD to error check  on these cases, instead the appl can just not send such commands.
And it doesn't make sense to disable AESNI or RTE_CRYPTODEV_FF_HW_ACCELERATED.
Actually I can't see what an application would want to achieve by disabling any flag?