[v2,00/15] add OCTEONTX2 inline IPsec support

This series adds inline IPsec support in OCTEONTX2 PMD.

In the inbound path, rte_flow framework need to be used to configure
the NPC block, which does the h/w lookup. The packets would get
processed by the crypto block and would submit to the scheduling block,
SSO. So inline IPsec mode can be enabled only when traffic is received
via event device using Rx adapter.

In the outbound path, the core would submit to the crypto block and the
crypto block would submit the packet for Tx internally.

v2:
* Minimized additions to common/octeontx2
* Updated release notes
* Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable

Ankur Dwivedi (3):
  crypto/octeontx2: add eth security capabilities
  crypto/octeontx2: add datapath ops in eth security ctx
  crypto/octeontx2: add inline tx path changes

Anoob Joseph (4):
  common/octeontx2: add CPT LF mbox for inline inbound
  crypto/octeontx2: create eth security ctx
  crypto/octeontx2: enable CPT to share QP with ethdev
  crypto/octeontx2: add eth security session operations

Archana Muniganti (3):
  crypto/octeontx2: add lookup mem changes to hold sa indices
  drivers/octeontx2: add sec in compiler optimized RX fastpath framework
  drivers/octeontx2: add sec in compiler optimized TX fastpath framework

Tejasree Kondoj (3):
  crypto/octeontx2: configure for inline IPsec
  crypto/octeontx2: add security in eth dev configure
  net/octeontx2: add inline ipsec rx path changes

Vamsi Attunuru (2):
  common/octeontx2: add routine to check if sec capable otx2
  crypto/octeontx2: sync inline tag type cfg with Rx adapter
    configuration

 doc/guides/nics/octeontx2.rst                      |  20 +
 doc/guides/rel_notes/release_20_02.rst             |   9 +
 drivers/common/octeontx2/otx2_common.c             |  22 +
 drivers/common/octeontx2/otx2_common.h             |  22 +
 drivers/common/octeontx2/otx2_mbox.h               |   7 +
 .../octeontx2/rte_common_octeontx2_version.map     |   3 +
 drivers/crypto/octeontx2/Makefile                  |   7 +-
 drivers/crypto/octeontx2/meson.build               |   7 +-
 drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
 .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
 drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
 drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
 drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
 drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
 drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
 drivers/crypto/octeontx2/otx2_security.c           | 870 +++++++++++++++++++++
 drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
 drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
 drivers/event/octeontx2/Makefile                   |   1 +
 drivers/event/octeontx2/meson.build                |   5 +-
 drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
 drivers/event/octeontx2/otx2_evdev.h               |   4 +-
 drivers/event/octeontx2/otx2_worker.c              |   6 +-
 drivers/event/octeontx2/otx2_worker.h              |   6 +
 drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
 drivers/net/octeontx2/Makefile                     |   1 +
 drivers/net/octeontx2/meson.build                  |   3 +
 drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
 drivers/net/octeontx2/otx2_ethdev.h                |   2 +
 drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
 drivers/net/octeontx2/otx2_flow.c                  |  26 +
 drivers/net/octeontx2/otx2_lookup.c                |  11 +-
 drivers/net/octeontx2/otx2_rx.c                    |  27 +-
 drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
 drivers/net/octeontx2/otx2_tx.c                    |  29 +-
 drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
 36 files changed, 2556 insertions(+), 283 deletions(-)
 create mode 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
 create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
 create mode 100644 drivers/crypto/octeontx2/otx2_security.c
 create mode 100644 drivers/crypto/octeontx2/otx2_security.h
 create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
  

On Sat, Jan 18, 2020 at 4:19 PM Anoob Joseph <anoobj@marvell.com> wrote:
>
> This series adds inline IPsec support in OCTEONTX2 PMD.
>
> In the inbound path, rte_flow framework need to be used to configure
> the NPC block, which does the h/w lookup. The packets would get
> processed by the crypto block and would submit to the scheduling block,
> SSO. So inline IPsec mode can be enabled only when traffic is received
> via event device using Rx adapter.
>
> In the outbound path, the core would submit to the crypto block and the
> crypto block would submit the packet for Tx internally.


Please fix following check-git-log.sh issues.

Wrong headline lowercase:
        net/octeontx2: add inline ipsec rx path changes
        drivers/octeontx2: add sec in compiler optimized RX fastpath framework
        drivers/octeontx2: add sec in compiler optimized TX fastpath framework
        crypto/octeontx2: add inline tx path changes
Headline too long:
        drivers/octeontx2: add sec in compiler optimized RX fastpath framework
        drivers/octeontx2: add sec in compiler optimized TX fastpath framework
        crypto/octeontx2: sync inline tag type cfg with Rx adapter configuration

Changing to Rx and Tx will fix most of the issues.



> v2:
> * Minimized additions to common/octeontx2
> * Updated release notes
> * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
>
> Ankur Dwivedi (3):
>   crypto/octeontx2: add eth security capabilities
>   crypto/octeontx2: add datapath ops in eth security ctx
>   crypto/octeontx2: add inline tx path changes
>
> Anoob Joseph (4):
>   common/octeontx2: add CPT LF mbox for inline inbound
>   crypto/octeontx2: create eth security ctx
>   crypto/octeontx2: enable CPT to share QP with ethdev
>   crypto/octeontx2: add eth security session operations
>
> Archana Muniganti (3):
>   crypto/octeontx2: add lookup mem changes to hold sa indices
>   drivers/octeontx2: add sec in compiler optimized RX fastpath framework
>   drivers/octeontx2: add sec in compiler optimized TX fastpath framework
>
> Tejasree Kondoj (3):
>   crypto/octeontx2: configure for inline IPsec
>   crypto/octeontx2: add security in eth dev configure
>   net/octeontx2: add inline ipsec rx path changes
>
> Vamsi Attunuru (2):
>   common/octeontx2: add routine to check if sec capable otx2
>   crypto/octeontx2: sync inline tag type cfg with Rx adapter
>     configuration
>
>  doc/guides/nics/octeontx2.rst                      |  20 +
>  doc/guides/rel_notes/release_20_02.rst             |   9 +
>  drivers/common/octeontx2/otx2_common.c             |  22 +
>  drivers/common/octeontx2/otx2_common.h             |  22 +
>  drivers/common/octeontx2/otx2_mbox.h               |   7 +
>  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
>  drivers/crypto/octeontx2/Makefile                  |   7 +-
>  drivers/crypto/octeontx2/meson.build               |   7 +-
>  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
>  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
>  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
>  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
>  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
>  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
>  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
>  drivers/crypto/octeontx2/otx2_security.c           | 870 +++++++++++++++++++++
>  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
>  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
>  drivers/event/octeontx2/Makefile                   |   1 +
>  drivers/event/octeontx2/meson.build                |   5 +-
>  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
>  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
>  drivers/event/octeontx2/otx2_worker.c              |   6 +-
>  drivers/event/octeontx2/otx2_worker.h              |   6 +
>  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
>  drivers/net/octeontx2/Makefile                     |   1 +
>  drivers/net/octeontx2/meson.build                  |   3 +
>  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
>  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
>  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
>  drivers/net/octeontx2/otx2_flow.c                  |  26 +
>  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
>  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
>  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
>  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
>  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
>  36 files changed, 2556 insertions(+), 283 deletions(-)
>  create mode 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
>  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
>  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
>  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
>  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
>
> --
> 2.7.4
>
  

Hi Jerin,

Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me to trim the headline as well?

@Akhil, did you get a chance to review the series? Do you have any comments on the patches?

Thanks,
Anoob

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Jerin Jacob
> Sent: Saturday, January 18, 2020 8:09 PM
> To: Anoob Joseph <anoobj@marvell.com>
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty
> <declan.doherty@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
> Lukas Bartosik <lbartosik@marvell.com>; dpdk-dev <dev@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec support
> 
> On Sat, Jan 18, 2020 at 4:19 PM Anoob Joseph <anoobj@marvell.com> wrote:
> >
> > This series adds inline IPsec support in OCTEONTX2 PMD.
> >
> > In the inbound path, rte_flow framework need to be used to configure
> > the NPC block, which does the h/w lookup. The packets would get
> > processed by the crypto block and would submit to the scheduling
> > block, SSO. So inline IPsec mode can be enabled only when traffic is
> > received via event device using Rx adapter.
> >
> > In the outbound path, the core would submit to the crypto block and
> > the crypto block would submit the packet for Tx internally.
> 
> 
> Please fix following check-git-log.sh issues.
> 
> Wrong headline lowercase:
>         net/octeontx2: add inline ipsec rx path changes
>         drivers/octeontx2: add sec in compiler optimized RX fastpath framework
>         drivers/octeontx2: add sec in compiler optimized TX fastpath framework
>         crypto/octeontx2: add inline tx path changes Headline too long:
>         drivers/octeontx2: add sec in compiler optimized RX fastpath framework
>         drivers/octeontx2: add sec in compiler optimized TX fastpath framework
>         crypto/octeontx2: sync inline tag type cfg with Rx adapter configuration
> 
> Changing to Rx and Tx will fix most of the issues.
> 
> 
> 
> > v2:
> > * Minimized additions to common/octeontx2
> > * Updated release notes
> > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> >
> > Ankur Dwivedi (3):
> >   crypto/octeontx2: add eth security capabilities
> >   crypto/octeontx2: add datapath ops in eth security ctx
> >   crypto/octeontx2: add inline tx path changes
> >
> > Anoob Joseph (4):
> >   common/octeontx2: add CPT LF mbox for inline inbound
> >   crypto/octeontx2: create eth security ctx
> >   crypto/octeontx2: enable CPT to share QP with ethdev
> >   crypto/octeontx2: add eth security session operations
> >
> > Archana Muniganti (3):
> >   crypto/octeontx2: add lookup mem changes to hold sa indices
> >   drivers/octeontx2: add sec in compiler optimized RX fastpath framework
> >   drivers/octeontx2: add sec in compiler optimized TX fastpath
> > framework
> >
> > Tejasree Kondoj (3):
> >   crypto/octeontx2: configure for inline IPsec
> >   crypto/octeontx2: add security in eth dev configure
> >   net/octeontx2: add inline ipsec rx path changes
> >
> > Vamsi Attunuru (2):
> >   common/octeontx2: add routine to check if sec capable otx2
> >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> >     configuration
> >
> >  doc/guides/nics/octeontx2.rst                      |  20 +
> >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> >  drivers/common/octeontx2/otx2_common.c             |  22 +
> >  drivers/common/octeontx2/otx2_common.h             |  22 +
> >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> >  drivers/crypto/octeontx2/meson.build               |   7 +-
> >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> >  drivers/crypto/octeontx2/otx2_security.c           | 870
> +++++++++++++++++++++
> >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> >  drivers/event/octeontx2/Makefile                   |   1 +
> >  drivers/event/octeontx2/meson.build                |   5 +-
> >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> >  drivers/net/octeontx2/Makefile                     |   1 +
> >  drivers/net/octeontx2/meson.build                  |   3 +
> >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> >  36 files changed, 2556 insertions(+), 283 deletions(-)  create mode
> > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> >  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
> >
> > --
> > 2.7.4
> >
  

