From: Min Tang <tommytang@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] net/netvsc: subchannel configuration failed due to unexpected NVS response
Date: Mon, 2 Mar 2020 10:40:17 -0500 [thread overview]
Message-ID: <CAEHUbGTvpxrsvAr3BK8qp8AbdBAY5svPzZnzBd5pAmvMSJq7yw@mail.gmail.com> (raw)
In-Reply-To: <20200301095402.6d570e83@hermes.lan>
Hi Stephen:
If there is no intention to process the response message of NVS_TYPE_RNDIS,
would it be better to not set the flags to VMBUS_CHANPKT_FLAG_RC so that it
won't receive any response message?
Best Regards,
Min Tang
On Sun, Mar 1, 2020 at 12:54 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> On Thu, 27 Feb 2020 11:16:01 -0500
> Min Tang <tommytang@gmail.com> wrote:
>
> > Hi Stephen:
> >
> > I saw the following error messages when using DPDK 18.11.2 in Azure:
> >
> > hn_nvs_execute(): unexpected NVS resp 0x6b, expect 0x85
> > hn_dev_configure(): subchannel configuration failed
> >
> > It was not easy to reproduce it and it only occurred with multiple queues
> > enabled. In hn_nvs_execute it expects the response to match the request.
> In
> > the failed case, it was expecting NVS_TYPE_SUBCH_REQ (133 or 0x85) but
> > got NVS_TYPE_RNDIS(107 or 0x6b). Obviously somewhere the NVS_TYPE_RNDIS
> > message had been sent before the NVS_TYPE_SUBCH_REQ message was sent. I
> > looked at the code and found that the NVS_TYPE_RNDIS message needs
> > completion response but it does not receive the response message
> anywhere.
> > The fix would be receiving and discarding the wrong response message(s).
> >
> > I put the following patches and it has fixed the problem.
> >
> > --- a/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:08:29.755530969 -0500
> > +++ b/drivers/net/netvsc/hn_nvs.c 2020-02-27 11:07:21.567371798 -0500
> > @@ -92,7 +92,7 @@
> > if (hdr->type != type) {
> > PMD_DRV_LOG(ERR, "unexpected NVS resp %#x, expect %#x",
> > hdr->type, type);
> > - goto retry;
> > + return -EINVAL;
> > }
> >
> > if (len < resplen) {
>
>
> The situation is that NVS_TYPE_RNDIS is a receive packet that is
> arriving while subchannel is being setup. For first channel this
> doesn't happen because control operations at that level happen
> before packets arrive.
>
> Needs some more research before coming up with a good fix.
> Either the processing of responses in nvs_execute needs to use
> the same receive processing function as normal data. Which
> means adding logic to wait for condition; or the incoming
> packets there could be dropped; or the device needs to be
> stopped before configuring sub channels.
>
> Dropping is probably the easiest to implement.
>
>
>
next prev parent reply other threads:[~2020-03-02 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 16:16 Min Tang
2020-02-27 17:47 ` Stephen Hemminger
2020-02-27 18:24 ` Min Tang
2020-03-01 17:54 ` Stephen Hemminger
2020-03-02 15:40 ` Min Tang [this message]
2020-03-02 16:07 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEHUbGTvpxrsvAr3BK8qp8AbdBAY5svPzZnzBd5pAmvMSJq7yw@mail.gmail.com \
--to=tommytang@gmail.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).