From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 56E5747158; Thu, 1 Jan 2026 18:43:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ADC6340267; Thu, 1 Jan 2026 18:43:15 +0100 (CET) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by mails.dpdk.org (Postfix) with ESMTP id 47A7040262 for ; Thu, 1 Jan 2026 18:43:14 +0100 (CET) Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7c7aee74dceso4513087a34.2 for ; Thu, 01 Jan 2026 09:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767289393; x=1767894193; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z1KPrbZkeJravhqXr5etlOZIy+Y+YVyp19bUIcMGK94=; b=I3BozKd+3RhMd3ehJp5UaS4nxC/Sw9rNf0Phh1+SCfjePG/MuxVqXjo5KMcXGkj1t9 xscNR9i1oSIhz2ylIHJgmGl/UDURC5Y069P0OofaAQXawd1yQ8scTs9Lqnf8LI1KSlEs NGOnGZsY8IsqIejlpgwbSir7N9ZlMDtZttIgWtRCe5s8h8UWiEnFEUIdKE4C0I3Ble4I ejobcMc9uZ6awKVHJ5de+G37rr4qvBDsFjlFj+19zo6h4LH0U+rqmnI8okZ0HXZ/AYak pmjBAXUIXpAa7erwmVjuuQDvr0SmO4qow4lxyxj1T54+LVcVso3KW2NMbdDtqQK6gD6m Dy8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767289393; x=1767894193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z1KPrbZkeJravhqXr5etlOZIy+Y+YVyp19bUIcMGK94=; b=Tki6Fw6f8zlKu0B1ec7q2VklhL0sU4pNPTZCYQUAz4MH5m0QbJOXLINFS2VKa0GHSO DxfPDDp428AzQcsDa90IQHHtPk5TMOuwZeIbjK+f+G3BrljtmGGoG9TnZOfaXkG4qsh4 /e0WlYvlDUcPyUFP+PpylfNWngOqkmth4nh7S0icKYIFCLek0IriNx8OPk+aTXCMOUEp WM4+4buMFbvYK81W2MmlJo3+C70Z31xeusKv5V1IH0cEj7l7NN3j7qK+mc26QQlxo1yi lrY0L7IorgMBJ4dXWuTLvrnKPstdsavvUniMC7LPo+DuWYlPknm3j1lQyFVQGE5FTT+F Q2AQ== X-Forwarded-Encrypted: i=1; AJvYcCX3d0PpZCOMOfobdosncGjBxJbwWgZ9zdTzaaQBbayyKNWgtAXiEaNmY44YYKOwe4CnhBA=@dpdk.org X-Gm-Message-State: AOJu0Yz2bUQYgd3upP0p+9J+O3YzwdVHGA2Lm/Yp+3bkI/J/o1fv5XN1 7CfXfP8meNtrOiyZsh4CiEDvF4j5qJOjXT6fvp5xTQPEW90oqiYTVby4yK7aG8eRMGdqKiTmzDw kkI5g7ljqk9qmdA7oQ6my61SJsZSPdkU= X-Gm-Gg: AY/fxX70tBygJ4LbCA3AgAtPq7ZvJZafW+JPC0pRCrqA4guQgf5C9HbSLtQcgbbxnnW 6hOTQKnENWIYX1yZUuqyUjHdKeC8sV16mOeOnkGsEipwO3vY5gOantCzV6+bKtyYbPBEN+xDWD/ sNbWD6B2pEev7IhvKvjJjpUZ5KWK1WY2I3FuxWfavQE/TP7wJkjEJQFuOfzHaetvhrRMBWgKy7+ SIHWifAT7qFeUkMWoc5AF+H4m9tlY8DptDD6sV2y9fnQZ2Mlb4SSUD4kLlz5JWgfXBsWbYCb2xp FuskoqS8/enSuWEGkQ+JWaZ1EX+v6A== X-Google-Smtp-Source: AGHT+IGYuXKruBfptWa0V2SEYn5JdDDQt/n9sUBXR1iF29qmyB3cNfV/CMq4MeKREOFTPuwnT3e3iZq1NNeHg8EWY3Q= X-Received: by 2002:a4a:d143:0:b0:659:9a49:8e69 with SMTP id 006d021491bc7-65d0eae197fmr12352027eaf.57.1767289393199; Thu, 01 Jan 2026 09:43:13 -0800 (PST) MIME-Version: 1.0 References: <20251212115238.59710-1-madhukar.mythri@gmail.com> <20251220102503.54d04c5d@phoenix.local> In-Reply-To: From: madhukar mythri Date: Thu, 1 Jan 2026 23:13:02 +0530 X-Gm-Features: AQt7F2r65F68FXN_1WegrDPaVJJqUmYL7RPZMx-zt8Y0slr1pu6TsPi8E6XbK5M Message-ID: Subject: Re: [EXTERNAL] [PATCH] net/netvsc: Fix on race condition of multiple commands To: Long Li Cc: Stephen Hemminger , "dev@dpdk.org" , Madhuker Mythri Content-Type: multipart/alternative; boundary="0000000000007f3ffa06475720a5" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000007f3ffa06475720a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Long Li 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 spinlo= ck > in production use. But I think it=E2=80=99s better to have application re= try on > BUSY (with some delay logic), as the netvsc is designed in this way since > introduced. > > > > Thanks, > > Long > > > > > > > > *From:* madhukar mythri > *Sent:* Saturday, December 20, 2025 9:37 PM > *To:* Stephen Hemminger > *Cc:* Long Li ; dev@dpdk.org; Madhuker Mythri < > madhuker.mythri@oracle.com> > *Subject:* Re: [EXTERNAL] [PATCH] net/netvsc: Fix on race condition of > multiple commands > > > > You don't often get email from madhukar.mythri@gmail.com. Learn why this > is important > > 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 suc= h > 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 , 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, > wrote: > > On Fri, 19 Dec 2025 17:35:33 +0000 > Long Li 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 a= re > 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 chang= e. > > 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. > > --0000000000007f3ffa06475720a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Long,