19/01/2020 11:43, Anoob Joseph:
> Hi Jerin,
> 
> Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me to trim the headline as well?

While you are in casing details,
I don't understand why I am alone taking care of the Marvell naming
(I am fixing it often while applying)
	OCTEONTX2 -> OCTEON TX2
  

Hi Thomas,

I'll have it fixed in v3. Thanks for pointing it out.

Thanks,
Anoob

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Sunday, January 19, 2020 4:24 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>; Anoob Joseph
> <anoobj@marvell.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> Narayana Prasad Raju Athreya <pathreya@marvell.com>; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
> Lukas Bartosik <lbartosik@marvell.com>
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty
> <declan.doherty@intel.com>; dpdk-dev <dev@dpdk.org>
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
> support
> 
> External Email
> 
> ----------------------------------------------------------------------
> 19/01/2020 11:43, Anoob Joseph:
> > Hi Jerin,
> >
> > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me to
> trim the headline as well?
> 
> While you are in casing details,
> I don't understand why I am alone taking care of the Marvell naming (I am fixing
> it often while applying)
> 	OCTEONTX2 -> OCTEON TX2
> 
>
  

> 
> Hi Jerin,
> 
> Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me to trim
> the headline as well?
> 

Hi Anoob,

> @Akhil, did you get a chance to review the series? Do you have any comments
> on the patches?
> 

You are adding inline ipsec support to ethernet device and not a crypto device.
These patches should not be part of crypto PMD. There will be cyclic dependency
Between ethernet device and crypto device which can be easily avoided.


> > >
> > > This series adds inline IPsec support in OCTEONTX2 PMD.
> > >
> > > In the inbound path, rte_flow framework need to be used to configure
> > > the NPC block, which does the h/w lookup. The packets would get
> > > processed by the crypto block and would submit to the scheduling
> > > block, SSO. So inline IPsec mode can be enabled only when traffic is
> > > received via event device using Rx adapter.
> > >
> > > In the outbound path, the core would submit to the crypto block and
> > > the crypto block would submit the packet for Tx internally.
> >
> >
> > Please fix following check-git-log.sh issues.
> >
> > Wrong headline lowercase:
> >         net/octeontx2: add inline ipsec rx path changes
> >         drivers/octeontx2: add sec in compiler optimized RX fastpath framework
> >         drivers/octeontx2: add sec in compiler optimized TX fastpath framework
> >         crypto/octeontx2: add inline tx path changes Headline too long:
> >         drivers/octeontx2: add sec in compiler optimized RX fastpath framework
> >         drivers/octeontx2: add sec in compiler optimized TX fastpath framework
> >         crypto/octeontx2: sync inline tag type cfg with Rx adapter configuration
> >
> > Changing to Rx and Tx will fix most of the issues.
> >
> >
> >
> > > v2:
> > > * Minimized additions to common/octeontx2
> > > * Updated release notes
> > > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> > >
> > > Ankur Dwivedi (3):
> > >   crypto/octeontx2: add eth security capabilities
> > >   crypto/octeontx2: add datapath ops in eth security ctx
> > >   crypto/octeontx2: add inline tx path changes
> > >
> > > Anoob Joseph (4):
> > >   common/octeontx2: add CPT LF mbox for inline inbound
> > >   crypto/octeontx2: create eth security ctx
> > >   crypto/octeontx2: enable CPT to share QP with ethdev
> > >   crypto/octeontx2: add eth security session operations
> > >
> > > Archana Muniganti (3):
> > >   crypto/octeontx2: add lookup mem changes to hold sa indices
> > >   drivers/octeontx2: add sec in compiler optimized RX fastpath framework
> > >   drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > framework
> > >
> > > Tejasree Kondoj (3):
> > >   crypto/octeontx2: configure for inline IPsec
> > >   crypto/octeontx2: add security in eth dev configure
> > >   net/octeontx2: add inline ipsec rx path changes
> > >
> > > Vamsi Attunuru (2):
> > >   common/octeontx2: add routine to check if sec capable otx2
> > >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > >     configuration
> > >
> > >  doc/guides/nics/octeontx2.rst                      |  20 +
> > >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> > >  drivers/common/octeontx2/otx2_common.c             |  22 +
> > >  drivers/common/octeontx2/otx2_common.h             |  22 +
> > >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> > >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> > >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> > >  drivers/crypto/octeontx2/meson.build               |   7 +-
> > >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> > >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> > >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> > >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> > >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> > >  drivers/crypto/octeontx2/otx2_security.c           | 870
> > +++++++++++++++++++++
> > >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> > >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> > >  drivers/event/octeontx2/Makefile                   |   1 +
> > >  drivers/event/octeontx2/meson.build                |   5 +-
> > >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> > >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> > >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> > >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> > >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> > >  drivers/net/octeontx2/Makefile                     |   1 +
> > >  drivers/net/octeontx2/meson.build                  |   3 +
> > >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> > >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> > >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> > >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> > >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> > >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> > >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> > >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> > >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> > >  36 files changed, 2556 insertions(+), 283 deletions(-)  create mode
> > > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> > >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> > >  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
> > >
> > > --
> > > 2.7.4
> > >
  

Hi Akhil,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Wednesday, January 22, 2020 3:46 PM
> To: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob
> <jerinjacobk@gmail.com>
> Cc: Declan Doherty <declan.doherty@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> Narayana Prasad Raju Athreya <pathreya@marvell.com>; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru
> <vattunuru@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; dpdk-
> dev <dev@dpdk.org>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
> support
> 
> External Email
> 
> ----------------------------------------------------------------------
> 
> >
> > Hi Jerin,
> >
> > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me
> > to trim the headline as well?
> >
> 
> Hi Anoob,
> 
> > @Akhil, did you get a chance to review the series? Do you have any
> > comments on the patches?
> >
> 
> You are adding inline ipsec support to ethernet device and not a crypto
> device.
> These patches should not be part of crypto PMD. There will be cyclic
> dependency Between ethernet device and crypto device which can be easily
> avoided.

[Anoob] We have plans to use lookaside protocol to handle the "fallback" session. And that involves session sharing between inline and lookaside protocol offloads. Also, though the feature is exposed as a feature of ethdev, on our platform, it's the crypto block which primarily implements the feature. And so, if the code is moved to ethdev dir, there would be lot of code duplication. The idea is to have all security related code in one place.

Also, the PMDs don't have any calls to each other. The communication between the two happens via common. The crypto dev PMD will register the required security ops to a common structure and ethdev would get it from there. So there won't be an issue of build dependency.

> 
> 
> > > >
> > > > This series adds inline IPsec support in OCTEONTX2 PMD.
> > > >
> > > > In the inbound path, rte_flow framework need to be used to
> > > > configure the NPC block, which does the h/w lookup. The packets
> > > > would get processed by the crypto block and would submit to the
> > > > scheduling block, SSO. So inline IPsec mode can be enabled only
> > > > when traffic is received via event device using Rx adapter.
> > > >
> > > > In the outbound path, the core would submit to the crypto block
> > > > and the crypto block would submit the packet for Tx internally.
> > >
> > >
> > > Please fix following check-git-log.sh issues.
> > >
> > > Wrong headline lowercase:
> > >         net/octeontx2: add inline ipsec rx path changes
> > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> framework
> > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> framework
> > >         crypto/octeontx2: add inline tx path changes Headline too long:
> > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> framework
> > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> framework
> > >         crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > configuration
> > >
> > > Changing to Rx and Tx will fix most of the issues.
> > >
> > >
> > >
> > > > v2:
> > > > * Minimized additions to common/octeontx2
> > > > * Updated release notes
> > > > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> > > >
> > > > Ankur Dwivedi (3):
> > > >   crypto/octeontx2: add eth security capabilities
> > > >   crypto/octeontx2: add datapath ops in eth security ctx
> > > >   crypto/octeontx2: add inline tx path changes
> > > >
> > > > Anoob Joseph (4):
> > > >   common/octeontx2: add CPT LF mbox for inline inbound
> > > >   crypto/octeontx2: create eth security ctx
> > > >   crypto/octeontx2: enable CPT to share QP with ethdev
> > > >   crypto/octeontx2: add eth security session operations
> > > >
> > > > Archana Muniganti (3):
> > > >   crypto/octeontx2: add lookup mem changes to hold sa indices
> > > >   drivers/octeontx2: add sec in compiler optimized RX fastpath
> framework
> > > >   drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > > framework
> > > >
> > > > Tejasree Kondoj (3):
> > > >   crypto/octeontx2: configure for inline IPsec
> > > >   crypto/octeontx2: add security in eth dev configure
> > > >   net/octeontx2: add inline ipsec rx path changes
> > > >
> > > > Vamsi Attunuru (2):
> > > >   common/octeontx2: add routine to check if sec capable otx2
> > > >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > >     configuration
> > > >
> > > >  doc/guides/nics/octeontx2.rst                      |  20 +
> > > >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> > > >  drivers/common/octeontx2/otx2_common.c             |  22 +
> > > >  drivers/common/octeontx2/otx2_common.h             |  22 +
> > > >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> > > >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> > > >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> > > >  drivers/crypto/octeontx2/meson.build               |   7 +-
> > > >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> > > >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> > > >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> > > >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> > > >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> > > >  drivers/crypto/octeontx2/otx2_security.c           | 870
> > > +++++++++++++++++++++
> > > >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> > > >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> > > >  drivers/event/octeontx2/Makefile                   |   1 +
> > > >  drivers/event/octeontx2/meson.build                |   5 +-
> > > >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> > > >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> > > >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> > > >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> > > >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> > > >  drivers/net/octeontx2/Makefile                     |   1 +
> > > >  drivers/net/octeontx2/meson.build                  |   3 +
> > > >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> > > >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> > > >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> > > >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> > > >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> > > >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> > > >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> > > >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> > > >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> > > >  36 files changed, 2556 insertions(+), 283 deletions(-)  create
> > > > mode
> > > > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> > > >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
> > > >
> > > > --
> > > > 2.7.4
> > > >
  

