Re: [EXTERNAL] [PATCH] net/netvsc: Fix on race condition of multiple commands

[madhukar mythri <madhukar.mythri@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

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 <stephen@networkplumber.org> , 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, <stephen@networkplumber.org>
wrote:

> On Fri, 19 Dec 2025 17:35:33 +0000
> Long Li <longli@microsoft.com> 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.
>

[-- Attachment #2: Type: text/html, Size: 3158 bytes --]