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

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

[Thierry Herbelot]

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').

	Thanks

	Thierry

-- 
Thierry Herbelot
6WIND
Software Engineer

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

[Bruce Richardson]

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.

/Bruce

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

[Thierry Herbelot]

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

	Thanks

	Thierry

> 
> /Bruce
> 

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

[Jerin Jacob]

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

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

[Akhil Goyal]

Hi Bruce/Thierry,

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

This was followed in the past when rte_security was experimental
And we made sure that compilation should work even after disabling the
Lib. Now since the lib has been removed with the experimental tag, shall we
Follow the same in future as well. It depends on the community and the users
Of the code. If there is a valid use case, we can continue test compilation without
Rte_security.

-Akhil 

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

[Thierry Herbelot]

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,

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

In any case, as the compilation of DPDK is (still) driven by a separate 
configuration file, it should be possible that some combination of 
options are disabled, and still DPDK builds fine.

	Thierry

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


-- 
Thierry Herbelot
6WIND
Senior Software Engineer

Tel: +33 1 39 30 92 61
Fax: +33 1 39 30 92 11
thierry.herbelot@6wind.com
www.6wind.com
Immeuble Central Gare - Bât C 1, place Charles de Gaulle 78180 
Montigny-le-Bretonneux, France

Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné 
à son ou ses destinataires. Il contient des informations confidentielles 
qui sont la propriété de 6WIND. Toute révélation, distribution ou copie 
des informations qu'il contient est strictement interdite. Si vous avez 
reçu ce message par erreur, veuillez immédiatement le signaler à 
l'émetteur et détruire toutes les données reçues

This e-mail message, including any attachments, is for the sole use of 
the intended recipient(s) and contains information that is confidential 
and proprietary to 6WIND. All unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, 
please contact the sender by reply e-mail and destroy all copies of the 
original message.

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

[Jerin Jacob]

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?

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

> options are disabled, and still DPDK builds fine.
>
>         Thierry
>
> >
> >
> >
> >>
> >>          Thanks
> >>
> >>          Thierry
> >>
> >>>
> >>> /Bruce
> >>>
> >>
>
>
> --
> Thierry Herbelot
> 6WIND
> Senior Software Engineer
>
> Tel: +33 1 39 30 92 61
> Fax: +33 1 39 30 92 11
> thierry.herbelot@6wind.com
> www.6wind.com
> Immeuble Central Gare - Bât C 1, place Charles de Gaulle 78180
> Montigny-le-Bretonneux, France
>
> Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné
> à son ou ses destinataires. Il contient des informations confidentielles
> qui sont la propriété de 6WIND. Toute révélation, distribution ou copie
> des informations qu'il contient est strictement interdite. Si vous avez
> reçu ce message par erreur, veuillez immédiatement le signaler à
> l'émetteur et détruire toutes les données reçues
>
> This e-mail message, including any attachments, is for the sole use of
> the intended recipient(s) and contains information that is confidential
> and proprietary to 6WIND. All unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply e-mail and destroy all copies of the
> original message.

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

[Thierry Herbelot]

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,

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

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

[Jerin Jacob]

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