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 76483A053B; Thu, 6 Feb 2020 16:39:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C07371C195; Thu, 6 Feb 2020 16:39:13 +0100 (CET) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 125EB1C038 for ; Thu, 6 Feb 2020 16:39:12 +0100 (CET) Received: by mail-il1-f193.google.com with SMTP id p8so5418941iln.12 for ; Thu, 06 Feb 2020 07:39:12 -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=DVwoM805panhG7df04YqMFt/PO85gx4V+AmFtnNoXVA=; b=HWcWFJTF9nNSNUsugsEkFFEt0A5kcDl223+ceXrgDyORGkVXFe68vSrIpVgrP+kEGs EdeWsv9nXJ3NKWS4dVQRQnLQETLbFH0vuP35x/8XHTO/tgaafqFr1gHBxlEBU+1TjSId OK6TzebW7Z9m1AnkEpWRVOSURwM3CasVIOQ1nlNzSM/dHTJf2jAFERI3QE6Y50quQTxR bW8X7bU0dcMxmETZwzMg1xJYYoyqQg5bhMk+5+bxqY0oLYdKYMTZX6KW7sk8bikWOU91 cowQw9eIXJ9fVj4Vwwbe9hRx8w0gaX823VIWrxHRjZXjfP5S3YZoJBe5A+X7iazyuhc7 XdTg== 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=DVwoM805panhG7df04YqMFt/PO85gx4V+AmFtnNoXVA=; b=Hv7CImKQkDvaMMQPIAYVSJcjuGv+VnJhjYrt5mDwDlQ5nBNpBbTYYUtPK9nLl42PVq MqJ7ossZsJQLT4012CPteIs6uubBYRHAHFvvPz/3MLgysHIjpwMTPocU7q+hymSaf5jD kEGSbJ8cWSS+1Ssy2SoplRPNquueBoWuV3ldA5j0UQTr6/NPvGS5ywjc4YBjkuesfn+l XPW/MJngSqFp04fS17aG2JMCpApBczRVZYvZPPYdYLDFStUQhL7BRMUPaBAKEPqNWupX ixbcEhj6e/aOVoW7dwAUqJuQ7Hi3jFTgTTAQipukEzKUxXLKyIprXZY2ZQbXajDzzcgf UwZg== X-Gm-Message-State: APjAAAW/PXDp4m3zlk7XmdPC8CZWg0rwxXRRDGovJwOAK+WC5dM8w3cV 1Ro4BiwVt5jDk5IQi3IKtMIlpnUH8Mf4dhaDQrY= X-Google-Smtp-Source: APXvYqwrcz1Rs4QqAYeb4tBGExVNWuoAUMiXmZzpfWE67B7pcFf9LeDUZEnKTme9KJxclgT9pwheAuiDmfVRo1rKNRs= X-Received: by 2002:a05:6e02:f47:: with SMTP id y7mr4594406ilj.162.1581003551226; Thu, 06 Feb 2020 07:39:11 -0800 (PST) MIME-Version: 1.0 References: <20200206142749.GA777@bricha3-MOBL.ger.corp.intel.com> <256f5d9f-ca90-8946-64c0-319a886bff3a@6wind.com> <70289e72-5311-2316-3f4f-7e7c054862dd@6wind.com> In-Reply-To: <70289e72-5311-2316-3f4f-7e7c054862dd@6wind.com> From: Jerin Jacob Date: Thu, 6 Feb 2020 21:08:55 +0530 Message-ID: To: Thierry Herbelot Cc: Bruce Richardson , "dev@dpdk.org" , Anoob Joseph , Akhil Goyal Content-Type: text/plain; charset="UTF-8" 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 Thu, Feb 6, 2020 at 8:48 PM Thierry Herbelot wrote: > > 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, Hello Thierry, > > 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'. If you are not using the octeontx2 driver and it will be unused. But if you are using the octeontx2 driver anyway there is a dependency that we can not avoid it. So are we gaining anything here? > > Precisely in a context of security code, it seems strange to bundle > unused code in a larger application. Now that rte_secuirty is not experimental. Maybe there should different treatment. Assuming someone else needs to disable yet another library say RTE_LIBRTE_CRYPTODEV, again we are back to square one. So I think, we need to have a policy on minimal dependency. > > > > >> 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, But meson does not allow disabling the libraries. If the stack has some other dependency on such assumptions, I think, better to improve that now, in the view of meson build in mind. > so ... > > Thierry > > > > >> options are disabled, and still DPDK builds fine. > >> > >> Thierry > >> > >>> > >>> > >>> > >>>> > >>>> Thanks > >>>> > >>>> Thierry > >>>> > >>>>> > >>>>> /Bruce > >