Hi Li and Stephen, We have a common DPDK application for all the PMD's, in which we are seeing issue for this Netvsc PMD only. I mean, for KVM hypervisor with Intel or Mellanox NICs we did not see such sync issues. Also, with failsafe PMD on hyper-v did not seen such sync issues.
So, i thought this would be better to fix at PMD level using spinlock. @Stephen Hemminger <[email protected]> , yes we can store the device info get details after probe and reuse it later. For Link-status get with multiple threads we can go with retry mechanism. However, w.r.t all other PMD's this device info get and Link-status get has issues in multi threaded application. Regards, Madhuker. On Sat, 20 Dec, 2025, 23:55 Stephen Hemminger, <[email protected]> wrote: > On Fri, 19 Dec 2025 17:35:33 +0000 > Long Li <[email protected]> wrote: > > > > When multiple processes issue command requests(like: device info get > and > > > link-status) at same-time, then we could see the command request > failures, > > > due to race-condition of common function execution. > > > > Hi Madhuker, > > > > I'm not sure if we should use a lock in the driver for this. It's not > clear in DPDK documents but in general the calls to query device status are > not thread safe. > > > > Is it possible that the application uses a lock to sync calling to this? > > > > I do not know of any restrictions about threads calling query operations. > > For info_get() the transaction is in rndis_get_offload(). > There are couple of ways to handle this better. One would to do > the query during probe and remember the result. The hypervisor is > not going to change supported offload. The other and simpler way > would be to just have hardcoded offload values. The code for query > got compute offloads is inherited for BSD and unless someone was trying > to run on Windows 2012 or earlier version of Hyper-V it would never change. > > Link status is a little more complex. Does the hyper-visor ever report > that the software path is down? And reading through the hn_rdis_exec code > it looks like if multiple operations are in process the second one > should return -EBUSY. Application could retry in that case. >