> > >
> > > Hi Jerin,
> > >
> > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me
> > > to trim the headline as well?
> > >
> >
> > Hi Anoob,
> >
> > > @Akhil, did you get a chance to review the series? Do you have any
> > > comments on the patches?
> > >
> >
> > You are adding inline ipsec support to ethernet device and not a crypto
> > device.
> > These patches should not be part of crypto PMD. There will be cyclic
> > dependency Between ethernet device and crypto device which can be easily
> > avoided.
> 
> [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> session. And that involves session sharing between inline and lookaside protocol
> offloads. Also, though the feature is exposed as a feature of ethdev, on our
> platform, it's the crypto block which primarily implements the feature. And so, if
> the code is moved to ethdev dir, there would be lot of code duplication. The
> idea is to have all security related code in one place.
> 
> Also, the PMDs don't have any calls to each other. The communication between
> the two happens via common. The crypto dev PMD will register the required
> security ops to a common structure and ethdev would get it from there. So there
> won't be an issue of build dependency.
> 

- The code that need to be duplicated can be moved to drivers/common/
- You may not need to include rte_ethdev.h inside drivers/crypto
- otx2_sec_eth_ctx_create should be part of ethdev and you would need similar API
for crypto device as well when you would support the fallback session support.
So that would go in crypto. Session creation code may be common and can go
in drivers/common.
- You would have separate security_ctx for both eth device and crypto device and that should
In net device and crypto device separately. Similarly security->ops should be different in both of them.
However if they may have same session creation code and that can go in common.

> >
> >
> > > > >
> > > > > This series adds inline IPsec support in OCTEONTX2 PMD.
> > > > >
> > > > > In the inbound path, rte_flow framework need to be used to
> > > > > configure the NPC block, which does the h/w lookup. The packets
> > > > > would get processed by the crypto block and would submit to the
> > > > > scheduling block, SSO. So inline IPsec mode can be enabled only
> > > > > when traffic is received via event device using Rx adapter.
> > > > >
> > > > > In the outbound path, the core would submit to the crypto block
> > > > > and the crypto block would submit the packet for Tx internally.
> > > >
> > > >
> > > > Please fix following check-git-log.sh issues.
> > > >
> > > > Wrong headline lowercase:
> > > >         net/octeontx2: add inline ipsec rx path changes
> > > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> > framework
> > > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> > framework
> > > >         crypto/octeontx2: add inline tx path changes Headline too long:
> > > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> > framework
> > > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> > framework
> > > >         crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > > configuration
> > > >
> > > > Changing to Rx and Tx will fix most of the issues.
> > > >
> > > >
> > > >
> > > > > v2:
> > > > > * Minimized additions to common/octeontx2
> > > > > * Updated release notes
> > > > > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> > > > >
> > > > > Ankur Dwivedi (3):
> > > > >   crypto/octeontx2: add eth security capabilities
> > > > >   crypto/octeontx2: add datapath ops in eth security ctx
> > > > >   crypto/octeontx2: add inline tx path changes
> > > > >
> > > > > Anoob Joseph (4):
> > > > >   common/octeontx2: add CPT LF mbox for inline inbound
> > > > >   crypto/octeontx2: create eth security ctx
> > > > >   crypto/octeontx2: enable CPT to share QP with ethdev
> > > > >   crypto/octeontx2: add eth security session operations
> > > > >
> > > > > Archana Muniganti (3):
> > > > >   crypto/octeontx2: add lookup mem changes to hold sa indices
> > > > >   drivers/octeontx2: add sec in compiler optimized RX fastpath
> > framework
> > > > >   drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > > > framework
> > > > >
> > > > > Tejasree Kondoj (3):
> > > > >   crypto/octeontx2: configure for inline IPsec
> > > > >   crypto/octeontx2: add security in eth dev configure
> > > > >   net/octeontx2: add inline ipsec rx path changes
> > > > >
> > > > > Vamsi Attunuru (2):
> > > > >   common/octeontx2: add routine to check if sec capable otx2
> > > > >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > > >     configuration
> > > > >
> > > > >  doc/guides/nics/octeontx2.rst                      |  20 +
> > > > >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> > > > >  drivers/common/octeontx2/otx2_common.c             |  22 +
> > > > >  drivers/common/octeontx2/otx2_common.h             |  22 +
> > > > >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> > > > >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> > > > >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> > > > >  drivers/crypto/octeontx2/meson.build               |   7 +-
> > > > >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> > > > >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> > > > >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> > > > >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> > > > >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> > > > >  drivers/crypto/octeontx2/otx2_security.c           | 870
> > > > +++++++++++++++++++++
> > > > >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> > > > >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> > > > >  drivers/event/octeontx2/Makefile                   |   1 +
> > > > >  drivers/event/octeontx2/meson.build                |   5 +-
> > > > >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> > > > >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> > > > >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> > > > >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> > > > >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> > > > >  drivers/net/octeontx2/Makefile                     |   1 +
> > > > >  drivers/net/octeontx2/meson.build                  |   3 +
> > > > >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> > > > >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> > > > >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> > > > >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> > > > >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> > > > >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> > > > >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> > > > >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> > > > >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> > > > >  36 files changed, 2556 insertions(+), 283 deletions(-)  create
> > > > > mode
> > > > > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
> > > > >
> > > > > --
> > > > > 2.7.4
> > > > >
  

On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
>
> > > >
> > > > Hi Jerin,
> > > >
> > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me
> > > > to trim the headline as well?
> > > >
> > >
> > > Hi Anoob,
> > >
> > > > @Akhil, did you get a chance to review the series? Do you have any
> > > > comments on the patches?
> > > >
> > >
> > > You are adding inline ipsec support to ethernet device and not a crypto
> > > device.
> > > These patches should not be part of crypto PMD. There will be cyclic
> > > dependency Between ethernet device and crypto device which can be easily
> > > avoided.
> >
> > [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> > session. And that involves session sharing between inline and lookaside protocol
> > offloads. Also, though the feature is exposed as a feature of ethdev, on our
> > platform, it's the crypto block which primarily implements the feature. And so, if
> > the code is moved to ethdev dir, there would be lot of code duplication. The
> > idea is to have all security related code in one place.
> >
> > Also, the PMDs don't have any calls to each other. The communication between
> > the two happens via common. The crypto dev PMD will register the required
> > security ops to a common structure and ethdev would get it from there. So there
> > won't be an issue of build dependency.
> >
>
> - The code that need to be duplicated can be moved to drivers/common/

I would like to keep the common code that is common to all the coprocessors.

Moreover, there are logistic issues in that case where
a) drivers/common/octeontx2/ going through master repo. So we will be
creating unnecessary dependency with that 'master' tree.
b) crypto and ethdev work is done by different teams so we would like
to make responsibly clear wrt the review and ownership.

I would like to keep the security/crypto-related code to driver/crypto and
hook to driver/net/octeontx2 with required functionalities over the
driver/common
using a few function pointers to remove the cyclic build dependency.

Considering there is no cyclic build and shared library dependency
now, Can we make forward progress
with the existing scheme?

> - You may not need to include rte_ethdev.h inside drivers/crypto
> - otx2_sec_eth_ctx_create should be part of ethdev and you would need similar API
> for crypto device as well when you would support the fallback session support.
> So that would go in crypto. Session creation code may be common and can go
> in drivers/common.
> - You would have separate security_ctx for both eth device and crypto device and that should
> In net device and crypto device separately. Similarly security->ops should be different in both of them.
> However if they may have same session creation code and that can go in common.
>
> > >
> > >
> > > > > >
> > > > > > This series adds inline IPsec support in OCTEONTX2 PMD.
> > > > > >
> > > > > > In the inbound path, rte_flow framework need to be used to
> > > > > > configure the NPC block, which does the h/w lookup. The packets
> > > > > > would get processed by the crypto block and would submit to the
> > > > > > scheduling block, SSO. So inline IPsec mode can be enabled only
> > > > > > when traffic is received via event device using Rx adapter.
> > > > > >
> > > > > > In the outbound path, the core would submit to the crypto block
> > > > > > and the crypto block would submit the packet for Tx internally.
> > > > >
> > > > >
> > > > > Please fix following check-git-log.sh issues.
> > > > >
> > > > > Wrong headline lowercase:
> > > > >         net/octeontx2: add inline ipsec rx path changes
> > > > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> > > framework
> > > > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > framework
> > > > >         crypto/octeontx2: add inline tx path changes Headline too long:
> > > > >         drivers/octeontx2: add sec in compiler optimized RX fastpath
> > > framework
> > > > >         drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > framework
> > > > >         crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > > > configuration
> > > > >
> > > > > Changing to Rx and Tx will fix most of the issues.
> > > > >
> > > > >
> > > > >
> > > > > > v2:
> > > > > > * Minimized additions to common/octeontx2
> > > > > > * Updated release notes
> > > > > > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> > > > > >
> > > > > > Ankur Dwivedi (3):
> > > > > >   crypto/octeontx2: add eth security capabilities
> > > > > >   crypto/octeontx2: add datapath ops in eth security ctx
> > > > > >   crypto/octeontx2: add inline tx path changes
> > > > > >
> > > > > > Anoob Joseph (4):
> > > > > >   common/octeontx2: add CPT LF mbox for inline inbound
> > > > > >   crypto/octeontx2: create eth security ctx
> > > > > >   crypto/octeontx2: enable CPT to share QP with ethdev
> > > > > >   crypto/octeontx2: add eth security session operations
> > > > > >
> > > > > > Archana Muniganti (3):
> > > > > >   crypto/octeontx2: add lookup mem changes to hold sa indices
> > > > > >   drivers/octeontx2: add sec in compiler optimized RX fastpath
> > > framework
> > > > > >   drivers/octeontx2: add sec in compiler optimized TX fastpath
> > > > > > framework
> > > > > >
> > > > > > Tejasree Kondoj (3):
> > > > > >   crypto/octeontx2: configure for inline IPsec
> > > > > >   crypto/octeontx2: add security in eth dev configure
> > > > > >   net/octeontx2: add inline ipsec rx path changes
> > > > > >
> > > > > > Vamsi Attunuru (2):
> > > > > >   common/octeontx2: add routine to check if sec capable otx2
> > > > > >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > > > >     configuration
> > > > > >
> > > > > >  doc/guides/nics/octeontx2.rst                      |  20 +
> > > > > >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> > > > > >  drivers/common/octeontx2/otx2_common.c             |  22 +
> > > > > >  drivers/common/octeontx2/otx2_common.h             |  22 +
> > > > > >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> > > > > >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> > > > > >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> > > > > >  drivers/crypto/octeontx2/meson.build               |   7 +-
> > > > > >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> > > > > >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> > > > > >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> > > > > >  drivers/crypto/octeontx2/otx2_security.c           | 870
> > > > > +++++++++++++++++++++
> > > > > >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> > > > > >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> > > > > >  drivers/event/octeontx2/Makefile                   |   1 +
> > > > > >  drivers/event/octeontx2/meson.build                |   5 +-
> > > > > >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> > > > > >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> > > > > >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> > > > > >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> > > > > >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> > > > > >  drivers/net/octeontx2/Makefile                     |   1 +
> > > > > >  drivers/net/octeontx2/meson.build                  |   3 +
> > > > > >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> > > > > >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> > > > > >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> > > > > >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> > > > > >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> > > > > >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> > > > > >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> > > > > >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> > > > > >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> > > > > >  36 files changed, 2556 insertions(+), 283 deletions(-)  create
> > > > > > mode
> > > > > > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security_tx.h
> > > > > >
> > > > > > --
> > > > > > 2.7.4
> > > > > >
  

