> 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.
- 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.
Thanks,
Nic
