[RFC,v2,0/7] RFC: Support MACSEC offload in the RTE_SECURITY infrastructure.

  From: Pavel Belous <Pavel.Belous@aquantia.com>

This RFC suggest possible API to implement generic MACSEC HW
offload in DPDK infrastructure.

Right now two PMDs implementing MACSEC hw offload via private
API: ixgbe (Intel) and atlantic (Aquantia).

During that private API discussion it was decided to go further
with well defined public API, based most probably on rte_security
infrastructure.

Here is that previous discussion:

http://inbox.dpdk.org/dev/20190416101145.nVecHKp3w14Ptd_hne-DqHhKyzbre88PwNI-OAowXJM@z/

Declaring macsec API via rte_security gives a good data-centric view on parameters
and operations macsec supports. Old, pure functional API (basically ixbe only API)
presented function calls with big argument lists which is hard to extend and analyse.

However, I'd like to note rte_security has to be used via explicitly created
mempools - this hardens abit the usage.
It also may be hard to extend the structures in the ABI compatible way.

One of the problems with MACSEC is that internally implementation and hardware
support could be either very simple, doing only endpoint encryption with a single
TX SC (Secure Connection), or quite complex, capable to do flexible filtering
and SC matching based on mac, vlan, ethertype and other.

Different macsec hardware supports some custom features and from our experience
users would like to configure these as well. Therefore there will probably be
needed a number of PMD specific macsec operators support.

Examples include: custom in-the-clear tag (matched by vlan id or mask),
configurable internal logic to allow both secure and unsecure traffic,
bypass filters on specific ethertypes.
To support such extensions, suggest use rte_security_macsec_op enum with
vendor specific operation codes.

In context of rte_security, MACSEC operations should normally be based on
security session create and update calls.

Session create is used to setup overall session. Thats equivalent of old
`macsec enable` operation.

Session update is used to update security connections and associations.
Here xform->op contains the required operation: rx/tx session/association
add/update/removal.

This RFC contains:
- patch 1-2 is rte_security data structures declaration and documentation
- patches 3-5 MACSEC implementation for atlantic (Aquantia) driver, using
  new rte_security interface.
- patches 6-7 is a draft on how testpmd based invocations of rte_security
  API will look like

To be done/decide:
- add missing documentation and comments to all the structures
- full testpmd macsec API adoption
- ixgbe api adoptation
- decide on how to declare SA (Security Associations) auto rollover and
  some other important features.
- interrupt event callback detalization of possible macsec events.
  Notice that it is not a part of rte_security, but a part of rte_ethdev.
- add ability to retrieve MACSEC statistics per individual SC/SA.