Hi Akhil,

Shall I send v3 with the commit header updates that Jerin suggested?

Thanks,
Anoob

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, January 22, 2020 7:48 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Declan Doherty
> <declan.doherty@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
> Lukas Bartosik <lbartosik@marvell.com>; dpdk-dev <dev@dpdk.org>
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
> support
> 
> External Email
> 
> ----------------------------------------------------------------------
> On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> >
> > > > >
> > > > > Hi Jerin,
> > > > >
> > > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you
> > > > > want me to trim the headline as well?
> > > > >
> > > >
> > > > Hi Anoob,
> > > >
> > > > > @Akhil, did you get a chance to review the series? Do you have
> > > > > any comments on the patches?
> > > > >
> > > >
> > > > You are adding inline ipsec support to ethernet device and not a
> > > > crypto device.
> > > > These patches should not be part of crypto PMD. There will be
> > > > cyclic dependency Between ethernet device and crypto device which
> > > > can be easily avoided.
> > >
> > > [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> > > session. And that involves session sharing between inline and
> > > lookaside protocol offloads. Also, though the feature is exposed as
> > > a feature of ethdev, on our platform, it's the crypto block which
> > > primarily implements the feature. And so, if the code is moved to
> > > ethdev dir, there would be lot of code duplication. The idea is to have all
> security related code in one place.
> > >
> > > Also, the PMDs don't have any calls to each other. The communication
> > > between the two happens via common. The crypto dev PMD will register
> > > the required security ops to a common structure and ethdev would get
> > > it from there. So there won't be an issue of build dependency.
> > >
> >
> > - The code that need to be duplicated can be moved to drivers/common/
> 
> I would like to keep the common code that is common to all the coprocessors.
> 
> Moreover, there are logistic issues in that case where
> a) drivers/common/octeontx2/ going through master repo. So we will be
> creating unnecessary dependency with that 'master' tree.
> b) crypto and ethdev work is done by different teams so we would like to make
> responsibly clear wrt the review and ownership.
> 
> I would like to keep the security/crypto-related code to driver/crypto and hook
> to driver/net/octeontx2 with required functionalities over the driver/common
> using a few function pointers to remove the cyclic build dependency.
> 
> Considering there is no cyclic build and shared library dependency now, Can we
> make forward progress with the existing scheme?
> 
> > - You may not need to include rte_ethdev.h inside drivers/crypto
> > - otx2_sec_eth_ctx_create should be part of ethdev and you would need
> > similar API for crypto device as well when you would support the fallback
> session support.
> > So that would go in crypto. Session creation code may be common and
> > can go in drivers/common.
> > - You would have separate security_ctx for both eth device and crypto
> > device and that should In net device and crypto device separately. Similarly
> security->ops should be different in both of them.
> > However if they may have same session creation code and that can go in
> common.
> >
> > > >
> > > >
> > > > > > >
> > > > > > > This series adds inline IPsec support in OCTEONTX2 PMD.
> > > > > > >
> > > > > > > In the inbound path, rte_flow framework need to be used to
> > > > > > > configure the NPC block, which does the h/w lookup. The
> > > > > > > packets would get processed by the crypto block and would
> > > > > > > submit to the scheduling block, SSO. So inline IPsec mode
> > > > > > > can be enabled only when traffic is received via event device using Rx
> adapter.
> > > > > > >
> > > > > > > In the outbound path, the core would submit to the crypto
> > > > > > > block and the crypto block would submit the packet for Tx internally.
> > > > > >
> > > > > >
> > > > > > Please fix following check-git-log.sh issues.
> > > > > >
> > > > > > Wrong headline lowercase:
> > > > > >         net/octeontx2: add inline ipsec rx path changes
> > > > > >         drivers/octeontx2: add sec in compiler optimized RX
> > > > > > fastpath
> > > > framework
> > > > > >         drivers/octeontx2: add sec in compiler optimized TX
> > > > > > fastpath
> > > > framework
> > > > > >         crypto/octeontx2: add inline tx path changes Headline too long:
> > > > > >         drivers/octeontx2: add sec in compiler optimized RX
> > > > > > fastpath
> > > > framework
> > > > > >         drivers/octeontx2: add sec in compiler optimized TX
> > > > > > fastpath
> > > > framework
> > > > > >         crypto/octeontx2: sync inline tag type cfg with Rx
> > > > > > adapter configuration
> > > > > >
> > > > > > Changing to Rx and Tx will fix most of the issues.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > v2:
> > > > > > > * Minimized additions to common/octeontx2
> > > > > > > * Updated release notes
> > > > > > > * Renamed otx2_is_ethdev to otx2_ethdev_is_sec_capable
> > > > > > >
> > > > > > > Ankur Dwivedi (3):
> > > > > > >   crypto/octeontx2: add eth security capabilities
> > > > > > >   crypto/octeontx2: add datapath ops in eth security ctx
> > > > > > >   crypto/octeontx2: add inline tx path changes
> > > > > > >
> > > > > > > Anoob Joseph (4):
> > > > > > >   common/octeontx2: add CPT LF mbox for inline inbound
> > > > > > >   crypto/octeontx2: create eth security ctx
> > > > > > >   crypto/octeontx2: enable CPT to share QP with ethdev
> > > > > > >   crypto/octeontx2: add eth security session operations
> > > > > > >
> > > > > > > Archana Muniganti (3):
> > > > > > >   crypto/octeontx2: add lookup mem changes to hold sa indices
> > > > > > >   drivers/octeontx2: add sec in compiler optimized RX
> > > > > > > fastpath
> > > > framework
> > > > > > >   drivers/octeontx2: add sec in compiler optimized TX
> > > > > > > fastpath framework
> > > > > > >
> > > > > > > Tejasree Kondoj (3):
> > > > > > >   crypto/octeontx2: configure for inline IPsec
> > > > > > >   crypto/octeontx2: add security in eth dev configure
> > > > > > >   net/octeontx2: add inline ipsec rx path changes
> > > > > > >
> > > > > > > Vamsi Attunuru (2):
> > > > > > >   common/octeontx2: add routine to check if sec capable otx2
> > > > > > >   crypto/octeontx2: sync inline tag type cfg with Rx adapter
> > > > > > >     configuration
> > > > > > >
> > > > > > >  doc/guides/nics/octeontx2.rst                      |  20 +
> > > > > > >  doc/guides/rel_notes/release_20_02.rst             |   9 +
> > > > > > >  drivers/common/octeontx2/otx2_common.c             |  22 +
> > > > > > >  drivers/common/octeontx2/otx2_common.h             |  22 +
> > > > > > >  drivers/common/octeontx2/otx2_mbox.h               |   7 +
> > > > > > >  .../octeontx2/rte_common_octeontx2_version.map     |   3 +
> > > > > > >  drivers/crypto/octeontx2/Makefile                  |   7 +-
> > > > > > >  drivers/crypto/octeontx2/meson.build               |   7 +-
> > > > > > >  drivers/crypto/octeontx2/otx2_cryptodev.c          |   8 +
> > > > > > >  .../crypto/octeontx2/otx2_cryptodev_hw_access.h    |  22 +-
> > > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.c     |  53 ++
> > > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_mbox.h     |   7 +
> > > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_ops.c      |  56 ++
> > > > > > >  drivers/crypto/octeontx2/otx2_cryptodev_qp.h       |  35 +
> > > > > > >  drivers/crypto/octeontx2/otx2_ipsec_fp.h           | 348 +++++++++
> > > > > > >  drivers/crypto/octeontx2/otx2_security.c           | 870
> > > > > > +++++++++++++++++++++
> > > > > > >  drivers/crypto/octeontx2/otx2_security.h           | 158 ++++
> > > > > > >  drivers/crypto/octeontx2/otx2_security_tx.h        | 175 +++++
> > > > > > >  drivers/event/octeontx2/Makefile                   |   1 +
> > > > > > >  drivers/event/octeontx2/meson.build                |   5 +-
> > > > > > >  drivers/event/octeontx2/otx2_evdev.c               | 170 ++--
> > > > > > >  drivers/event/octeontx2/otx2_evdev.h               |   4 +-
> > > > > > >  drivers/event/octeontx2/otx2_worker.c              |   6 +-
> > > > > > >  drivers/event/octeontx2/otx2_worker.h              |   6 +
> > > > > > >  drivers/event/octeontx2/otx2_worker_dual.c         |   6 +-
> > > > > > >  drivers/net/octeontx2/Makefile                     |   1 +
> > > > > > >  drivers/net/octeontx2/meson.build                  |   3 +
> > > > > > >  drivers/net/octeontx2/otx2_ethdev.c                |  46 +-
> > > > > > >  drivers/net/octeontx2/otx2_ethdev.h                |   2 +
> > > > > > >  drivers/net/octeontx2/otx2_ethdev_devargs.c        |  19 +
> > > > > > >  drivers/net/octeontx2/otx2_flow.c                  |  26 +
> > > > > > >  drivers/net/octeontx2/otx2_lookup.c                |  11 +-
> > > > > > >  drivers/net/octeontx2/otx2_rx.c                    |  27 +-
> > > > > > >  drivers/net/octeontx2/otx2_rx.h                    | 377 ++++++---
> > > > > > >  drivers/net/octeontx2/otx2_tx.c                    |  29 +-
> > > > > > >  drivers/net/octeontx2/otx2_tx.h                    | 271 +++++--
> > > > > > >  36 files changed, 2556 insertions(+), 283 deletions(-)
> > > > > > > create mode
> > > > > > > 100644 drivers/crypto/octeontx2/otx2_cryptodev_qp.h
> > > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_ipsec_fp.h
> > > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.c
> > > > > > >  create mode 100644 drivers/crypto/octeontx2/otx2_security.h
> > > > > > >  create mode 100644
> > > > > > > drivers/crypto/octeontx2/otx2_security_tx.h
> > > > > > >
> > > > > > > --
> > > > > > > 2.7.4
> > > > > > >
  

