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

[Thomas Monjalon]

26/10/2017 15:16, Akhil Goyal:
> 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.

OK