DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thierry Herbelot <thierry.herbelot@6wind.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Anoob Joseph <anoobj@marvell.com>,
	Akhil Goyal <akhil.goyal@nxp.com>
Subject: Re: [dpdk-dev] drivers/octeontx2: compilation fails without RTE_LIBRTE_SECURITY
Date: Thu, 6 Feb 2020 16:18:03 +0100	[thread overview]
Message-ID: <70289e72-5311-2316-3f4f-7e7c054862dd@6wind.com> (raw)
In-Reply-To: <CALBAE1NqHf4biRAoc1kcZ-GmFPs+0RrprSNoH-Xc+n7eZuSdYQ@mail.gmail.com>

On 2/6/20 4:06 PM, Jerin Jacob wrote:
> On Thu, Feb 6, 2020 at 8:26 PM Thierry Herbelot
> <thierry.herbelot@6wind.com> wrote:
>>
>> On 2/6/20 3:48 PM, Jerin Jacob wrote:
>>> On Thu, Feb 6, 2020 at 8:06 PM Thierry Herbelot
>>> <thierry.herbelot@6wind.com> 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 <rte_security.h>
>>>>>>              ^~~~~~~~~~~~~~~~
>>>>>> 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



  reply	other threads:[~2020-02-06 15:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 13:39 Thierry Herbelot
2020-02-06 14:27 ` Bruce Richardson
2020-02-06 14:36   ` Thierry Herbelot
2020-02-06 14:48     ` Jerin Jacob
2020-02-06 14:56       ` Thierry Herbelot
2020-02-06 15:06         ` Jerin Jacob
2020-02-06 15:18           ` Thierry Herbelot [this message]
2020-02-06 15:38             ` Jerin Jacob
2020-02-06 14:54   ` Akhil Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70289e72-5311-2316-3f4f-7e7c054862dd@6wind.com \
    --to=thierry.herbelot@6wind.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinjacobk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).