> 
> On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> >
> > > > >
> > > > > Hi Jerin,
> > > > >
> > > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me
> > > > > to trim the headline as well?
> > > > >
> > > >
> > > > Hi Anoob,
> > > >
> > > > > @Akhil, did you get a chance to review the series? Do you have any
> > > > > comments on the patches?
> > > > >
> > > >
> > > > You are adding inline ipsec support to ethernet device and not a crypto
> > > > device.
> > > > These patches should not be part of crypto PMD. There will be cyclic
> > > > dependency Between ethernet device and crypto device which can be
> easily
> > > > avoided.
> > >
> > > [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> > > session. And that involves session sharing between inline and lookaside
> protocol
> > > offloads. Also, though the feature is exposed as a feature of ethdev, on our
> > > platform, it's the crypto block which primarily implements the feature. And
> so, if
> > > the code is moved to ethdev dir, there would be lot of code duplication. The
> > > idea is to have all security related code in one place.
> > >
> > > Also, the PMDs don't have any calls to each other. The communication
> between
> > > the two happens via common. The crypto dev PMD will register the required
> > > security ops to a common structure and ethdev would get it from there. So
> there
> > > won't be an issue of build dependency.
> > >
> >
> > - The code that need to be duplicated can be moved to drivers/common/
> 
> I would like to keep the common code that is common to all the coprocessors.
> 
> Moreover, there are logistic issues in that case where
> a) drivers/common/octeontx2/ going through master repo. So we will be
> creating unnecessary dependency with that 'master' tree.
> b) crypto and ethdev work is done by different teams so we would like
> to make responsibly clear wrt the review and ownership.

I can agree upon that the code shall not be placed in the common/octeontx2, 
But you can have a header file in crypto/octeontx2/ which has some inline functions
Which can be called from the ethernet as well as crypto device for inline proto
And lookaside cases respectively. I think with that the maintainability would not
be an issue.

IMO, following approach can be looked upon and may be cleaner
- define security ctx and its ops in net/octeontx2.c or net/octeontx2_security.c 
These are all control path and should not be any issue.

- define crypto specific code (inline functions) in crypto/octeontx2_security.h
Which can be called for both inline protocol as well as lookaside proto case.

- for data path you can have the processing as is. I hope all dependencies can
Be dealt with as the code will be there in crypto driver for all the mapping of 
Event and crypto queues.

- all APIs which are common for ethernet device and crypto device in
octeontx2_security.h should not prefix eth as is the case in current APIs.

I hope this will clear the ugliness of the code.
> 
> I would like to keep the security/crypto-related code to driver/crypto and
> hook to driver/net/octeontx2 with required functionalities over the
> driver/common
> using a few function pointers to remove the cyclic build dependency.
> 
> Considering there is no cyclic build and shared library dependency
> now, Can we make forward progress
> with the existing scheme?
> 
> > - You may not need to include rte_ethdev.h inside drivers/crypto
> > - otx2_sec_eth_ctx_create should be part of ethdev and you would need
> similar API
> > for crypto device as well when you would support the fallback session support.
> > So that would go in crypto. Session creation code may be common and can go
> > in drivers/common.
> > - You would have separate security_ctx for both eth device and crypto device
> and that should
> > In net device and crypto device separately. Similarly security->ops should be
> different in both of them.
> > However if they may have same session creation code and that can go in
> common.
> >
  

On Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
>
>
> >
> > On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> > >
> > > > > >
> > > > > > Hi Jerin,
> > > > > >
> > > > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want me
> > > > > > to trim the headline as well?
> > > > > >
> > > > >
> > > > > Hi Anoob,
> > > > >
> > > > > > @Akhil, did you get a chance to review the series? Do you have any
> > > > > > comments on the patches?
> > > > > >
> > > > >
> > > > > You are adding inline ipsec support to ethernet device and not a crypto
> > > > > device.
> > > > > These patches should not be part of crypto PMD. There will be cyclic
> > > > > dependency Between ethernet device and crypto device which can be
> > easily
> > > > > avoided.
> > > >
> > > > [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> > > > session. And that involves session sharing between inline and lookaside
> > protocol
> > > > offloads. Also, though the feature is exposed as a feature of ethdev, on our
> > > > platform, it's the crypto block which primarily implements the feature. And
> > so, if
> > > > the code is moved to ethdev dir, there would be lot of code duplication. The
> > > > idea is to have all security related code in one place.
> > > >
> > > > Also, the PMDs don't have any calls to each other. The communication
> > between
> > > > the two happens via common. The crypto dev PMD will register the required
> > > > security ops to a common structure and ethdev would get it from there. So
> > there
> > > > won't be an issue of build dependency.
> > > >
> > >
> > > - The code that need to be duplicated can be moved to drivers/common/
> >
> > I would like to keep the common code that is common to all the coprocessors.
> >
> > Moreover, there are logistic issues in that case where
> > a) drivers/common/octeontx2/ going through master repo. So we will be
> > creating unnecessary dependency with that 'master' tree.
> > b) crypto and ethdev work is done by different teams so we would like
> > to make responsibly clear wrt the review and ownership.
>
> I can agree upon that the code shall not be placed in the common/octeontx2,
> But you can have a header file in crypto/octeontx2/ which has some inline functions
> Which can be called from the ethernet as well as crypto device for inline proto
> And lookaside cases respectively. I think with that the maintainability would not
> be an issue.
>
> IMO, following approach can be looked upon and may be cleaner
> - define security ctx and its ops in net/octeontx2.c or net/octeontx2_security.c
> These are all control path and should not be any issue.
>
> - define crypto specific code (inline functions) in crypto/octeontx2_security.h
> Which can be called for both inline protocol as well as lookaside proto case.

One problem with such an approach is we need to have fat inline functions.
In some case, those inline functions to needs  accessing the
array/driver specific symbols
in another driver namespace then those array needs to be exported in
map file and hence the
build dependency comes.


>
> - for data path you can have the processing as is. I hope all dependencies can
> Be dealt with as the code will be there in crypto driver for all the mapping of
> Event and crypto queues.
>
> - all APIs which are common for ethernet device and crypto device in
> octeontx2_security.h should not prefix eth as is the case in current APIs.

If I understand it correctly, You have a concern in having the
*rte_eth* symbols in driver/crypto/octeontx2?
If so, we can check what can be done. Let us know the exact your
concern in managing the code in this
model?

>
> I hope this will clear the ugliness of the code.

It is relative, I think, having fat inline functions and accessing
both drivers is ugly.

> >
> > I would like to keep the security/crypto-related code to driver/crypto and
> > hook to driver/net/octeontx2 with required functionalities over the
> > driver/common
> > using a few function pointers to remove the cyclic build dependency.
> >
> > Considering there is no cyclic build and shared library dependency
> > now, Can we make forward progress
> > with the existing scheme?
> >
> > > - You may not need to include rte_ethdev.h inside drivers/crypto
> > > - otx2_sec_eth_ctx_create should be part of ethdev and you would need
> > similar API
> > > for crypto device as well when you would support the fallback session support.
> > > So that would go in crypto. Session creation code may be common and can go
> > > in drivers/common.
> > > - You would have separate security_ctx for both eth device and crypto device
> > and that should
> > > In net device and crypto device separately. Similarly security->ops should be
> > different in both of them.
> > > However if they may have same session creation code and that can go in
> > common.
> > >
>
  

Hi Jerin,

> 
> On Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> >
> >
> > >
> > > On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> > > >
> > > > > > >
> > > > > > > Hi Jerin,
> > > > > > >
> > > > > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do you want
> me
> > > > > > > to trim the headline as well?
> > > > > > >
> > > > > >
> > > > > > Hi Anoob,
> > > > > >
> > > > > > > @Akhil, did you get a chance to review the series? Do you have any
> > > > > > > comments on the patches?
> > > > > > >
> > > > > >
> > > > > > You are adding inline ipsec support to ethernet device and not a crypto
> > > > > > device.
> > > > > > These patches should not be part of crypto PMD. There will be cyclic
> > > > > > dependency Between ethernet device and crypto device which can be
> > > easily
> > > > > > avoided.
> > > > >
> > > > > [Anoob] We have plans to use lookaside protocol to handle the "fallback"
> > > > > session. And that involves session sharing between inline and lookaside
> > > protocol
> > > > > offloads. Also, though the feature is exposed as a feature of ethdev, on
> our
> > > > > platform, it's the crypto block which primarily implements the feature.
> And
> > > so, if
> > > > > the code is moved to ethdev dir, there would be lot of code duplication.
> The
> > > > > idea is to have all security related code in one place.
> > > > >
> > > > > Also, the PMDs don't have any calls to each other. The communication
> > > between
> > > > > the two happens via common. The crypto dev PMD will register the
> required
> > > > > security ops to a common structure and ethdev would get it from there.
> So
> > > there
> > > > > won't be an issue of build dependency.
> > > > >
> > > >
> > > > - The code that need to be duplicated can be moved to drivers/common/
> > >
> > > I would like to keep the common code that is common to all the
> coprocessors.
> > >
> > > Moreover, there are logistic issues in that case where
> > > a) drivers/common/octeontx2/ going through master repo. So we will be
> > > creating unnecessary dependency with that 'master' tree.
> > > b) crypto and ethdev work is done by different teams so we would like
> > > to make responsibly clear wrt the review and ownership.
> >
> > I can agree upon that the code shall not be placed in the common/octeontx2,
> > But you can have a header file in crypto/octeontx2/ which has some inline
> functions
> > Which can be called from the ethernet as well as crypto device for inline proto
> > And lookaside cases respectively. I think with that the maintainability would
> not
> > be an issue.
> >
> > IMO, following approach can be looked upon and may be cleaner
> > - define security ctx and its ops in net/octeontx2.c or net/octeontx2_security.c
> > These are all control path and should not be any issue.
> >
> > - define crypto specific code (inline functions) in crypto/octeontx2_security.h
> > Which can be called for both inline protocol as well as lookaside proto case.
> 
> One problem with such an approach is we need to have fat inline functions.
> In some case, those inline functions to needs  accessing the
> array/driver specific symbols
> in another driver namespace then those array needs to be exported in
> map file and hence the
> build dependency comes.

