On 4/16/19 12:43 PM, Ferruh Yigit wrote:
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?
I agree.
