<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 30 Apr 2025 at 19:58, Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 30 Apr 2025 13:00:53 +0530<br>
Prashant Upadhyaya <<a href="mailto:praupadhyaya@gmail.com" target="_blank">praupadhyaya@gmail.com</a>> wrote:<br>
<br>
> > With DPDK on Azure, an application should never use the VF directly.<br>
> > It needs to use either netvsc PMD which handles both the vmbus (slow path)<br>
> > and VF (fast path) combined. Or use the older vdev_netvsc/failsafe/tap<br>
> > combination.<br>
> > The latter uses a virtual device to make a failsafe PMD which then does<br>
> > a combination of TAP (via kernel slow path) and MLX5 VF.  The failsafe PMD<br>
> > is what is exposed for application usage.<br>
> ><br>
> > The limitations are not explicitly mentioned in the documentation but:<br>
> >   - don't use VF directly in application<br>
> >   - there is no support for bifurcation where some packets go to kernel<br>
> >     and some to DPDK<br>
> >   - there is only very limited support for rte_flow; that is with failsafe<br>
> > PMD<br>
> >     (not netvsc PMD) and the limitations are that the emulation of rte_flow<br>
> >     in the TAP device only supports a few things.<br>
> >  <br>
> <br>
> Thanks Stephen, the above information was very instructive.<br>
> If I do use the Netvsc PMD with the latest DPDK, will my DPDK app get the<br>
> non IP packets like ARP, please confirm.<br>
> I quickly tried the Netvsc PMD but don't seem to be getting the ARP packets<br>
> in still.<br>
> When you mention "The failsafe PMD is what is exposed for application<br>
> usage", what is the meaning of this, are the apps expected to use failsafe<br>
> PMD, please suggest.<br>
> <br>
> Regards<br>
> -Prashant<br>
<br>
ARP handled differently in virtual network environments. The ARP packets sent<br>
get consumed and replied to by the network infrastructure (in all virtual networks<br>
not just Azure). Non-IP packets always show up on the synthetic VMBus device.<br>
<br>
Current docs are here:<br>
<a href="https://learn.microsoft.com/en-us/azure/virtual-network/setup-dpdk?tabs=redhat" rel="noreferrer" target="_blank">https://learn.microsoft.com/en-us/azure/virtual-network/setup-dpdk?tabs=redhat</a><br>
<br>
See vdev_netvsc for picture. <a href="https://doc.dpdk.org/guides/nics/vdev_netvsc.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/nics/vdev_netvsc.html</a><br>
<br>
<br></blockquote><div>Thanks again Stephen. I finally was able to run the netvsc pmd and it is detecting the ports.</div><div>However, for every accelerated networking interface of Azure, it detects 'two' ports. This is presumably for controlling both the slow and fast path ?</div><div>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.</div><div>So a question -- am I observing correctly that DPDK, in case of netvsc, will enumerate two ports for each accelerated networking interface ?</div><div><br></div><div>Regards</div><div>-Prashant</div><div> </div></div></div>