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
next prev parent 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).