> From: Thomas Monjalon <tho...@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