How many such symbols are there. I don’t they will be many. Can they be
Passed as argument in the APIs to avoid build dependencies.

> 
> 
> >
> > - for data path you can have the processing as is. I hope all dependencies can
> > Be dealt with as the code will be there in crypto driver for all the mapping of
> > Event and crypto queues.
> >
> > - all APIs which are common for ethernet device and crypto device in
> > octeontx2_security.h should not prefix eth as is the case in current APIs.
> 
> If I understand it correctly, You have a concern in having the
> *rte_eth* symbols in driver/crypto/octeontx2?
> If so, we can check what can be done. Let us know the exact your
> concern in managing the code in this
> model?

Yes, rte_eth* symbols should not be there in crypto driver.
Because crypto driver is not leveraging any ethernet functionality,
It is the other way, ethernet device is using the crypto functionality/
Structs etc for supporting inline IPSEC.

Also, the security ctx should be part of ethdev  and its ops should be
Defined in ethernet device which may call some inline APIs placed in
Drivers/crypto/octeontx2/

> 
> >
> > I hope this will clear the ugliness of the code.
> 
> It is relative, I think, having fat inline functions and accessing
> both drivers is ugly.

Breaking the way an API need to be defined and used is even more uglier.
IMO, having fat inline functions will act as external library functions which
Are independent of the device which is calling it.
Something similar to drivers/common/dpaax/caamflib/.

My original suggestion was to put it in common, but I am ok, if you want that
In the crypto driver. I agree with the decision that all crypto/ipsec related stuff
Should be there under drivers/crypto if it is getting used from both the net and
Crypto driver. But atleast the API definitions should be there where it should be.


> 
> > >
> > > I would like to keep the security/crypto-related code to driver/crypto and
> > > hook to driver/net/octeontx2 with required functionalities over the
> > > driver/common
> > > using a few function pointers to remove the cyclic build dependency.
> > >
> > > Considering there is no cyclic build and shared library dependency
> > > now, Can we make forward progress
> > > with the existing scheme?
> > >
> > > > - You may not need to include rte_ethdev.h inside drivers/crypto
> > > > - otx2_sec_eth_ctx_create should be part of ethdev and you would need
> > > similar API
> > > > for crypto device as well when you would support the fallback session
> support.
> > > > So that would go in crypto. Session creation code may be common and can
> go
> > > > in drivers/common.
> > > > - You would have separate security_ctx for both eth device and crypto
> device
> > > and that should
> > > > In net device and crypto device separately. Similarly security->ops should
> be
> > > different in both of them.
> > > > However if they may have same session creation code and that can go in
> > > common.
> > > >
> >
  

Hi Jerin, Akhil,

Let me summarize the design changes from the discussions below.

Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops for the ethdev (idea was to add all crypto security ctx for lookaside also there). That will be moved to drivers/net/octeontx2 as is. The routines which are doing qp_add & qp_remove would be moved to common (discussed below). Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation, please do share specifics. Almost all functions in otx2_security.c is dereferencing 'rte_eth_dev'. So having (void *) will not help.

The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h (which has lower level implementations of session create etc). This will remain as is in drivers/crypto/octeontx2 but would be called from drivers/net/octeontx2/otx2_security.c.

We will need to include otx2_cryptodev_qp.h (internal header in drivers/crypto/octeontx2) since the crypto queue pair is required for outbound processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the ethdev file will have dependency on rte_cryptodev.h.

I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting included in a cryptodev PMD file. The case we are proposing is the exact mirror of that)

Currently, the cryptodev has to do qp-eth port mapping and save it somewhere for eth dev to use during security session create. This will have to be saved in drivers/common/octeontx2.

@Ferruh, do you agree with the suggestions here? With the proposed changes, parts of the patches would go into ethdev space (for reviews and merge), and the rest would be in crypto space.

Thanks,
Anoob

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Monday, January 27, 2020 5:18 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Declan Doherty
> <declan.doherty@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
> Lukas Bartosik <lbartosik@marvell.com>; dpdk-dev <dev@dpdk.org>
> Subject: [EXT] RE: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
> support
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Jerin,
> 
> >
> > On Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
> > >
> > >
> > > >
> > > > On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com>
> wrote:
> > > > >
> > > > > > > >
> > > > > > > > Hi Jerin,
> > > > > > > >
> > > > > > > > Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do
> > > > > > > > you want
> > me
> > > > > > > > to trim the headline as well?
> > > > > > > >
> > > > > > >
> > > > > > > Hi Anoob,
> > > > > > >
> > > > > > > > @Akhil, did you get a chance to review the series? Do you
> > > > > > > > have any comments on the patches?
> > > > > > > >
> > > > > > >
> > > > > > > You are adding inline ipsec support to ethernet device and
> > > > > > > not a crypto device.
> > > > > > > These patches should not be part of crypto PMD. There will
> > > > > > > be cyclic dependency Between ethernet device and crypto
> > > > > > > device which can be
> > > > easily
> > > > > > > avoided.
> > > > > >
> > > > > > [Anoob] We have plans to use lookaside protocol to handle the
> "fallback"
> > > > > > session. And that involves session sharing between inline and
> > > > > > lookaside
> > > > protocol
> > > > > > offloads. Also, though the feature is exposed as a feature of
> > > > > > ethdev, on
> > our
> > > > > > platform, it's the crypto block which primarily implements the feature.
> > And
> > > > so, if
> > > > > > the code is moved to ethdev dir, there would be lot of code duplication.
> > The
> > > > > > idea is to have all security related code in one place.
> > > > > >
> > > > > > Also, the PMDs don't have any calls to each other. The
> > > > > > communication
> > > > between
> > > > > > the two happens via common. The crypto dev PMD will register
> > > > > > the
> > required
> > > > > > security ops to a common structure and ethdev would get it from there.
> > So
> > > > there
> > > > > > won't be an issue of build dependency.
> > > > > >
> > > > >
> > > > > - The code that need to be duplicated can be moved to
> > > > > drivers/common/
> > > >
> > > > I would like to keep the common code that is common to all the
> > coprocessors.
> > > >
> > > > Moreover, there are logistic issues in that case where
> > > > a) drivers/common/octeontx2/ going through master repo. So we will
> > > > be creating unnecessary dependency with that 'master' tree.
> > > > b) crypto and ethdev work is done by different teams so we would
> > > > like to make responsibly clear wrt the review and ownership.
> > >
> > > I can agree upon that the code shall not be placed in the
> > > common/octeontx2, But you can have a header file in
> > > crypto/octeontx2/ which has some inline
> > functions
> > > Which can be called from the ethernet as well as crypto device for
> > > inline proto And lookaside cases respectively. I think with that the
> > > maintainability would
> > not
> > > be an issue.
> > >
> > > IMO, following approach can be looked upon and may be cleaner
> > > - define security ctx and its ops in net/octeontx2.c or
> > > net/octeontx2_security.c These are all control path and should not be any
> issue.
> > >
> > > - define crypto specific code (inline functions) in
> > > crypto/octeontx2_security.h Which can be called for both inline protocol as
> well as lookaside proto case.
> >
> > One problem with such an approach is we need to have fat inline functions.
> > In some case, those inline functions to needs  accessing the
> > array/driver specific symbols in another driver namespace then those
> > array needs to be exported in map file and hence the build dependency
> > comes.
> 
> How many such symbols are there. I don’t they will be many. Can they be Passed
> as argument in the APIs to avoid build dependencies.
> 
> >
> >
> > >
> > > - for data path you can have the processing as is. I hope all
> > > dependencies can Be dealt with as the code will be there in crypto
> > > driver for all the mapping of Event and crypto queues.
> > >
> > > - all APIs which are common for ethernet device and crypto device in
> > > octeontx2_security.h should not prefix eth as is the case in current APIs.
> >
> > If I understand it correctly, You have a concern in having the
> > *rte_eth* symbols in driver/crypto/octeontx2?
> > If so, we can check what can be done. Let us know the exact your
> > concern in managing the code in this model?
> 
> Yes, rte_eth* symbols should not be there in crypto driver.
> Because crypto driver is not leveraging any ethernet functionality, It is the other
> way, ethernet device is using the crypto functionality/ Structs etc for supporting
> inline IPSEC.
> 
> Also, the security ctx should be part of ethdev  and its ops should be Defined in
> ethernet device which may call some inline APIs placed in
> Drivers/crypto/octeontx2/
> 
> >
> > >
> > > I hope this will clear the ugliness of the code.
> >
> > It is relative, I think, having fat inline functions and accessing
> > both drivers is ugly.
> 
> Breaking the way an API need to be defined and used is even more uglier.
> IMO, having fat inline functions will act as external library functions which Are
> independent of the device which is calling it.
> Something similar to drivers/common/dpaax/caamflib/.
> 
> My original suggestion was to put it in common, but I am ok, if you want that In
> the crypto driver. I agree with the decision that all crypto/ipsec related stuff
> Should be there under drivers/crypto if it is getting used from both the net and
> Crypto driver. But atleast the API definitions should be there where it should be.
> 
> 
> >
> > > >
> > > > I would like to keep the security/crypto-related code to
> > > > driver/crypto and hook to driver/net/octeontx2 with required
> > > > functionalities over the driver/common using a few function
> > > > pointers to remove the cyclic build dependency.
> > > >
> > > > Considering there is no cyclic build and shared library dependency
> > > > now, Can we make forward progress with the existing scheme?
> > > >
> > > > > - You may not need to include rte_ethdev.h inside drivers/crypto
> > > > > - otx2_sec_eth_ctx_create should be part of ethdev and you would
> > > > > need
> > > > similar API
> > > > > for crypto device as well when you would support the fallback
> > > > > session
> > support.
> > > > > So that would go in crypto. Session creation code may be common
> > > > > and can
> > go
> > > > > in drivers/common.
> > > > > - You would have separate security_ctx for both eth device and
> > > > > crypto
> > device
> > > > and that should
> > > > > In net device and crypto device separately. Similarly
> > > > > security->ops should
> > be
> > > > different in both of them.
> > > > > However if they may have same session creation code and that can
> > > > > go in
> > > > common.
> > > > >
> > >
  

