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

[Thomas Monjalon <thomas@monjalon.net>]

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?

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