On 2/6/20 4:06 PM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 8:26 PM Thierry Herbelot
<[email protected]> wrote:

On 2/6/20 3:48 PM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 8:06 PM Thierry Herbelot
<[email protected]> 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 via email to