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 <ano...@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 <ma...@mellanox.com> M: Shahaf Shuler <shah...@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.yi...@intel.com> > Sent: Tuesday, January 28, 2020 10:58 PM > To: Jerin Jacob <jerinjac...@gmail.com>; Anoob Joseph > <ano...@marvell.com> > Cc: Akhil Goyal <akhil.go...@nxp.com>; Declan Doherty > <declan.dohe...@intel.com>; Thomas Monjalon <tho...@monjalon.net>; Jerin > Jacob Kollanukkaran <jer...@marvell.com>; Narayana Prasad Raju Athreya > <pathr...@marvell.com>; Kiran Kumar Kokkilagadda > <kirankum...@marvell.com>; Nithin Kumar Dabilpuram > <ndabilpu...@marvell.com>; Pavan Nikhilesh Bhagavatula > <pbhagavat...@marvell.com>; Ankur Dwivedi <adwiv...@marvell.com>; > Archana Muniganti <march...@marvell.com>; Tejasree Kondoj > <ktejas...@marvell.com>; Vamsi Krishna Attunuru <vattun...@marvell.com>; > Lukas Bartosik <lbarto...@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 <ano...@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. > > >
