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 <[email protected]> +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 <[email protected]> M: Shahaf Shuler <[email protected]> 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 <[email protected]> > Sent: Tuesday, January 28, 2020 10:58 PM > To: Jerin Jacob <[email protected]>; Anoob Joseph > <[email protected]> > Cc: Akhil Goyal <[email protected]>; Declan Doherty > <[email protected]>; Thomas Monjalon <[email protected]>; Jerin > Jacob Kollanukkaran <[email protected]>; Narayana Prasad Raju Athreya > <[email protected]>; Kiran Kumar Kokkilagadda > <[email protected]>; Nithin Kumar Dabilpuram > <[email protected]>; Pavan Nikhilesh Bhagavatula > <[email protected]>; Ankur Dwivedi <[email protected]>; > Archana Muniganti <[email protected]>; Tejasree Kondoj > <[email protected]>; Vamsi Krishna Attunuru <[email protected]>; > Lukas Bartosik <[email protected]>; dpdk-dev <[email protected]> > 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 <[email protected]> > 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. > > >
