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 6FF7BA3160 for ; Thu, 10 Oct 2019 07:37:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE3591E8AB; Thu, 10 Oct 2019 07:37:06 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 17C7D1E8A4 for ; Thu, 10 Oct 2019 07:37:04 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id b136so10997404iof.3 for ; Wed, 09 Oct 2019 22:37:04 -0700 (PDT) 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=IN8389uuUeE0AErOMJl9EFx7T2dM1ejCNiFVuKjujZU=; b=gtID/fTtHd2W2m/nijN7nCY52X5+EVp/lUOXDeM9YIds7Uan4TKIk1jKcg1tvbE2zf 04Nq9kIguALKge5HGEQapYoMRrfsz6V12hHMaTqDREPBxJ2tcIyCuvUuQLut+3w+Kbnz fRP96+wMXHg/q9GxmoGe3XA4sruCMW3liAiaKozlUgbO8dhm0lBjiWR1xAjDiNyY7pv4 Z70dAW3GZ+dfNuty+lVu7NxKzyrvY7AZEHGdLBGEdr+4YIsoH/gBAJZY8kzAc4KF6RVY uAwp9mc3iEy7xA8Y7+D/Fgs6oPrM2SOLXNsEqP1CyZm0hkPgas2nWxdteDyngCrBBKWV d2uQ== 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=IN8389uuUeE0AErOMJl9EFx7T2dM1ejCNiFVuKjujZU=; b=KetIpUKlHf/rsXG6/HgfkOaNbKmxQcdBtAN+I2NBcTzBaisWqu8v7hh6P9p9Ny3ttl uR4rt70uO/JtH05rlazRuyDVnF3kZ+v/mN5wXRRdWO9DicgqHqGp+xkwcZZF3HU17Rkf 2iYXuti7NVZ2i4vs5MdlZzPIEMAPgKQiHCQdsCvGz1ryq152y3sKiAABMBCQ87fQDFRl 9edS+yolXzKYUwE6R0MFI5B2gZF8a+oSyHy9JNPOyRy4XdkQ4dqxAel7WMXHPJKrmD7D jU40O15bVZl/WnHqpMEx/AKVTZQTeSJtvUyz2IesxnA6jVJoo5u0Tf1yjvznPYvEqI+P Fjog== X-Gm-Message-State: APjAAAW1OJtZO2OLEZvncfg8uSTZ6Z0Tja/i08Dgds0ZtU2c28rz2yBh DXpHC5z/xGMkE+2w3Z7DBmOlH7LfAu/6h+VwipA= X-Google-Smtp-Source: APXvYqwvCUkPMwEYL++mSmwpyE1jUCaRRhoc/2dYV6LDVzx2alFvYmz8wASaYM9Mxzv/66N1c2JeX7qe4BYYBK0yzaw= X-Received: by 2002:a02:6d08:: with SMTP id m8mr8507822jac.34.1570685823103; Wed, 09 Oct 2019 22:37:03 -0700 (PDT) MIME-Version: 1.0 References: <20191003225732.13463-1-dharmik.thakkar@arm.com> <22790115.aVAZyMIHDd@xps> In-Reply-To: From: Jerin Jacob Date: Thu, 10 Oct 2019 10:54:31 +0530 Message-ID: To: Honnappa Nagarahalli Cc: Thomas Monjalon , Jerin Jacob , Dharmik Thakkar , "Akhil.goyal@nxp.com" , "hemant.agrawal@nxp.com" , "anoobj@marvell.com" , "pathreya@marvell.com" , Bruce Richardson , dpdk-dev , nd Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] crypto/armv8: enable meson build 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 Thu, 10 Oct, 2019, 10:17 AM Honnappa Nagarahalli, < Honnappa.Nagarahalli@arm.com> wrote: > > > > > On Mon, 7 Oct, 2019, 3:49 PM Jerin Jacob, wrote: > > > > On Sun, 6 Oct, 2019, 11:36 PM Thomas Monjalon, > wrote: > > 05/10/2019 17:28, Jerin Jacob: > > On Fri, Oct 4, 2019 at 4:27 AM Dharmik Thakkar > wrote: > > > > > > Add new meson.build file for crypto/armv8 > > > > > > Signed-off-by: Dharmik Thakkar > > > --- > > > drivers/crypto/armv8/meson.build | 25 +++++++++++++++++++++++++ > > > drivers/crypto/meson.build | 6 +++--- > > > meson_options.txt | 2 ++ > > > 3 files changed, 30 insertions(+), 3 deletions(-) > > > create mode 100644 drivers/crypto/armv8/meson.build > > > > > > > > option('allow_invalid_socket_id', type: 'boolean', value: false, > > > description: 'allow out-of-range NUMA socket id\'s for > platforms that don\'t report the value correctly') > > > +option('armv8_crypto_dir', type: 'string', value: '', > > > + description: 'path to the armv8_crypto library installation > directory') > > You should not need such option if you provide a pkg-config file > in your library. > > > > It is not specific to this patch but it is connected to this patch. > > > > Three years back when Cavium contributed to this driver the situation > > was different where only Cavium was contributing to DPDK and now we > > have multiple vendors from > > ARMv8 platform and ARM itself is contributing it. > > > > When it is submitted, I was not in favor of the external library. But > > various reasons it happened to be the external library where 90% meat > > in this library and shim PMD > > the driver moved to DPDK. > > > > Now, I look back, It does not make sense to the external library. > Reasons are > > - It won't allow another ARMv8 player to contribute to this library as > > Marvell owns this repo and there is no upstreaming path to this > > library. > > This is a real issue and you are able to fix it. > > > > Note sure how I can fix it and why I need to fix it. I just dont want to > start a parallel collaborating infrastructure for DPDK armv8. > > > > > > > - That made this library to not have 'any' change for the last three > > year and everyone have there owned copy of this driver. In fact the > > library was not compiling for last 2.5 years. > > - AES-NI case it makes sense to have an external library as it is a > > single vendor and it is not specific to DPDK. But in this, It is > > another way around > > I don't see how it is different, except it is badly maintained. > > > > It is different because only one company contributing to it. In this case, > multiple companies needs to contribute. > > > > The library badly maintained in upstream as there is no incentives to > upstream to external library. I believe each vendor has it own copy of > that. At least Some teams in Marvell internally has copy of it. > > What is their incentive to upstream? They ask me the same thing. > > > > > > > - If it an external library, we might as well add the PMD code as well > > there and that only 10% of the real stuff. > > We are not able able to improve anything in this library due to this > situation. > > > > Does anyone care about this PMD? If not, we might as well remove this > > DPDK and every vendor can manage the external library and external > > PMD(Situation won't change much) > > External PMD is bad. > > > > It is SHIM layer. I would say external library also bad if it is specific > to DPDK. > > > > I think this library should not be specific to DPDK, > > > > Sadly it is VERY specific to DPDK for doing authentication and encryption > in one shot to improve the performance. Openssl has already has armv8 > instructions support for doing it as two pass just that performance is not > good. For use cae such as IPsec it make sense do authentication and > encryption in one shot for performance improvement. > > *[Honnappa] *I think there is a need for such a library not just for > DPDK. It would be good if it could do UDP checksum validation for the inner > packet as well. > > > > so it would make sense as an external library > > > > If it an external library, it does NOT make much sense for Marvell to > maintain it(No incentive and it is pain due lack of collaboration) > > > > Either someone need to step up and maintain it if we NOT choose to make it > as external else we can remove the PMD from dpdk(Makes life easy for > everyone). I don't want to maintain something not upsteamble nor > collaboration friendly aka less quality. > > > > . > > > > > > Thoughts from ARM, other ARMv8 vendors or community? > > > > I have expressed my concerns. If there is no constructive feedback to fix > the concern. I will plan for submitting a patch to remove the shim crypto > Armv8 PMD from dpdk by next week. > > *[Honnappa] *I do not think there is a need to remove the PMD. As you > have mentioned, many might have developed their own libraries and may be > dependent on DPDK Armv8 PMD. > Problem with that approach is that, No convergence/collaboration on this PMD aka no improvement and less quality. >From Arm side, there have been efforts to fix the situation. Some have not > gone far and some have shown promise, but fell flat. I can say that this is > still a priority but I am not sure when we will have something. > If ARM is ready to take over the maintenance on PMD and external library then I am fine with any decision. Let us know. Personally, I don't like to maintain something not upsteamble friendly. My suggestion, we should go ahead with adding the meson build for this PMD. >