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 20:18:27 +0530	[thread overview]
Message-ID: <CALBAE1N=r7ufzTFBnYxzXxNiuva-ti9oXJMkBAciT-dOLtgczg@mail.gmail.com> (raw)
In-Reply-To: <cd8cf24a-d4d6-2b05-9404-38b113b8b21d@6wind.com>

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.



>
>         Thanks
>
>         Thierry
>
> >
> > /Bruce
> >
>

  reply	other threads:[~2020-02-06 14:48 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 [this message]
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
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='CALBAE1N=r7ufzTFBnYxzXxNiuva-ti9oXJMkBAciT-dOLtgczg@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).