Yes, got it.
By cach= ing the results of 'hn_rndis_query_hwcaps()' inside PMD will be bet= ter.
Yes, you can submit the patch 'Or' let me know, if y= ou are busy.

Thanks,
Madhukar.

On Thu, Jan 1, 2026 at 4:52=E2=80=AFAM Long Li <longli@microsoft.com> wrote:

Hi Madhukar,

=C2=A0

I suggest caching the result of hn_rndis_query_hwcap= s(), as suggested by Stephen. This can be done inside PMD. Do you want me t= o submit a patch?

=C2=A0

For querying link status, the lock should be impleme= nted inside hn_rndis_exec1(). The drawback is that this function can potent= ially wait for up to 60 seconds on response from host, maybe not suitable f= or spinlock in production use. But I think it=E2=80=99s better to have application retry on BUSY (with some d= elay logic), as the netvsc is designed in this way since introduced.=

=C2=A0

Thanks,

Long

=C2=A0

=C2=A0

=C2=A0

From: madhukar mythri <madhukar.mythri@gmail.com>
Sent: Saturday, December 20, 2025 9:37 PM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Long Li <longli@microsoft.com>; dev@dpdk.org; Madhuker Mythri <madhuker.mythri@oracle.com> Subject: Re: [EXTERNAL] [PATCH] net/netvsc: Fix on race condition of= multiple commands

=C2=A0

You don't often get email from madhukar.mythri@gmail.com. Learn why this is important

Hi Li and Stephen,

=C2=A0

We have a common DPDK application for all the PMD= 9;s, in which we are seeing issue for this Netvsc PMD only.

I mean, for KVM hypervisor with Intel or Mellanox NI= Cs we did not see such sync issues. Also, with failsafe PMD on hyper-v did = not seen such sync issues.

=C2=A0

So, i thought this would be better to fix at PMD lev= el using spinlock.

=C2=A0

For Link-status get with multiple threads we can go = with retry mechanism.

=C2=A0

However, w.r.t all other PMD's this device info = get and Link-status get has issues in multi threaded application.=

=C2=A0

Regards,

Madhuker.

=C2=A0

On Fri, 19 Dec 2025 17:35:33 +0000
Long Li <longl= i@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.=C2=A0
>
> Hi Madhuker,
>
> I'm not sure if we should use a lock in the driver for this. It= 9;s not clear in DPDK documents but in general the calls to query device st= atus are not thread safe.
>
> Is it possible that the application uses a lock to sync calling to thi= s?
>

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.

--0000000000007f3ffa06475720a5--