From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E76B6A04B3; Tue, 28 Jan 2020 09:56:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 578FC1C191; Tue, 28 Jan 2020 09:56:45 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id B71391BF87 for ; Tue, 28 Jan 2020 09:56:43 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id o13so9345094ilg.10 for ; Tue, 28 Jan 2020 00:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IcKtFdEs/7qNnxtzEjgjw9ZkrFP2SzQN17eO8Bywjxo=; b=J8tmEIRu9DO9+VuZ7BuLfTEGQKpq6+Vz5oGLxMPML7Yo94hukPj9OS+R/qtdrIWau5 28PX/RJ/YBa46yRaarNmTCqjW15PZcsPdNkV4UvUiC5TTTz8Q+ovv0ng3P9UhR4wWcXT mTrKwXdkTUUOyvrHE8E9sq2DAizWVv+lwaFpA8d+h7hsAThSA4ULi1PeYQYd1TSnuGHN 4Zf+7qDa7OzjpT0j4ksmutZJOxyyFKWJNGMuc/nuy2le+t1DD0Mmx8b+5GDvhoWA0zWO fKsVQSa5qdMYCiNf22teS+ORpkAzzb7PxgrdXJjiTVZ0qIFYD3/iGXricoaD2KlXYLTL U4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IcKtFdEs/7qNnxtzEjgjw9ZkrFP2SzQN17eO8Bywjxo=; b=rpl1ykGHnWNpVUZByy7fUOvvd2F2EGDGzzbbCTL9ltljPJ2MRNSgHwnkHG4DtYH30F 9D1G5Al5g7O0imM7G2c/4oMlBRMjl1cpw1pybetpuOqpJcrKXzK6La9kxazms91peEz+ MnUY6El/zgJO66UetK2RYdVnDq96BtWLEFDuuGaEBah3gQSyXZn9nxg3qb3JnuAm064t +C7EcTE2oD/yyiUNju8nfBZf5yislnVWpYS0eMv6FSZI9c3bbyzig7qyqLlYbKJKUtYg A2niBrsNIhjFelvvLY4insKe1KInsB4Yydyrqx/ZIcPluPqcx8OS4/zceVNACG1TSoSW h3FQ== X-Gm-Message-State: APjAAAXW920022xEjZTVCWcjIYbl/AfAyqrvg9RxISIc9CizZ5FQ5Rhv SGCFUkL+lGhQgCief+5Ac+7TmZNDJnFxicwPxnU= X-Google-Smtp-Source: APXvYqz8SEwvCUDz/yC112buRDwiXcxASHtsbR1uZ9NyCQR6OfrSw8kZvPNKMhsoAfSw3aoFGYnRnD282fM/69yqvfk= X-Received: by 2002:a92:1906:: with SMTP id 6mr19533360ilz.130.1580201802960; Tue, 28 Jan 2020 00:56:42 -0800 (PST) MIME-Version: 1.0 References: <1575806094-28391-1-git-send-email-anoobj@marvell.com> <1579344553-11428-1-git-send-email-anoobj@marvell.com> In-Reply-To: From: Jerin Jacob Date: Tue, 28 Jan 2020 14:26:26 +0530 Message-ID: To: Akhil Goyal Cc: Anoob Joseph , Ferruh Yigit , Declan Doherty , Thomas Monjalon , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Kiran Kumar Kokkilagadda , Nithin Kumar Dabilpuram , Pavan Nikhilesh Bhagavatula , Ankur Dwivedi , Archana Muniganti , Tejasree Kondoj , Vamsi Krishna Attunuru , Lukas Bartosik , dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 00/15] add OCTEONTX2 inline IPsec support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jan 28, 2020 at 2:08 PM Akhil Goyal wrote: > > Hi Jerin, Hi Akhil, > > > > On Mon, Jan 27, 2020 at 8:24 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) > > > > 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.