Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> Hi Ferruh,
> 
>>> +int
>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>> +			   uint8_t idx, uint8_t an,
>>> +			   uint32_t pn, uint8_t *key);
>>> +
>>>  
>>>  #include <rte_ethdev_core.h>
>>>  
>>
>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>> these didn't go through a proper review cycle, we didn't get any comment on any
>> other possible driver can use it, I am for postponing the series to next release.
>>
>> Also there are some mechanical issues [1] but main thing is adding a set of API
>> to late in release cycle without proper review.
> 
> I see, that's reasonable.
> 
> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> Two points here:
> 
> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> through the rte_security set of APIs. This obviously could be done, but with proper design
> of rte_security structures and ops.
> 
> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> of private driver API as it runs in ixgbe now. This code is functional and will not be
> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
> 

If there is a commitment to work on a generic solution for 19.08, involving
other users too, I would be OK to get the support as PMD API for this release.

If that is accepted, please bu sure too add experimental tag to new PMD APIs and
even add to release notes about intention and that the PMD specific APIs are
temporary. And if ABI breakage required, put any necessary deprecation notice
withing this release scope so that the development is not blocked for next release.

Thomas, Andrew, what do you think?