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.
