DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pavel Belous <Pavel.Belous@aquantia.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
	Akhil Goyal <akhil.goyal@nxp.com>,
	 John McNamara <john.mcnamara@intel.com>,
	Declan Doherty <declan.doherty@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Igor Russkikh <Igor.Russkikh@aquantia.com>,
	Fenilkumar Patel <fenpatel@cisco.com>,
	 Hitesh K Maisheri <hmaisher@cisco.com>,
	Pavel Belous <Pavel.Belous@aquantia.com>
Subject: [dpdk-dev] [RFC v2 0/7] RFC: Support MACSEC offload in the RTE_SECURITY infrastructure.
Date: Fri, 25 Oct 2019 17:53:49 +0000	[thread overview]
Message-ID: <cover.1571928488.git.Pavel.Belous@aquantia.com> (raw)

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

-- 
2.7.4


             reply	other threads:[~2019-10-25 17:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 17:53 Pavel Belous [this message]
2019-10-25 17:53 ` [dpdk-dev] [RFC v2 1/7] security: MACSEC infrastructure data declarations Pavel Belous
2019-10-25 17:53 ` [dpdk-dev] [RFC v2 2/7] security: Update rte_security documentation Pavel Belous
2019-10-25 17:53 ` [dpdk-dev] [RFC v2 3/7] net/atlantic: Add helper functions for PHY access Pavel Belous
2019-10-25 17:54 ` [dpdk-dev] [RFC v2 4/7] net/atlantic: add MACSEC internal HW data declaration and functions Pavel Belous
2019-10-25 17:54 ` [dpdk-dev] [RFC v2 5/7] net/atlantic: implementation of the MACSEC using rte_security interface Pavel Belous
2019-10-25 17:54 ` [dpdk-dev] [RFC v2 6/7] app/testpmd: macsec on/off commands " Pavel Belous
2019-10-25 19:01   ` Stephen Hemminger
2019-10-25 19:02   ` Stephen Hemminger
2019-10-25 17:54 ` [dpdk-dev] [RFC v2 7/7] app/testpmd: macsec adding RX/TX SC " Pavel Belous
2020-01-27 11:25 ` [dpdk-dev] [RFC v2 0/7] RFC: Support MACSEC offload in the RTE_SECURITY infrastructure Akhil Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1571928488.git.Pavel.Belous@aquantia.com \
    --to=pavel.belous@aquantia.com \
    --cc=Igor.Russkikh@aquantia.com \
    --cc=akhil.goyal@nxp.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fenpatel@cisco.com \
    --cc=ferruh.yigit@intel.com \
    --cc=hmaisher@cisco.com \
    --cc=john.mcnamara@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).