[01/10] ethdev: introduce MACSEC device ops
diff mbox series

Message ID 69b3fcf19cb3e11fae93281f40a1bbc0ec5a2e38.1554894242.git.igor.russkikh@aquantia.com
State Changes Requested, archived
Delegated to: Ferruh Yigit
Headers show
Series
  • add MACSEC hw offload to atlantic PMD
Related show

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK
ci/intel-Performance-Testing fail Performance Testing issues
ci/mellanox-Performance-Testing success Performance Testing PASS

Commit Message

Igor Russkikh April 10, 2019, 11:18 a.m. UTC
MACSEC related device ops, API and parameters are taken from the
existing ixgbe PMD ops

Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
 lib/librte_ethdev/rte_ethdev.c      |  87 +++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev.h      | 115 ++++++++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev_core.h |  23 ++++++
 3 files changed, 225 insertions(+)

Comments

Thomas Monjalon April 10, 2019, 11:46 a.m. UTC | #1
10/04/2019 13:18, Igor Russkikh:
> MACSEC related device ops, API and parameters are taken from the
> existing ixgbe PMD ops

Please can you explain how it is related to rte_security?
Igor Russkikh April 11, 2019, 12:37 p.m. UTC | #2
Hello Thomas,

Thanks for the review!

On 10.04.2019 14:46, Thomas Monjalon wrote:
> 10/04/2019 13:18, Igor Russkikh:
>> MACSEC related device ops, API and parameters are taken from the
>> existing ixgbe PMD ops
> 
> Please can you explain how it is related to rte_security?

It is not.
Do you mean macsec control API could be moved and logically be a part of rte_security api?
I can't comment now on how feasible is this. Moreover this depends on how Intel considers
and uses the existing macsec offload in ixgbe.

> The generic API is implemented in ixgbe in next patch.
> You should reverse them, or completely move this patch at the end.

You are right, I'll swap them.

> Please merge such doc update in the patch enabling the feature.

Ok,

Thanks,
  Igor
Thomas Monjalon April 11, 2019, 9:15 p.m. UTC | #3
11/04/2019 14:37, Igor Russkikh:
> On 10.04.2019 14:46, Thomas Monjalon wrote:
> > 10/04/2019 13:18, Igor Russkikh:
> >> MACSEC related device ops, API and parameters are taken from the
> >> existing ixgbe PMD ops
> > 
> > Please can you explain how it is related to rte_security?
> 
> It is not.
> Do you mean macsec control API could be moved and logically be a part of rte_security api?
> I can't comment now on how feasible is this. Moreover this depends on how Intel considers
> and uses the existing macsec offload in ixgbe.

There are RTE_SECURITY_PROTOCOL_MACSEC and rte_security_macsec_* structs
in librte_security.
Please check how it can be used while defining an ethdev API.
Igor Russkikh April 12, 2019, 8:50 a.m. UTC | #4
>>> Please can you explain how it is related to rte_security?
>>
>> It is not.
>> Do you mean macsec control API could be moved and logically be a part of rte_security api?
>> I can't comment now on how feasible is this. Moreover this depends on how Intel considers
>> and uses the existing macsec offload in ixgbe.
> 
> There are RTE_SECURITY_PROTOCOL_MACSEC and rte_security_macsec_* structs
> in librte_security.
> Please check how it can be used while defining an ethdev API.

There is nothing in rte_security defined explicitly for macsec except that enum item.
All the macsec structures are dummy. Was there any intent to implement this?

I can writeup the generic macsec structures for rte_security, do you think that's feasible?

Regards,
  Igor
Thomas Monjalon April 12, 2019, 11:22 a.m. UTC | #5
12/04/2019 10:50, Igor Russkikh:
> 
> >>> Please can you explain how it is related to rte_security?
> >>
> >> It is not.
> >> Do you mean macsec control API could be moved and logically be a part of rte_security api?
> >> I can't comment now on how feasible is this. Moreover this depends on how Intel considers
> >> and uses the existing macsec offload in ixgbe.
> > 
> > There are RTE_SECURITY_PROTOCOL_MACSEC and rte_security_macsec_* structs
> > in librte_security.
> > Please check how it can be used while defining an ethdev API.
> 
> There is nothing in rte_security defined explicitly for macsec except that enum item.
> All the macsec structures are dummy. Was there any intent to implement this?
> 
> I can writeup the generic macsec structures for rte_security, do you think that's feasible?

I don't know. We are in front of a case of dead code
written well too far in advance.
Akhil, any suggestion?
Ferruh Yigit April 12, 2019, 6:26 p.m. UTC | #6
On 4/10/2019 12:18 PM, Igor Russkikh wrote:
> MACSEC related device ops, API and parameters are taken from the
> existing ixgbe PMD ops
> 
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>