On Mon, Jan 27, 2020 at 8:24 PM Anoob Joseph <anoobj@marvell.com> wrote:
>
> Hi Jerin, Akhil,
>
> Let me summarize the design changes from the discussions below.
>
> Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops for the ethdev (idea was to add all crypto security ctx for lookaside also there). That will be moved to drivers/net/octeontx2 as is. The routines which are doing qp_add & qp_remove would be moved to common (discussed below). Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation, please do share specifics. Almost all functions in otx2_security.c is dereferencing 'rte_eth_dev'. So having (void *) will not help.
>
> The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h (which has lower level implementations of session create etc). This will remain as is in drivers/crypto/octeontx2 but would be called from drivers/net/octeontx2/otx2_security.c.
>
> We will need to include otx2_cryptodev_qp.h (internal header in drivers/crypto/octeontx2) since the crypto queue pair is required for outbound processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the ethdev file will have dependency on rte_cryptodev.h.
>
> I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting included in a cryptodev PMD file. The case we are proposing is the exact mirror of that)

I think, Following rework would be required.

1) Don't access rte_eth_dev symbols in driver/crypto/octeontx2
2) Don't access rte_crypto_dev symbols in drier/net/octeontx2
3) Communication between both drivers should both through "custom
structure"(say struct otx2_eth_sec or so for inline, otx2_crypto_sec
for look side)
defined in driver/common/octeonxt2 which holds data.
Processing function through "function pointer" registration provided
through in driver/common/octeonx2 as idev framework to avoid build
dependency.

I am not sure anything else can be done beyond the above.
  

Hi Jerin,
> 
> On Mon, Jan 27, 2020 at 8:24 PM Anoob Joseph <anoobj@marvell.com> wrote:
> >
> > Hi Jerin, Akhil,
> >
> > Let me summarize the design changes from the discussions below.
> >
> > Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops
> for the ethdev (idea was to add all crypto security ctx for lookaside also there).
> That will be moved to drivers/net/octeontx2 as is. The routines which are doing
> qp_add & qp_remove would be moved to common (discussed below). Otherwise,
> the rest should remain as is. If Jerin/Akhil wants further isolation, please do
> share specifics. Almost all functions in otx2_security.c is dereferencing
> 'rte_eth_dev'. So having (void *) will not help.
> >
> > The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h
> (which has lower level implementations of session create etc). This will remain
> as is in drivers/crypto/octeontx2 but would be called from
> drivers/net/octeontx2/otx2_security.c.
> >
> > We will need to include otx2_cryptodev_qp.h (internal header in
> drivers/crypto/octeontx2) since the crypto queue pair is required for outbound
> processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the
> ethdev file will have dependency on rte_cryptodev.h.
> >
> > I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so
> that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting
> included in a cryptodev PMD file. The case we are proposing is the exact mirror
> of that)
> 
> I think, Following rework would be required.
> 
> 1) Don't access rte_eth_dev symbols in driver/crypto/octeontx2
Yes

> 2) Don't access rte_crypto_dev symbols in drier/net/octeontx2
I am not sure how you can work without rte_cryptodev.h in net driver.
As I mentioned, security_ctx for ethernet device along with it's ops should 
Be defined in ethernet driver. And call crypto specific inline functions 
Placed in a header file in drivers/crypto/octeontx2/

I believe you would need cryptodev.h included in ethernet driver like it is
Getting used in ixgbe driver. The difference would be, all crypto
Base functionality would be inside the crypto driver(inline functions in .h).

> 3) Communication between both drivers should both through "custom
> structure"(say struct otx2_eth_sec or so for inline, otx2_crypto_sec
> for look side)
> defined in driver/common/octeonxt2 which holds data.
> Processing function through "function pointer" registration provided
> through in driver/common/octeonx2 as idev framework to avoid build
> dependency.
> 
> I am not sure anything else can be done beyond the above.
  

On Tue, Jan 28, 2020 at 2:08 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
>
> Hi Jerin,

Hi Akhil,

> >
> > On Mon, Jan 27, 2020 at 8:24 PM Anoob Joseph <anoobj@marvell.com> wrote:
> > >
> > > Hi Jerin, Akhil,
> > >
> > > Let me summarize the design changes from the discussions below.
> > >
> > > Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops
> > for the ethdev (idea was to add all crypto security ctx for lookaside also there).
> > That will be moved to drivers/net/octeontx2 as is. The routines which are doing
> > qp_add & qp_remove would be moved to common (discussed below). Otherwise,
> > the rest should remain as is. If Jerin/Akhil wants further isolation, please do
> > share specifics. Almost all functions in otx2_security.c is dereferencing
> > 'rte_eth_dev'. So having (void *) will not help.
> > >
> > > The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h
> > (which has lower level implementations of session create etc). This will remain
> > as is in drivers/crypto/octeontx2 but would be called from
> > drivers/net/octeontx2/otx2_security.c.
> > >
> > > We will need to include otx2_cryptodev_qp.h (internal header in
> > drivers/crypto/octeontx2) since the crypto queue pair is required for outbound
> > processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the
> > ethdev file will have dependency on rte_cryptodev.h.
> > >
> > > I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so
> > that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting
> > included in a cryptodev PMD file. The case we are proposing is the exact mirror
> > of that)
> >
> > I think, Following rework would be required.
> >
> > 1) Don't access rte_eth_dev symbols in driver/crypto/octeontx2
> Yes
>
> > 2) Don't access rte_crypto_dev symbols in drier/net/octeontx2
> I am not sure how you can work without rte_cryptodev.h in net driver.

We would need to include the only rte_security.h. Right?
Meaning access should be limited to rte_securty_* symbols.

> As I mentioned, security_ctx for ethernet device along with it's ops should
> Be defined in ethernet driver. And call crypto specific inline functions

Yes. Ops should should be defined in an ethernet driver.

It can be the hook to the real implementation in driver/crypto/octeontx2
have some code for ethdev specific locally and other in crypto-specific.

> Placed in a header file in drivers/crypto/octeontx2/
>
> I believe you would need cryptodev.h included in ethernet driver like it is
> Getting used in ixgbe driver. The difference would be, all crypto
> Base functionality would be inside the crypto driver(inline functions in .h).
>
> > 3) Communication between both drivers should both through "custom
> > structure"(say struct otx2_eth_sec or so for inline, otx2_crypto_sec
> > for look side)
> > defined in driver/common/octeonxt2 which holds data.
> > Processing function through "function pointer" registration provided
> > through in driver/common/octeonx2 as idev framework to avoid build
> > dependency.
> >
> > I am not sure anything else can be done beyond the above.
  

On 1/27/2020 2:54 PM, Anoob Joseph wrote:
> Hi Jerin, Akhil,
> 
> Let me summarize the design changes from the discussions below.
> 
> Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops for the ethdev (idea was to add all crypto security ctx for lookaside also there). That will be moved to drivers/net/octeontx2 as is. The routines which are doing qp_add & qp_remove would be moved to common (discussed below). Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation, please do share specifics. Almost all functions in otx2_security.c is dereferencing 'rte_eth_dev'. So having (void *) will not help.
> 
> The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h (which has lower level implementations of session create etc). This will remain as is in drivers/crypto/octeontx2 but would be called from drivers/net/octeontx2/otx2_security.c.
> 
> We will need to include otx2_cryptodev_qp.h (internal header in drivers/crypto/octeontx2) since the crypto queue pair is required for outbound processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the ethdev file will have dependency on rte_cryptodev.h.
> 
> I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting included in a cryptodev PMD file. The case we are proposing is the exact mirror of that)
> 
> Currently, the cryptodev has to do qp-eth port mapping and save it somewhere for eth dev to use during security session create. This will have to be saved in drivers/common/octeontx2.
> 
> @Ferruh, do you agree with the suggestions here? With the proposed changes, parts of the patches would go into ethdev space (for reviews and merge), and the rest would be in crypto space.

Hi Anoob,

It is OK to move the 'rte_security_ops' to net driver, as far as I can see there
is no way to isolate ethdev and cryptodev completely, at least having one way
ethdev->crypto dependency is better.

Not sure about using inline functions though, existing solution to use common/x
looks OK to me.

