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. Thanks for the review, Regards, Igor
