[dpdk-dev] [PATCH 09/22] net/bnxt: use dedicated cpr for async events

[Lance Richardson]

Yes, the platform can be detected at runtime
from the PCI device ID. This would be a better
approach than adding a configuration parameter,
I think. I'll take a look.

Thanks,

   Lance

On Tue, Jul 23, 2019 at 4:04 AM Thomas Monjalon <thomas at monjalon.net> wrote:
>
> 22/07/2019 20:34, Ferruh Yigit:
> > On 7/22/2019 6:57 PM, Lance Richardson wrote:
> > > On Mon, Jul 22, 2019 at 11:06 AM Thomas Monjalon <thomas at monjalon.net> wrote:
> > >> 22/07/2019 16:57, Ferruh Yigit:
> > >>> On 7/18/2019 4:36 AM, Ajit Khaparde wrote:
> > >>>> From: Lance Richardson <lance.richardson at broadcom.com>
> > >>>> --- a/config/common_base
> > >>>> +++ b/config/common_base
> > >>>> @@ -212,6 +212,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
> > >>>>  # Compile burst-oriented Broadcom BNXT PMD driver
> > >>>>  #
> > >>>>  CONFIG_RTE_LIBRTE_BNXT_PMD=y
> > >>>> +CONFIG_RTE_LIBRTE_BNXT_SHARED_ASYNC_RING=n
> > >>>
> > >>> Normally we don't want to introduce new config time options as much as possible.
> > >>>
> > >>> This is what happens when patches slip in the last minute, please Ajit try to
> > >>> send patches before proposal next time.
> > >>>
> > >>> And back to the config option, is it something have to be a compile time flag
> > >>> (if so why?), can it be replaced by a devarg?
> > >>
> > >> I confirm it is nack.
> > >> I don't see any reason not to replace it with a runtime devargs.
> > >
> > > This build-time configuration option was introduced because the
> > > "shared async completion
> > > ring" configuration is needed for one specific platform,
> > > arm64-stingray-linux-gcc. This
> > > configuration has a number of drawbacks and should be avoided
> > > otherwise. Making it
> > > a run-time option will add complexity and introduce the possibility
> > > that existing stingray
> > > users will not know that they need to specify this option as of 19.08,
> > > so it would be good
> > > if some other way could be found to handle this.
> >
> > I see this provides a configuration transparent to user, but won't this kill the
> > binary portability? If a distro packages an 'armv8a' target and distributes it,
> > this won't be usable in your 'stingray' platform for the driver.
> >
> > But if this is added as a devargs, it can be usable even with distributed
> > binaries, by providing proper devargs to binary for a specific platform. And
> > documenting this devargs in NIC guide can help users to figure it out.
> >
> > > Other than perhaps using RTE_ARCH_ARM64 to select the shared completion ring
> > > configuration (which would obviously affect all ARM64 users), are
> > > there any other options
> > > that might be acceptable?
>
> Can you detect the platform in the PMD?
>
>