Re: [dpdk-dev] [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function

["Chautru, Nicolas" <nicolas.chautru@intel.com>]

> From: Thomas Monjalon <thomas@monjalon.net>
> 26/06/2020 03:14, Chautru, Nicolas:
> > > From: Thomas Monjalon
> > > 25/06/2020 02:30, Chautru, Nicolas:
> > > > > From: Thomas Monjalon :
> > > > > 02/05/2020 01:15, Chautru, Nicolas:
> > > > > > Hi Akhil, Thomas,
> > > > > >
> > > > > > Following up on that previous discussion below so that to
> > > > > > confirm whether
> > > > > there is an available option to handle this usecase within DPDK repo.
> > > > > >
> > > > > > Basically traditional deployment for VRAN relies on BBDEV/DPDK
> > > > > > running
> > > > > within container where the workload is processed behind BBDEV
> > > > > API bounded to a VF of the accelerator, all that is fully
> > > > > covered currently in
> > > 20.05.
> > > > > > Conversely an application from baremetal still has to be run
> > > > > > at initialization
> > > > > to do the required register poking to PF MMIO so that to
> > > > > configure the HW so that the VF is functional. Without this it
> > > > > is not possible to use the VF driver form within the container.
> > > > > Said otherwise the BBDEV VF PMD cannot be even tested with DPDK
> > > > > repo (only the PF PMD with the workaround discussed in the previous
> discussion).
> > > > > > That small userspace application is purely doing mmap and
> > > > > > writing to
> > > > > register based on xml file input (relying on igb_uio bounded to
> > > > > PF, or other vanilla kernel module) and has no dependency on
> > > > > rest of DPDK (DPDK would not be installed outside of the
> > > > > container since no packet or wireless workload is actually run from
> there).
> > > > > > Is that sensible to add such a small companion application
> > > > > > within the
> > > > > related PMD directory even if it has no dependency on DPDK
> > > > > libraries per se, only the fact that is required just to be able
> > > > > to use BBDEV from the
> > > VF.
> > > > > > On one hand I see reason not to do this as this is not a DPDK
> > > > > > application per
> > > > > se, but that companion HW application is still required to be
> > > > > able for anyone to use BBDEV driver + being within the same repo
> > > > > enforces that there is no risk of version mismatch. The other
> > > > > option being to put that on a separate repo outside of DPDK
> > > > > causing fragmentation of
> > > ingredients across repos.
> > > > > >
> > > > > > I wanted to check whether you had any strong opinion on this
> > > > > > topic and
> > > > > whether a patch with such a companion simple user application
> > > > > may be approved.
> > > > >
> > > > > I feel it is best to have the required app in the PMD directory,
> > > > > as in "batteries included".
> > > > >
> > > >
> > > > Hi Thomas,
> > > > For such a companion application to configure the HW within the
> > > > PMD
> > > directory I want to confirm two things before pushing a patch :
> > > > 	- This is okay with you for it to build outside of the DPDK build flow.
> > > Ie. Separate Makefile, not planning meson support. Again zero DPDK
> > > libraries dependency.
> > >
> > > I think it should be built as part of the PMD.
> > > Why not?
> >
> > For the same reason as above : you would not deploy this companion
> application in the same OS or container/VM as DPDK; they would be built
> without dependency on each other, but still provided together so that you
> can actually have all the ingredients in one place without mismatch and be
> able to actually use the PMD will all required ingredients in one place.
> 
> OK I missed the DPDK environment is not the same as the environment of the
> companion application.
> 
> > Also based on the dependency below, even if adding option to build within
> same DPDK meson framework, it would not build by default by anyone as the
> dependency repo would be lacking.
> 
> What is the dependency? I assume it is freely and easily downloadable.
> 
> > For that reason that would be a bit artificial to me to be built with the PMD
> really, but I could be convinced otherwise.
> > Any thought Thomas?
> 
> OK
> If you think the application is tightly related to the PMD, I think it could be
> hosted with it.
> 
> 
> > > > 	- This is okay with you for it to have dependency on other open-
> > > source library to build it. Ie. we are currently linking to this
> > > https://github.com/benhoyt/inih (BSD license) as a simple input
> > > config file parsing.
> > >
> > > No problem with dependencies.
> 
> 

Hi, 
Note that the related contribution is capture on this new patchset.
http://patches.dpdk.org/patch/73785/

Thanks
Nicolas