Hi Long, Yes, got it. By caching the results of 'hn_rndis_query_hwcaps()' inside PMD will be better. Yes, you can submit the patch 'Or' let me know, if you are busy.
Thanks, Madhukar. On Thu, Jan 1, 2026 at 4:52 AM Long Li <[email protected]> wrote: > Hi Madhukar, > > > > I suggest caching the result of hn_rndis_query_hwcaps(), as suggested by > Stephen. This can be done inside PMD. Do you want me to submit a patch? > > > > For querying link status, the lock should be implemented inside > hn_rndis_exec1(). The drawback is that this function can potentially wait > for up to 60 seconds on response from host, maybe not suitable for spinlock > in production use. But I think it’s better to have application retry on > BUSY (with some delay logic), as the netvsc is designed in this way since > introduced. > > > > Thanks, > > Long > > > > > > > > *From:* madhukar mythri <[email protected]> > *Sent:* Saturday, December 20, 2025 9:37 PM > *To:* Stephen Hemminger <[email protected]> > *Cc:* Long Li <[email protected]>; [email protected]; Madhuker Mythri < > [email protected]> > *Subject:* Re: [EXTERNAL] [PATCH] net/netvsc: Fix on race condition of > multiple commands > > > > You don't often get email from [email protected]. Learn why this > is important <https://aka.ms/LearnAboutSenderIdentification> > > 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. > >