<...>

> @@ -3872,6 +3872,121 @@ rte_eth_dev_pool_ops_supported(uint16_t port_id, const char *pool);
>  void *
>  rte_eth_dev_get_sec_ctx(uint16_t port_id);
>  
> +/**
> + * Enable MACsec offload.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param encr
> + *    1 - Enable encryption (encrypt and add integrity signature).
> + *    0 - Disable encryption (only add integrity signature).
> + * @param repl_prot
> + *    1 - Enable replay protection.
> + *    0 - Disable replay protection.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + */
> +int
> +rte_eth_macsec_enable(uint16_t port_id,
> +		      uint8_t encr, uint8_t repl_prot);
> +
> +/**
> + * Disable MACsec offload.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + */
> +int
> +rte_eth_macsec_disable(uint16_t port_id);
> +
> +/**
> + * Configure Rx SC (Secure Connection).
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param mac
> + *   The MAC address on the remote side.
> + * @param pi
> + *   The PI (port identifier) on the remote side.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + */
> +int
> +rte_eth_macsec_config_rxsc(uint16_t port_id,
> +			   uint8_t *mac, uint16_t pi);
> +
> +/**
> + * Configure Tx SC (Secure Connection).
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param mac
> + *   The MAC address on the local side.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + */
> +int
> +rte_eth_macsec_config_txsc(uint16_t port_id,
> +			   uint8_t *mac);
> +
> +/**
> + * Enable Rx SA (Secure Association).
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param idx
> + *   The SA to be enabled (0 or 1)
> + * @param an
> + *   The association number on the remote side.
> + * @param pn
> + *   The packet number on the remote side.
> + * @param key
> + *   The key on the remote side.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + *   - (-EINVAL) if bad parameter.
> + */
> +int
> +rte_eth_macsec_select_rxsa(uint16_t port_id,
> +			   uint8_t idx, uint8_t an,
> +			   uint32_t pn, uint8_t *key);
> +
> +/**
> + * Enable Tx SA (Secure Association).
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param idx
> + *   The SA to be enabled (0 or 1).
> + * @param an
> + *   The association number on the local side.
> + * @param pn
> + *   The packet number on the local side.
> + * @param key
> + *   The key on the local side.
> + * @return
> + *   - (0) if successful.
> + *   - (-ENODEV) if *port* invalid.
> + *   - (-ENOTSUP) if hardware doesn't support this feature.
> + *   - (-EINVAL) if bad parameter.
> + */
> +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.
Thomas, Andrew, what do you think?


[1]
- New APIs must be experimental
- Apis should be exported via linker file (.map)
Igor Russkikh April 13, 2019, 7:24 a.m. UTC | #7
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
Ferruh Yigit April 16, 2019, 9:43 a.m. UTC | #8
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?
Andrew Rybchenko April 16, 2019, 9:58 a.m. UTC | #9
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.
Thomas Monjalon April 16, 2019, 10:11 a.m. UTC | #10
16/04/2019 11:58, Andrew Rybchenko:
> 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.

+1
Igor Russkikh April 16, 2019, 10:19 a.m. UTC | #11
>>>>> 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

Patch
diff mbox series

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 243beb4dd5ef..315c31dc667d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -4367,6 +4367,93 @@  rte_eth_dev_pool_ops_supported(uint16_t port_id, const char *pool)
 	return (*dev->dev_ops->pool_ops_supported)(dev, pool);
 }
 
+int
+rte_eth_macsec_enable(uint16_t port_id,
+		      uint8_t encr, uint8_t repl_prot)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_enable, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_enable)
+				(dev, encr, repl_prot));
+}
+
+int
+rte_eth_macsec_disable(uint16_t port_id)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_disable, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_disable)
+				(dev));
+}
+
+int
+rte_eth_macsec_config_rxsc(uint16_t port_id,
+			   uint8_t *mac, uint16_t pi)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_config_rxsc, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_config_rxsc)
+				(dev, mac, pi));
+}
+
+int
+rte_eth_macsec_config_txsc(uint16_t port_id,
+			   uint8_t *mac)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_config_txsc, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_config_txsc)
+				(dev, mac));
+}
+
+int
+rte_eth_macsec_select_rxsa(uint16_t port_id,
+					uint8_t idx, uint8_t an,
+					uint32_t pn, uint8_t *key)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_select_rxsa, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_select_rxsa)
+				(dev, idx, an, pn, key));
+}
+
+int
+rte_eth_macsec_select_txsa(uint16_t port_id,
+					uint8_t idx, uint8_t an,
+					uint32_t pn, uint8_t *key)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->macsec_select_txsa, -ENOTSUP);
+	return eth_err(port_id, (*dev->dev_ops->macsec_select_txsa)
+				(dev, idx, an, pn, key));
+}
+
+
+
 /**
  * A set of values to describe the possible states of a switch domain.
  */
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 40a068fe8337..0e4e889653ad 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -3872,6 +3872,121 @@  rte_eth_dev_pool_ops_supported(uint16_t port_id, const char *pool);
 void *
 rte_eth_dev_get_sec_ctx(uint16_t port_id);
 
