From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F1011A0569; Mon, 2 Mar 2020 16:40:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 449A41BFF0; Mon, 2 Mar 2020 16:40:37 +0100 (CET) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by dpdk.org (Postfix) with ESMTP id DA7E73B5 for ; Mon, 2 Mar 2020 16:40:35 +0100 (CET) Received: by mail-il1-f173.google.com with SMTP id x2so9670186ila.9 for ; Mon, 02 Mar 2020 07:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8T8nrJHiM11V6sHD5pWJz4QC8XrM2GMmdkssUhjChCo=; b=Tl3JkB9puKy2unBELVObSmelbkXIyvZS2x9O5N6DRVEhWoj16j6aWyTTXhhQvl2iIs kOCdmhMdTZD2gxLOyWhCdkfJ56KAAKha/OLYzqxlU5KfqPHhM3nOW7dTSKHTsJKM4vh+ FhDZYm//OeZabLiToFJs7CYeoDf3xqjS5dxbwOXsMRAQMY/fAWf/RLxJE9M3a8qUgI8V MUHdEVkc2O2F8BEn3ZSSGLWqb9OPPQ2+AIBJkohJplDHGXxSPLNAtdy4avmXKRWj/722 HMzUaUAaegDlx0o4Ec9YLOrX0ic5x36xJ/3pRpr8CTzFfsjVE2O8PDM5/wwwZvTvzIMv PrAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8T8nrJHiM11V6sHD5pWJz4QC8XrM2GMmdkssUhjChCo=; b=cnO/84L2f5vJm12XbVtFCAK+wDpnjF2tEewpLg+gzILuHu+xDaST6DUOAJmx/7NN63 12agP2rqT8l9KG0BTZlJs1AHKrWlVEoeRmqoI6j7h6iVzxpYjHRXm4tRczVLGmIgmJEw ilrir/iNjXPhOtsL/oLJJSajFiPmSOVF8EMz0WcylT8OGwjY/QGX15hUZPYlfc4vvb9o xSAN2UigwmXTSqYkODbzy35WC1hL6qqQzez6vDnBXZnMKv1iVgcipwcnc8k1CSNN1pig xDdqi8F8KLyYU+De1GHS0ft5k6TQ4bL8+Hi7g9AFZjwvhAud0/pUzltZ1bSpluNDP1Vn /wxA== X-Gm-Message-State: ANhLgQ2igIDGH5gej4CJoGTEuYtu2Q0+JMZG4EVqJIACfscTnna3Zv8u PGPTL3OAgQqu62HQmwXxPL27VbloHub44bQJTG60Hg78 X-Google-Smtp-Source: ADFU+vvIIaCdIyJplU+jPoAxaWuALonLn0LkLVFE2IcN3T8lHfxnMy43b6Br4VEsfvXHSuFAytba16SLVnpacx7C77g= X-Received: by 2002:a92:ce92:: with SMTP id r18mr194980ilo.135.1583163635055; Mon, 02 Mar 2020 07:40:35 -0800 (PST) MIME-Version: 1.0 References: <20200301095402.6d570e83@hermes.lan> In-Reply-To: <20200301095402.6d570e83@hermes.lan> From: Min Tang Date: Mon, 2 Mar 2020 10:40:17 -0500 Message-ID: To: Stephen Hemminger Cc: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] net/netvsc: subchannel configuration failed due to unexpected NVS response X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 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. > > >