Re: [dpdk-dev] drivers/octeontx2: compilation fails without RTE_LIBRTE_SECURITY

[Jerin Jacob <jerinjacobk@gmail.com>]

On Thu, Feb 6, 2020 at 8:48 PM Thierry Herbelot
<thierry.herbelot@6wind.com> wrote:
>
> 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,

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
>
>