[dpdk-dev] [PATCH 2/3] net/ixgbe: fix build issue

Akhil Goyal akhil.goyal at nxp.com
Thu Oct 26 15:16:38 CEST 2017


On 10/26/2017 6:37 PM, Thomas Monjalon wrote:
> 26/10/2017 14:59, Akhil Goyal:
>> Hi Thomas,
>>
>> On 10/26/2017 6:03 PM, Thomas Monjalon wrote:
>>> 26/10/2017 14:28, Radu Nicolau:
>>>>
>>>> On 10/26/2017 12:39 PM, Thomas Monjalon wrote:
>>>>> 26/10/2017 13:27, David Marchand:
>>>>>> On Thu, Oct 26, 2017 at 1:01 PM, Radu Nicolau <radu.nicolau at intel.com> wrote:
>>>>>>> On 10/26/2017 11:36 AM, David Marchand wrote:
>>>>>>>> On Thu, Oct 26, 2017 at 12:22 PM, Radu Nicolau <radu.nicolau at intel.com>
>>>>>>>> wrote:
>>>>>>>>> --- a/drivers/net/ixgbe/Makefile
>>>>>>>>> +++ b/drivers/net/ixgbe/Makefile
>>>>>>>>> +ifneq ($(MAKECMDGOALS),clean)
>>>>>>>>> +ifneq ($(CONFIG_RTE_LIBRTE_SECURITY),y)
>>>>>>>>> +$(error "RTE_LIBRTE_SECURITY is required to build RTE_LIBRTE_IXGBE_PMD")
>>>>>>>>> +endif
>>>>>>>>> +endif
>>>>>>>> This is a no go for me unless you explain how it is impossible to
>>>>>>>> disable it in the code.
>>>>>>>>
>>>>>>>>
>>>>>>> It can be disabled in the code, but as far as I know there is a general push
>>>>>>> back against having conditionally compiled code. I originally had the
>>>>>>> security sections in ixgbe PMD isolated, but the feedback was to have them
>>>>>>> always on.
>>>>>> In my mind, this was to stop having features enabled per pmd (and stop
>>>>>> the nightmare with 10 options in a pmd).
>>>>>> Having features globally enabled for all or nothing is still
>>>>>> acceptable, is it not ?
>>>>> Yes there is a config option for rte_security,
>>>>> and it is acceptable.
>>>>> The code depending on it must be ifdef'ed.
>>>>
>>>> Given that both ixgbe and dpaa2_sec are now security enabled PMDs, I
>>>> would go with Konstantin's proposal, have rte_security listed as a
>>>> dependency (instead of the explicit check).
>>>
>>> Please consider my request instead.
>>> Until now we are ifdef'ing code to allow disabling any lib.
>>> We are not going to change our mind during the last days of a release.
>>> Please just fix it for now.
>>
>> For dpaa2_sec we do not want to make the driver run without
>> rte_security. We do not see people using it without rte_security.
> 
> Why not?
We see a lot of performance difference in the two cases. People may not 
like to see a lower performance for the same protocol processing.

> 
>> Will take the Makefile changes that Radu has done in 1st patch of this
>> series.
> 
> Is it really a lot to ifdef?
As I see it would be around 12-13 checks in 2 files.
> 
> It is going to break compilation of DPDK for those who disable rte_security.
> 

Well I would say, if people do not need rte_security then they can 
disable dpaa2_sec_pmd also.

-Akhil


More information about the dev mailing list