DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Thierry Herbelot <thierry.herbelot@6wind.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 21:08:55 +0530	[thread overview]
Message-ID: <CALBAE1MrYvovAveBVxm13_rnDps-RRZtCGHtpHSEgAdCrs-sZQ@mail.gmail.com> (raw)
In-Reply-To: <70289e72-5311-2316-3f4f-7e7c054862dd@6wind.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
>
>

  reply	other threads:[~2020-02-06 15:39 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
2020-02-06 15:38             ` Jerin Jacob [this message]
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=CALBAE1MrYvovAveBVxm13_rnDps-RRZtCGHtpHSEgAdCrs-sZQ@mail.gmail.com \
    --to=jerinjacobk@gmail.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=thierry.herbelot@6wind.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).