On Thu, Feb 6, 2020 at 8:48 PM Thierry Herbelot <[email protected]> wrote: > > 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,
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 > >
