Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec support

[Ferruh Yigit <ferruh.yigit@intel.com>]

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.
>