Pavel Belous (7):
  security: MACSEC infrastructure data declarations
  security: Update rte_security documentation
  net/atlantic: Add helper functions for PHY access
  net/atlantic: add MACSEC internal HW data declaration and functions
  net/atlantic: implementation of the MACSEC using rte_security
    interface
  app/testpmd: macsec on/off commands using rte_security interface
  app/testpmd: macsec adding RX/TX SC using rte_security interface

 app/test-pmd/Makefile                              |    1 +
 app/test-pmd/cmdline.c                             |   20 +-
 app/test-pmd/macsec.c                              |  138 ++
 app/test-pmd/macsec.h                              |   14 +
 app/test-pmd/meson.build                           |    3 +-
 doc/guides/prog_guide/rte_security.rst             |    4 -
 drivers/net/atlantic/Makefile                      |    5 +-
 drivers/net/atlantic/atl_ethdev.c                  |  316 +---
 drivers/net/atlantic/atl_sec.c                     |  615 ++++++++
 drivers/net/atlantic/atl_sec.h                     |  124 ++
 drivers/net/atlantic/hw_atl/hw_atl_utils.h         |  116 +-
 drivers/net/atlantic/macsec/MSS_Egress_registers.h | 1498 ++++++++++++++++++
 .../net/atlantic/macsec/MSS_Ingress_registers.h    | 1135 ++++++++++++++
 drivers/net/atlantic/macsec/macsec_api.c           | 1612 ++++++++++++++++++++
 drivers/net/atlantic/macsec/macsec_api.h           |  111 ++
 drivers/net/atlantic/macsec/macsec_struct.h        |  269 ++++
 drivers/net/atlantic/macsec/mdio.c                 |  328 ++++
 drivers/net/atlantic/macsec/mdio.h                 |   19 +
 drivers/net/atlantic/meson.build                   |    6 +-
 drivers/net/atlantic/rte_pmd_atlantic.c            |  102 --
 drivers/net/atlantic/rte_pmd_atlantic.h            |  144 --
 drivers/net/atlantic/rte_pmd_atlantic_version.map  |   16 -
 lib/librte_security/rte_security.h                 |  143 +-
 23 files changed, 6080 insertions(+), 659 deletions(-)
 create mode 100644 app/test-pmd/macsec.c
 create mode 100644 app/test-pmd/macsec.h
 create mode 100644 drivers/net/atlantic/atl_sec.c
 create mode 100644 drivers/net/atlantic/atl_sec.h
 create mode 100644 drivers/net/atlantic/macsec/MSS_Egress_registers.h
 create mode 100644 drivers/net/atlantic/macsec/MSS_Ingress_registers.h
 create mode 100644 drivers/net/atlantic/macsec/macsec_api.c
 create mode 100644 drivers/net/atlantic/macsec/macsec_api.h
 create mode 100644 drivers/net/atlantic/macsec/macsec_struct.h
 create mode 100644 drivers/net/atlantic/macsec/mdio.c
 create mode 100644 drivers/net/atlantic/macsec/mdio.h
 delete mode 100644 drivers/net/atlantic/rte_pmd_atlantic.c
 delete mode 100644 drivers/net/atlantic/rte_pmd_atlantic.h
 delete mode 100644 drivers/net/atlantic/rte_pmd_atlantic_version.map
  

Hi Pavel,

> From: Pavel Belous <Pavel.Belous@aquantia.com>
> 
> This RFC suggest possible API to implement generic MACSEC HW
> offload in DPDK infrastructure.
> 
> Right now two PMDs implementing MACSEC hw offload via private
> API: ixgbe (Intel) and atlantic (Aquantia).
> 
> During that private API discussion it was decided to go further
> with well defined public API, based most probably on rte_security
> infrastructure.
> 
> Here is that previous discussion:
> 
> http://inbox.dpdk.org/dev/20190416101145.nVecHKp3w14Ptd_hne-DqHhKyzbre88PwNI-OAowXJM@z/
> 
> Declaring macsec API via rte_security gives a good data-centric view on
> parameters
> and operations macsec supports. Old, pure functional API (basically ixbe only API)
> presented function calls with big argument lists which is hard to extend and
> analyse.
> 
> However, I'd like to note rte_security has to be used via explicitly created
> mempools - this hardens abit the usage.
> It also may be hard to extend the structures in the ABI compatible way.
> 
> One of the problems with MACSEC is that internally implementation and
> hardware
> support could be either very simple, doing only endpoint encryption with a single
> TX SC (Secure Connection), or quite complex, capable to do flexible filtering
> and SC matching based on mac, vlan, ethertype and other.
> 
> Different macsec hardware supports some custom features and from our
> experience
> users would like to configure these as well. Therefore there will probably be
> needed a number of PMD specific macsec operators support.
> 
> Examples include: custom in-the-clear tag (matched by vlan id or mask),
> configurable internal logic to allow both secure and unsecure traffic,
> bypass filters on specific ethertypes.
> To support such extensions, suggest use rte_security_macsec_op enum with
> vendor specific operation codes.
> 
> In context of rte_security, MACSEC operations should normally be based on
> security session create and update calls.
> 
> Session create is used to setup overall session. Thats equivalent of old
> `macsec enable` operation.
> 
> Session update is used to update security connections and associations.
> Here xform->op contains the required operation: rx/tx session/association
> add/update/removal.
> 

The patches look good from rte_security perspective. You can send the formal
Patches for 20.05 window.