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 63802A04B3; Mon, 27 Jan 2020 12:26:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 386041BFAF; Mon, 27 Jan 2020 12:26:06 +0100 (CET) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 8E8AE1BFAE for ; Mon, 27 Jan 2020 12:26:05 +0100 (CET) Received: by mail-io1-f65.google.com with SMTP id s24so8005981iog.5 for ; Mon, 27 Jan 2020 03:26:05 -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=Uk9Xb9wFIq5HZWuIsotEEkXBWMARIDokWM7IuE/M/5M=; b=bvTFWDImjlR7KgpeVLzw1D4dsnbpPKxZW0y8XQI9eruYLf2WLOsqyGoFPEKBqqQtQw 2D/vJOI9Y14P9L/8RpiEkv5p3TZ9yrKLIXYD6Y+bDO12lsbFVTs/K7PxMeW0W7xkUWo0 jUJGhc+XCwUWjGpBtF1JzJbHLYB5MAbp5wgwSOaranDt5BFC7nzc4Yl3MWlnYTLVuSy5 +MaQrOtxSQmABK9F+Xg37vXyaJmHo38nQKJpkJ6IvJbl+fpTnNZF0SEUXiqwhz72hu4s cmzBqiaE+FTvRa0Nnw51QERaO3Bwcwbig3POOKg51UcOwWsKEIsLw6KEGUXdZzGOLMVD uDmQ== 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=Uk9Xb9wFIq5HZWuIsotEEkXBWMARIDokWM7IuE/M/5M=; b=R5+M9o52MvPAhkE4leTtRQU7eN0AO52w1lSrUtxK/h/62Kv176/ylaeGGrqlHXeLGX SCXLXO4tJj5gF+tksn0mMxeqruYlD1RUZ8YIAtBGF6m/tlHYKcswNOBpD7y2Jae1c8Yx B6LwVQL/3izWqyVeM40nrHCTexkyEL45QTpDhrSJEI5cQPbUCALiWo1LtkAFRxWsjOwo pAodwwa07uTKkGqLmFImHFYnj1ADsFK2N8pxPCFEK8eTaRFZqVNHaxrIDm5vPWfBKJLB Twk9hybOCOkKzl7qS98AQWnKV/ffYJ/osLqTy+EY+HnQcayQSLlbHr8ys8CRNd2LAkYk JKnw== X-Gm-Message-State: APjAAAWYh2FpUe6Qas/uD4LdiaeCz5X0OdYFKTEy0zM/l0jBPd4V7/XG r/6va/YCqk0+2afDEDOv56Pz73HjMGI/vAnOJDk= X-Google-Smtp-Source: APXvYqx3jMWuhEY+lA9L2aMNoe66T1uRG9D1fGkSwLu3lVC/7kK3OQm4Me1lf1dKkmCOS3Sc9XGSnmZkHn8aHaBm7KU= X-Received: by 2002:a02:cc75:: with SMTP id j21mr12628765jaq.113.1580124364776; Mon, 27 Jan 2020 03:26:04 -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: Mon, 27 Jan 2020 16:55:48 +0530 Message-ID: To: Akhil Goyal Cc: Anoob Joseph , 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 Mon, Jan 27, 2020 at 4:10 PM Akhil Goyal wrote: > > > > > > On Wed, Jan 22, 2020 at 6:26 PM Akhil Goyal 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. > > > >