>>>>> 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? >> >> I agree. > > +1
Great, I'll prepare v2 patchset then. Will also start on prototyping possible rte_security macsec API. Regards, Igor
