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