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 7EAB7A053C; Thu, 6 Feb 2020 16:18:07 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2162B1C135; Thu, 6 Feb 2020 16:18:07 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 32A451C11D for ; Thu, 6 Feb 2020 16:18:05 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id w12so7689156wrt.2 for ; Thu, 06 Feb 2020 07:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yt2wYd5YtL9RhCagJLSxtwDkjEqRMylzv/l4uvI728c=; b=HZ8s2ub78vlz9kCgeHGP/zWphN34nvD3jYJiNH6QEGqN3rjJyuRl21Zn4aDj8lGclX WuRTY7q1aLM3UezDexdAl6yMz3NWJairFd1i1PZMUvfE9dDYsD+/MgvQwHcLwZB04+qz X8c8jlEIiNmCDOTSLr+6AIyI9fOyRoo1u+dYEh1KgKxAffDTRdA8T6CS2bTL+UgScbWF 6qMCB0Lcq6TwwpNcCjXxXAr/xDvpCff4Zn/TjleEBr/mXDHJVN78xyXvTp3hDm84B1rT NE++VIfXACl4ce/+VDmMEIUuBb6tvXFkdCcPpjOSi+CbY2XMh74syuZjYTy/0iPRQP6v dskg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yt2wYd5YtL9RhCagJLSxtwDkjEqRMylzv/l4uvI728c=; b=E7aWUom/4GZ7INXYxVNJTPvmAHKvrN0MkRrUz+4IJEg6MbA+UvY/19xqKLjvX8TPdG hPvLBjlqgf9h9ppamJjEH2JynJow98hX0gAyfkAKANMSlDUVzoVQpVogp/pqYa3VK2E5 UqB6yjlu+HvJXqd7DUQe0yme963RcO6yyy9VncEaaD6CHpHGM0UmT0EfH2k5dBJBV+vI mQRZOdyxCLRVbzcXDwNONa5gvfAkCVk0KzZHXLIRDNpr2+u8xo/TfiuTrrf9++1XZTGc a5GK6WOUDLhnqXU5P1N1xsc0YMH+upS56wl6+q4gVB5UWhTGP0odGPuQaUrVAT1usWGL +U2Q== X-Gm-Message-State: APjAAAViLUgGGZrBJDVFB8fEWsT18W4sXC1p5yf+8y/pwmZnvgJf9sp/ oNEswnOiAtmgexZGhYl6RFY4E+arY3xy X-Google-Smtp-Source: APXvYqzXK5yzgMS6Nsn7FpdgRnXG0ie+XnA7l7U9f4PV+NssXL9WNkV4kpUK30K+EvBsKyux3Uz4iA== X-Received: by 2002:adf:dd4d:: with SMTP id u13mr4587702wrm.394.1581002284872; Thu, 06 Feb 2020 07:18:04 -0800 (PST) Received: from [10.16.0.208] (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v8sm4712654wrw.2.2020.02.06.07.18.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Feb 2020 07:18:04 -0800 (PST) To: Jerin Jacob Cc: Bruce Richardson , "dev@dpdk.org" , Anoob Joseph , Akhil Goyal References: <20200206142749.GA777@bricha3-MOBL.ger.corp.intel.com> <256f5d9f-ca90-8946-64c0-319a886bff3a@6wind.com> From: Thierry Herbelot Message-ID: <70289e72-5311-2316-3f4f-7e7c054862dd@6wind.com> Date: Thu, 6 Feb 2020 16:18:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] drivers/octeontx2: compilation fails without RTE_LIBRTE_SECURITY 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 2/6/20 4:06 PM, Jerin Jacob wrote: > On Thu, Feb 6, 2020 at 8:26 PM Thierry Herbelot > wrote: >> >> On 2/6/20 3:48 PM, Jerin Jacob wrote: >>> On Thu, Feb 6, 2020 at 8:06 PM Thierry Herbelot >>> wrote: >>>> >>>> On 2/6/20 3:27 PM, Bruce Richardson wrote: >>>>> On Thu, Feb 06, 2020 at 02:39:28PM +0100, Thierry Herbelot wrote: >>>>>> Hello, >>>>>> >>>>>> When RTE_LIBRTE_SECURITY is disabled, compilation fails for octeontx2 (on an >>>>>> Intel machine): >>>>>> >>>>>> git clone git://dpdk.org/dpdk >>>>>> cd dpdk >>>>>> make config T=x86_64-native-linux-gcc >>>>>> cd build >>>>>> vi .config >>>>>> => disable RTE_LIBRTE_IPSEC and RTE_LIBRTE_SECURITY >>>>>> make >>>>>> ... >>>>>> == Build drivers/net/octeontx2 >>>>>> CC otx2_rx.o >>>>>> In file included from .../dpdk/drivers/net/octeontx2/otx2_ethdev_sec.h:10, >>>>>> from .../dpdk/drivers/net/octeontx2/otx2_rx.h:11, >>>>>> from .../dpdk/drivers/net/octeontx2/otx2_ethdev.h:24, >>>>>> from .../dpdk/drivers/net/octeontx2/otx2_rx.c:7: >>>>>> .../dpdk/drivers/crypto/octeontx2/otx2_ipsec_fp.h:9:10: fatal error: >>>>>> rte_security.h: No such file or directory >>>>>> #include >>>>>> ^~~~~~~~~~~~~~~~ >>>>>> compilation terminated. >>>>>> >>>>>> This seems cause by f44e7163775537 ('net/octeontx2: add security session >>>>>> operations'). >>>>>> >>>>> Disabling parts of the build, particularly libraries, is always likely to >>>>> cause other build failures. I'm not sure we should, or even need to, >>>>> support the disabling of arbitrary libs in DPDK. >>>> >>>> Hello, >>>> >>>> On the other hand, there is no reason delivering unused code in a DPDK >>>> application: an application should be free to select its needed 'modules'. >>> >>> Just to understand the use case, What would be the downside of >>> compiling unwanted code? >>> In meson, it takes only jiffies to compile code and If we use, >>> -no-whole-archive then the generated binary will not be bloated, >>> Considering the case where "make" build system will be deprecated soon >>> and, for meson, I don't think, we are >>> planning to take the route of disabling the "core libraries". >>> >>> Could you share the real-world use for this? >>> My only concern is we can not make tons of #define in the driver code. >>> So, eventually, we end up >>> disabling the driver. >> >> Hello Jerin, > > Hello Thierry, > >> >> Our use case is that IPsec is provided as part of 6WIND stack, not using >> the version from DPDK (we are using the crypto PMDs from DPDK). > > I see. But still, I don't see any issue even If the 6WIND stack is not using any > security or IPsec lib files. Both library and header files will be just unused > in the install directory. Right? Or am I missing something? Hello Jerin, All calls to libsecurity will still be part of the octeontx2 driver (by way of otx2_ethdev_sec.c), so the library will not be 'just unused in the install drectory'. Precisely in a context of security code, it seems strange to bundle unused code in a larger application. > >> In any case, as the compilation of DPDK is (still) driven by a separate >> configuration file, it should be possible that some combination of > > No configuration file option with meson to opt-in and opt-out the library. Indeed a better wording would be: the compilation of DPDK can be driven by a separate configuration file, so ... Thierry > >> options are disabled, and still DPDK builds fine. >> >> Thierry >> >>> >>> >>> >>>> >>>> Thanks >>>> >>>> Thierry >>>> >>>>> >>>>> /Bruce