+/**
+ * Enable MACsec offload.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param encr
+ *    1 - Enable encryption (encrypt and add integrity signature).
+ *    0 - Disable encryption (only add integrity signature).
+ * @param repl_prot
+ *    1 - Enable replay protection.
+ *    0 - Disable replay protection.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int
+rte_eth_macsec_enable(uint16_t port_id,
+		      uint8_t encr, uint8_t repl_prot);
+
+/**
+ * Disable MACsec offload.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int
+rte_eth_macsec_disable(uint16_t port_id);
+
+/**
+ * Configure Rx SC (Secure Connection).
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param mac
+ *   The MAC address on the remote side.
+ * @param pi
+ *   The PI (port identifier) on the remote side.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int
+rte_eth_macsec_config_rxsc(uint16_t port_id,
+			   uint8_t *mac, uint16_t pi);
+
+/**
+ * Configure Tx SC (Secure Connection).
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param mac
+ *   The MAC address on the local side.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ */
+int
+rte_eth_macsec_config_txsc(uint16_t port_id,
+			   uint8_t *mac);
+
+/**
+ * Enable Rx SA (Secure Association).
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param idx
+ *   The SA to be enabled (0 or 1)
+ * @param an
+ *   The association number on the remote side.
+ * @param pn
+ *   The packet number on the remote side.
+ * @param key
+ *   The key on the remote side.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ *   - (-EINVAL) if bad parameter.
+ */
+int
+rte_eth_macsec_select_rxsa(uint16_t port_id,
+			   uint8_t idx, uint8_t an,
+			   uint32_t pn, uint8_t *key);
+
+/**
+ * Enable Tx SA (Secure Association).
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param idx
+ *   The SA to be enabled (0 or 1).
+ * @param an
+ *   The association number on the local side.
+ * @param pn
+ *   The packet number on the local side.
+ * @param key
+ *   The key on the local side.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENODEV) if *port* invalid.
+ *   - (-ENOTSUP) if hardware doesn't support this feature.
+ *   - (-EINVAL) if bad parameter.
+ */
+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>
 
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index 8f03f83f62cf..6434a9065756 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -377,6 +377,20 @@  typedef int (*eth_pool_ops_supported_t)(struct rte_eth_dev *dev,
 						const char *pool);
 /**< @internal Test if a port supports specific mempool ops */
 
+typedef int (*eth_macsec_enable_t)(struct rte_eth_dev *dev,
+				   uint8_t encr, uint8_t repl_prot);
+typedef int (*eth_macsec_disable_t)(struct rte_eth_dev *dev);
+typedef int (*eth_macsec_config_rxsc_t)(struct rte_eth_dev *dev,
+					uint8_t *mac, uint16_t pi);
+typedef int (*eth_macsec_config_txsc_t)(struct rte_eth_dev *dev,
+					uint8_t *mac);
+typedef int (*eth_macsec_select_rxsa_t)(struct rte_eth_dev *dev,
+					uint8_t idx, uint8_t an,
+					uint32_t pn, uint8_t *key);
+typedef int (*eth_macsec_select_txsa_t)(struct rte_eth_dev *dev,
+					uint8_t idx, uint8_t an,
+					uint32_t pn, uint8_t *key);
+
 /**
  * @internal A structure containing the functions exported by an Ethernet driver.
  */
@@ -509,6 +523,15 @@  struct eth_dev_ops {
 
 	eth_pool_ops_supported_t pool_ops_supported;
 	/**< Test if a port supports specific mempool ops */
+
+	eth_macsec_enable_t macsec_enable; /** macsec function enable */
+	eth_macsec_disable_t macsec_disable; /** macsec function disable */
+	eth_macsec_config_rxsc_t macsec_config_rxsc; /** macsec configure rx */
+	eth_macsec_config_txsc_t macsec_config_txsc; /** macsec configure tx */
+	eth_macsec_select_rxsa_t macsec_select_rxsa;
+	/** macsec select rx security association */
+	eth_macsec_select_txsa_t macsec_select_txsa;
+	/** macsec select tx security association */
 };
 
 /**