On Wed, 30 Apr 2025 22:00:29 +0530 Prashant Upadhyaya <praupadhy...@gmail.com> wrote:
> On Wed, 30 Apr 2025 at 19:58, Stephen Hemminger <step...@networkplumber.org> > wrote: > > > On Wed, 30 Apr 2025 13:00:53 +0530 > > Prashant Upadhyaya <praupadhy...@gmail.com> wrote: > > > > > > With DPDK on Azure, an application should never use the VF directly. > > > > It needs to use either netvsc PMD which handles both the vmbus (slow > > path) > > > > and VF (fast path) combined. Or use the older vdev_netvsc/failsafe/tap > > > > combination. > > > > The latter uses a virtual device to make a failsafe PMD which then does > > > > a combination of TAP (via kernel slow path) and MLX5 VF. The failsafe > > PMD > > > > is what is exposed for application usage. > > > > > > > > The limitations are not explicitly mentioned in the documentation but: > > > > - don't use VF directly in application > > > > - there is no support for bifurcation where some packets go to kernel > > > > and some to DPDK > > > > - there is only very limited support for rte_flow; that is with > > failsafe > > > > PMD > > > > (not netvsc PMD) and the limitations are that the emulation of > > rte_flow > > > > in the TAP device only supports a few things. > > > > > > > > > > Thanks Stephen, the above information was very instructive. > > > If I do use the Netvsc PMD with the latest DPDK, will my DPDK app get the > > > non IP packets like ARP, please confirm. > > > I quickly tried the Netvsc PMD but don't seem to be getting the ARP > > packets > > > in still. > > > When you mention "The failsafe PMD is what is exposed for application > > > usage", what is the meaning of this, are the apps expected to use > > failsafe > > > PMD, please suggest. > > > > > > Regards > > > -Prashant > > > > ARP handled differently in virtual network environments. The ARP packets > > sent > > get consumed and replied to by the network infrastructure (in all virtual > > networks > > not just Azure). Non-IP packets always show up on the synthetic VMBus > > device. > > > > Current docs are here: > > > > https://learn.microsoft.com/en-us/azure/virtual-network/setup-dpdk?tabs=redhat > > > > See vdev_netvsc for picture. > > https://doc.dpdk.org/guides/nics/vdev_netvsc.html > > > > > > Thanks again Stephen. I finally was able to run the netvsc pmd and it is > detecting the ports. > However, for every accelerated networking interface of Azure, it detects > 'two' ports. This is presumably for controlling both the slow and fast path > ? > This poses an issue for my app as it wanted to see only 'one' interface in > its control as a lot of business logic is kind of tied to it. > So a question -- am I observing correctly that DPDK, in case of netvsc, > will enumerate two ports for each accelerated networking interface ? > > Regards > -Prashant The hidden VF interfaces are "owned" in DPDK. If you use the standard API's in ethdev it will skip the owned interfaces. /** * Macro to iterate over all enabled and ownerless ethdev ports. */ #define RTE_ETH_FOREACH_DEV(p) \ RTE_ETH_FOREACH_DEV_OWNED_BY(p, RTE_ETH_DEV_NO_OWNER)
