[dpdk-dev] crypto drivers in the API

[dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

In the crypto API, the drivers are listed.
In my opinion, it is a wrong designed and these lists should be removed.
Do we need a deprecation notice to plan this removal in 17.05, while
working on bus abstraction?


lib/librte_cryptodev/rte_cryptodev.h:

#define CRYPTODEV_NAME_NULL_PMD     crypto_null
/**< Null crypto PMD device name */
#define CRYPTODEV_NAME_AESNI_MB_PMD crypto_aesni_mb
/**< AES-NI Multi buffer PMD device name */
#define CRYPTODEV_NAME_AESNI_GCM_PMD    crypto_aesni_gcm
/**< AES-NI GCM PMD device name */
#define CRYPTODEV_NAME_OPENSSL_PMD  crypto_openssl
/**< Open SSL Crypto PMD device name */
#define CRYPTODEV_NAME_QAT_SYM_PMD  crypto_qat
/**< Intel QAT Symmetric Crypto PMD device name */
#define CRYPTODEV_NAME_SNOW3G_PMD   crypto_snow3g
/**< SNOW 3G PMD device name */
#define CRYPTODEV_NAME_KASUMI_PMD   crypto_kasumi
/**< KASUMI PMD device name */
#define CRYPTODEV_NAME_ZUC_PMD      crypto_zuc
/**< KASUMI PMD device name */
#define CRYPTODEV_NAME_ARMV8_PMD    crypto_armv8
/**< ARMv8 Crypto PMD device name */
#define CRYPTODEV_NAME_SCHEDULER_PMD    crypto_scheduler
/**< Scheduler Crypto PMD device name */

/** Crypto device type */
enum rte_cryptodev_type {
    RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
    RTE_CRYPTODEV_AESNI_GCM_PMD,    /**< AES-NI GCM PMD */
    RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
    RTE_CRYPTODEV_QAT_SYM_PMD,  /**< QAT PMD Symmetric Crypto */
    RTE_CRYPTODEV_SNOW3G_PMD,   /**< SNOW 3G PMD */
    RTE_CRYPTODEV_KASUMI_PMD,   /**< KASUMI PMD */
    RTE_CRYPTODEV_ZUC_PMD,      /**< ZUC PMD */
    RTE_CRYPTODEV_OPENSSL_PMD,    /**<  OpenSSL PMD */
    RTE_CRYPTODEV_ARMV8_PMD,    /**< ARMv8 crypto PMD */
    RTE_CRYPTODEV_SCHEDULER_PMD,    /**< Crypto Scheduler PMD */
};

Re: [dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

(resent to fix email address)
2017-02-13 14:25, Thomas Monjalon:
> In the crypto API, the drivers are listed.
> In my opinion, it is a wrong designed and these lists should be removed.
> Do we need a deprecation notice to plan this removal in 17.05, while
> working on bus abstraction?
> 
> 
> lib/librte_cryptodev/rte_cryptodev.h:
> 
> #define CRYPTODEV_NAME_NULL_PMD     crypto_null
> /**< Null crypto PMD device name */
> #define CRYPTODEV_NAME_AESNI_MB_PMD crypto_aesni_mb
> /**< AES-NI Multi buffer PMD device name */
> #define CRYPTODEV_NAME_AESNI_GCM_PMD    crypto_aesni_gcm
> /**< AES-NI GCM PMD device name */
> #define CRYPTODEV_NAME_OPENSSL_PMD  crypto_openssl
> /**< Open SSL Crypto PMD device name */
> #define CRYPTODEV_NAME_QAT_SYM_PMD  crypto_qat
> /**< Intel QAT Symmetric Crypto PMD device name */
> #define CRYPTODEV_NAME_SNOW3G_PMD   crypto_snow3g
> /**< SNOW 3G PMD device name */
> #define CRYPTODEV_NAME_KASUMI_PMD   crypto_kasumi
> /**< KASUMI PMD device name */
> #define CRYPTODEV_NAME_ZUC_PMD      crypto_zuc
> /**< KASUMI PMD device name */
> #define CRYPTODEV_NAME_ARMV8_PMD    crypto_armv8
> /**< ARMv8 Crypto PMD device name */
> #define CRYPTODEV_NAME_SCHEDULER_PMD    crypto_scheduler
> /**< Scheduler Crypto PMD device name */
> 
> /** Crypto device type */
> enum rte_cryptodev_type {
>     RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
>     RTE_CRYPTODEV_AESNI_GCM_PMD,    /**< AES-NI GCM PMD */
>     RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
>     RTE_CRYPTODEV_QAT_SYM_PMD,  /**< QAT PMD Symmetric Crypto */
>     RTE_CRYPTODEV_SNOW3G_PMD,   /**< SNOW 3G PMD */
>     RTE_CRYPTODEV_KASUMI_PMD,   /**< KASUMI PMD */
>     RTE_CRYPTODEV_ZUC_PMD,      /**< ZUC PMD */
>     RTE_CRYPTODEV_OPENSSL_PMD,    /**<  OpenSSL PMD */
>     RTE_CRYPTODEV_ARMV8_PMD,    /**< ARMv8 crypto PMD */
>     RTE_CRYPTODEV_SCHEDULER_PMD,    /**< Crypto Scheduler PMD */
> };

Re: [dpdk-dev] crypto drivers in the API

[Doherty, Declan]

On 13/02/2017 1:25 PM, Thomas Monjalon wrote:
> In the crypto API, the drivers are listed.
> In my opinion, it is a wrong designed and these lists should be removed.
> Do we need a deprecation notice to plan this removal in 17.05, while
> working on bus abstraction?
>
...
>

Hey Thomas,
I agree that these need to be removed, and I had planned on doing this 
for 17.05 but I have a concern on the requirements for ABI breakage in 
relation to this. This enum is unfortunately used in both the 
rte_cryptodev and rte_crypto_sym_session structures which are part of 
the libraries public API. I don't think it would be feasible to maintain 
a set of 17.02 compatible APIs with the changes this would introduce, as 
it would require a large number of functions to have 2 versions? Is it 
OK to break the ABI for this case?

Re: [dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

2017-02-14 10:44, Doherty, Declan:
> On 13/02/2017 1:25 PM, Thomas Monjalon wrote:
> > In the crypto API, the drivers are listed.
> > In my opinion, it is a wrong designed and these lists should be removed.
> > Do we need a deprecation notice to plan this removal in 17.05, while
> > working on bus abstraction?
> >
> ...
> >
> 
> Hey Thomas,
> I agree that these need to be removed, and I had planned on doing this 
> for 17.05 but I have a concern on the requirements for ABI breakage in 
> relation to this. This enum is unfortunately used in both the 
> rte_cryptodev and rte_crypto_sym_session structures which are part of 
> the libraries public API. I don't think it would be feasible to maintain 
> a set of 17.02 compatible APIs with the changes this would introduce, as 
> it would require a large number of functions to have 2 versions? Is it 
> OK to break the ABI for this case?

Yes
If you were planning to do this, you should have sent a deprecation notice
few weeks ago.
Please send it now and we'll see if we have enough supporters shortly.

Re: [dpdk-dev] crypto drivers in the API

[Doherty, Declan]

On 14/02/2017 11:04 AM, Thomas Monjalon wrote:
> 2017-02-14 10:44, Doherty, Declan:
>> On 13/02/2017 1:25 PM, Thomas Monjalon wrote:
>>> In the crypto API, the drivers are listed.
>>> In my opinion, it is a wrong designed and these lists should be removed.
>>> Do we need a deprecation notice to plan this removal in 17.05, while
>>> working on bus abstraction?
>>>
>> ...
>>>
...
>
> Yes
> If you were planning to do this, you should have sent a deprecation notice
> few weeks ago.
> Please send it now and we'll see if we have enough supporters shortly.
>

Thomas, there are a couple of other changes we are looking at in the 
cryptodev which would require API changes as well as break ABI including 
adding support for a multi-device sessions, and changes to crypto 
operation layout and field changes for performance but these but will 
require RFCs or at least more discussion of the proposals. Given the 
time constrains for the V1 deadline for 17.05 I would prefer to work on 
the RFCs and get them out as soon as possible over the next few weeks 
and then make all the ABI breaking changes in R17.08 in a single release.

Otherwise we will end up breaking ABI 2 release in a row which I would 
like to avoid if possible.

Re: [dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

2017-02-14 14:46, Doherty, Declan:
> On 14/02/2017 11:04 AM, Thomas Monjalon wrote:
> > 2017-02-14 10:44, Doherty, Declan:
> >> On 13/02/2017 1:25 PM, Thomas Monjalon wrote:
> >>> In the crypto API, the drivers are listed.
> >>> In my opinion, it is a wrong designed and these lists should be removed.
> >>> Do we need a deprecation notice to plan this removal in 17.05, while
> >>> working on bus abstraction?
> >>>
> >> ...
> >>>
> ...
> >
> > Yes
> > If you were planning to do this, you should have sent a deprecation notice
> > few weeks ago.
> > Please send it now and we'll see if we have enough supporters shortly.
> >
> 
> Thomas, there are a couple of other changes we are looking at in the 
> cryptodev which would require API changes as well as break ABI including 
> adding support for a multi-device sessions, and changes to crypto 
> operation layout and field changes for performance but these but will 
> require RFCs or at least more discussion of the proposals. Given the 
> time constrains for the V1 deadline for 17.05 I would prefer to work on 
> the RFCs and get them out as soon as possible over the next few weeks 
> and then make all the ABI breaking changes in R17.08 in a single release.
> 
> Otherwise we will end up breaking ABI 2 release in a row which I would 
> like to avoid if possible.

OK, seems good. Thanks