> 
> Thanks,
> Anoob
> 
>> -----Original Message-----
>> From: Akhil Goyal <akhil.goyal@nxp.com>
>> Sent: Monday, January 27, 2020 5:18 PM
>> To: Jerin Jacob <jerinjacobk@gmail.com>
>> Cc: Anoob Joseph <anoobj@marvell.com>; Declan Doherty
>> <declan.doherty@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Jerin
>> Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
>> <pathreya@marvell.com>; Kiran Kumar Kokkilagadda
>> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
>> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
>> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
>> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
>> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
>> Lukas Bartosik <lbartosik@marvell.com>; dpdk-dev <dev@dpdk.org>
>> Subject: [EXT] RE: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
>> support
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>> Hi Jerin,
>>
>>>
>>> On Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal <akhil.goyal@nxp.com> wrote:
>>>>
>>>>
>>>>>
>>>>> On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal <akhil.goyal@nxp.com>
>> wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Jerin,
>>>>>>>>>
>>>>>>>>> Will  do the suggested change (RX/rx-> Rx & TX/tx->Tx). Do
>>>>>>>>> you want
>>> me
>>>>>>>>> to trim the headline as well?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Anoob,
>>>>>>>>
>>>>>>>>> @Akhil, did you get a chance to review the series? Do you
>>>>>>>>> have any comments on the patches?
>>>>>>>>>
>>>>>>>>
>>>>>>>> You are adding inline ipsec support to ethernet device and
>>>>>>>> not a crypto device.
>>>>>>>> These patches should not be part of crypto PMD. There will
>>>>>>>> be cyclic dependency Between ethernet device and crypto
>>>>>>>> device which can be
>>>>> easily
>>>>>>>> avoided.
>>>>>>>
>>>>>>> [Anoob] We have plans to use lookaside protocol to handle the
>> "fallback"
>>>>>>> session. And that involves session sharing between inline and
>>>>>>> lookaside
>>>>> protocol
>>>>>>> offloads. Also, though the feature is exposed as a feature of
>>>>>>> ethdev, on
>>> our
>>>>>>> platform, it's the crypto block which primarily implements the feature.
>>> And
>>>>> so, if
>>>>>>> the code is moved to ethdev dir, there would be lot of code duplication.
>>> The
>>>>>>> idea is to have all security related code in one place.
>>>>>>>
>>>>>>> Also, the PMDs don't have any calls to each other. The
>>>>>>> communication
>>>>> between
>>>>>>> the two happens via common. The crypto dev PMD will register
>>>>>>> the
>>> required
>>>>>>> security ops to a common structure and ethdev would get it from there.
>>> So
>>>>> there
>>>>>>> won't be an issue of build dependency.
>>>>>>>
>>>>>>
>>>>>> - The code that need to be duplicated can be moved to
>>>>>> drivers/common/
>>>>>
>>>>> I would like to keep the common code that is common to all the
>>> coprocessors.
>>>>>
>>>>> Moreover, there are logistic issues in that case where
>>>>> a) drivers/common/octeontx2/ going through master repo. So we will
>>>>> be creating unnecessary dependency with that 'master' tree.
>>>>> b) crypto and ethdev work is done by different teams so we would
>>>>> like to make responsibly clear wrt the review and ownership.
>>>>
>>>> I can agree upon that the code shall not be placed in the
>>>> common/octeontx2, But you can have a header file in
>>>> crypto/octeontx2/ which has some inline
>>> functions
>>>> Which can be called from the ethernet as well as crypto device for
>>>> inline proto And lookaside cases respectively. I think with that the
>>>> maintainability would
>>> not
>>>> be an issue.
>>>>
>>>> IMO, following approach can be looked upon and may be cleaner
>>>> - define security ctx and its ops in net/octeontx2.c or
>>>> net/octeontx2_security.c These are all control path and should not be any
>> issue.
>>>>
>>>> - define crypto specific code (inline functions) in
>>>> crypto/octeontx2_security.h Which can be called for both inline protocol as
>> well as lookaside proto case.
>>>
>>> One problem with such an approach is we need to have fat inline functions.
>>> In some case, those inline functions to needs  accessing the
>>> array/driver specific symbols in another driver namespace then those
>>> array needs to be exported in map file and hence the build dependency
>>> comes.
>>
>> How many such symbols are there. I don’t they will be many. Can they be Passed
>> as argument in the APIs to avoid build dependencies.
>>
>>>
>>>
>>>>
>>>> - for data path you can have the processing as is. I hope all
>>>> dependencies can Be dealt with as the code will be there in crypto
>>>> driver for all the mapping of Event and crypto queues.
>>>>
>>>> - all APIs which are common for ethernet device and crypto device in
>>>> octeontx2_security.h should not prefix eth as is the case in current APIs.
>>>
>>> If I understand it correctly, You have a concern in having the
>>> *rte_eth* symbols in driver/crypto/octeontx2?
>>> If so, we can check what can be done. Let us know the exact your
>>> concern in managing the code in this model?
>>
>> Yes, rte_eth* symbols should not be there in crypto driver.
>> Because crypto driver is not leveraging any ethernet functionality, It is the other
>> way, ethernet device is using the crypto functionality/ Structs etc for supporting
>> inline IPSEC.
>>
>> Also, the security ctx should be part of ethdev  and its ops should be Defined in
>> ethernet device which may call some inline APIs placed in
>> Drivers/crypto/octeontx2/
>>
>>>
>>>>
>>>> I hope this will clear the ugliness of the code.
>>>
>>> It is relative, I think, having fat inline functions and accessing
>>> both drivers is ugly.
>>
>> Breaking the way an API need to be defined and used is even more uglier.
>> IMO, having fat inline functions will act as external library functions which Are
>> independent of the device which is calling it.
>> Something similar to drivers/common/dpaax/caamflib/.
>>
>> My original suggestion was to put it in common, but I am ok, if you want that In
>> the crypto driver. I agree with the decision that all crypto/ipsec related stuff
>> Should be there under drivers/crypto if it is getting used from both the net and
>> Crypto driver. But atleast the API definitions should be there where it should be.
>>
>>
>>>
>>>>>
>>>>> I would like to keep the security/crypto-related code to
>>>>> driver/crypto and hook to driver/net/octeontx2 with required
>>>>> functionalities over the driver/common using a few function
>>>>> pointers to remove the cyclic build dependency.
>>>>>
>>>>> Considering there is no cyclic build and shared library dependency
>>>>> now, Can we make forward progress with the existing scheme?
>>>>>
>>>>>> - You may not need to include rte_ethdev.h inside drivers/crypto
>>>>>> - otx2_sec_eth_ctx_create should be part of ethdev and you would
>>>>>> need
>>>>> similar API
>>>>>> for crypto device as well when you would support the fallback
>>>>>> session
>>> support.
>>>>>> So that would go in crypto. Session creation code may be common
>>>>>> and can
>>> go
>>>>>> in drivers/common.
>>>>>> - You would have separate security_ctx for both eth device and
>>>>>> crypto
>>> device
>>>>> and that should
>>>>>> In net device and crypto device separately. Similarly
>>>>>> security->ops should
>>> be
>>>>> different in both of them.
>>>>>> However if they may have same session creation code and that can
>>>>>> go in
>>>>> common.
>>>>>>
>>>>
  

On 1/28/2020 8:29 AM, Jerin Jacob wrote:
> On Mon, Jan 27, 2020 at 8:24 PM Anoob Joseph <anoobj@marvell.com> wrote:
>>
>> Hi Jerin, Akhil,
>>
>> Let me summarize the design changes from the discussions below.
>>
>> Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx ops for the ethdev (idea was to add all crypto security ctx for lookaside also there). That will be moved to drivers/net/octeontx2 as is. The routines which are doing qp_add & qp_remove would be moved to common (discussed below). Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation, please do share specifics. Almost all functions in otx2_security.c is dereferencing 'rte_eth_dev'. So having (void *) will not help.
>>
>> The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h (which has lower level implementations of session create etc). This will remain as is in drivers/crypto/octeontx2 but would be called from drivers/net/octeontx2/otx2_security.c.
>>
>> We will need to include otx2_cryptodev_qp.h (internal header in drivers/crypto/octeontx2) since the crypto queue pair is required for outbound processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the ethdev file will have dependency on rte_cryptodev.h.
>>
>> I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above behavior so that I can proceed with the restructuring. (Currently issue is rte_ethdev.h getting included in a cryptodev PMD file. The case we are proposing is the exact mirror of that)
> 
> I think, Following rework would be required.
> 
> 1) Don't access rte_eth_dev symbols in driver/crypto/octeontx2
> 2) Don't access rte_crypto_dev symbols in drier/net/octeontx2
> 3) Communication between both drivers should both through "custom
> structure"(say struct otx2_eth_sec or so for inline, otx2_crypto_sec
> for look side)
> defined in driver/common/octeonxt2 which holds data.
> Processing function through "function pointer" registration provided
> through in driver/common/octeonx2 as idev framework to avoid build
> dependency.
> 

In high level this looks good to me.

> I am not sure anything else can be done beyond the above.
>
  

Hi Ferruh, Akhil, Thomas,

I would like to make the following modifications to MAINTAINERS file to better isolate security additions.

diff --git a/MAINTAINERS b/MAINTAINERS
index 94bccae..76171ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -724,6 +724,12 @@ F: drivers/net/octeontx2/
 F: doc/guides/nics/features/octeontx2*.ini
 F: doc/guides/nics/octeontx2.rst

+Marvell OCTEON TX2 - security
+M: Anoob Joseph <anoobj@marvell.com>
+T: git://dpdk.org/next/dpdk-next-crypto
+F: drivers/net/octeontx2/otx2_ethdev_sec*
+F: drivers/common/octeontx2/otx2_sec*
+
 Mellanox mlx4
 M: Matan Azrad <matan@mellanox.com>
 M: Shahaf Shuler <shahafs@mellanox.com>

Can you confirm if this is fine?

@Akhil, can the security changes (in both ethdev & common) go via dpdk-next-crypto? Once the interface is set, there won't be any changes in the rest of the ethdev related routines. All the further changes would be feature additions in the security specific files and so would be contained in the above mentioned files.

Thanks,
Anoob

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Tuesday, January 28, 2020 10:58 PM
> To: Jerin Jacob <jerinjacobk@gmail.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty
> <declan.doherty@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Archana Muniganti <marchana@marvell.com>; Tejasree Kondoj
> <ktejasree@marvell.com>; Vamsi Krishna Attunuru <vattunuru@marvell.com>;
> Lukas Bartosik <lbartosik@marvell.com>; dpdk-dev <dev@dpdk.org>
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec
> support
> 
> External Email
> 
> ----------------------------------------------------------------------
> On 1/28/2020 8:29 AM, Jerin Jacob wrote:
> > On Mon, Jan 27, 2020 at 8:24 PM Anoob Joseph <anoobj@marvell.com>
> wrote:
> >>
> >> Hi Jerin, Akhil,
> >>
> >> Let me summarize the design changes from the discussions below.
> >>
> >> Currently, drivers/crypto/octeontx2/otx2_security.c defines all security ctx
> ops for the ethdev (idea was to add all crypto security ctx for lookaside also
> there). That will be moved to drivers/net/octeontx2 as is. The routines which are
> doing qp_add & qp_remove would be moved to common (discussed below).
> Otherwise, the rest should remain as is. If Jerin/Akhil wants further isolation,
> please do share specifics. Almost all functions in otx2_security.c is dereferencing
> 'rte_eth_dev'. So having (void *) will not help.
> >>
> >> The functions in otx2_security.c is calling inline functions in otx2_ipsec_fp.h
> (which has lower level implementations of session create etc). This will remain
> as is in drivers/crypto/octeontx2 but would be called from
> drivers/net/octeontx2/otx2_security.c.
> >>
> >> We will need to include otx2_cryptodev_qp.h (internal header in
> drivers/crypto/octeontx2) since the crypto queue pair is required for outbound
> processing. Since otx2_cryptodev_qp.h has dependency on rte_cryptodev.h, the
> ethdev file will have dependency on rte_cryptodev.h.
> >>
> >> I want all the maintainers (Akhil, Jerin & Ferruh) to ack the above
> >> behavior so that I can proceed with the restructuring. (Currently
> >> issue is rte_ethdev.h getting included in a cryptodev PMD file. The
> >> case we are proposing is the exact mirror of that)
> >
> > I think, Following rework would be required.
> >
> > 1) Don't access rte_eth_dev symbols in driver/crypto/octeontx2
> > 2) Don't access rte_crypto_dev symbols in drier/net/octeontx2
> > 3) Communication between both drivers should both through "custom
> > structure"(say struct otx2_eth_sec or so for inline, otx2_crypto_sec
> > for look side) defined in driver/common/octeonxt2 which holds data.
> > Processing function through "function pointer" registration provided
> > through in driver/common/octeonx2 as idev framework to avoid build
> > dependency.
> >
> 
> In high level this looks good to me.
> 
> > I am not sure anything else can be done beyond the above.
> >
>