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". -------------------------- > > > BTW what is the need of a pmd API to configure the fpga? > > > Is it not possible to do that as one of rte_bbdev_ops ? > > > > This configuration is done agnostically of bbdev, the application doesn't > > need to > > know there is actual HW device requiring to be configured below the hood. > > Also this operation would be possible for the VF driver which doesn't have > > access to related registers. > > Typical deployment is within a container environment and this configuration > > is > > done without any need of any dependency on anything from librte_bbdev. > > > > Something we were considering was to push a standalone application (without > > dependency on BBDEV or even DPDK) to do that configuration from PF. > > Currently DPDK community are only able to run the PF driver, since to run > > from > > the VF would need a separate application to configure the device to allow > > usage from VF. > > We need to provide such application externally to DPDK currently (pretty > > much > > that function wrapped up with args and xml parsing). > > So we were wondering whether this could still be provided with DPDK (even if > > application has no DPDK dependency) or just push it externally on git hub. > > I see > > pros and cons, any view on that or similar concern for other crypto drivers?
