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 BE1F2A0569; Mon, 2 Mar 2020 17:07:26 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ED2DB1BFF0; Mon, 2 Mar 2020 17:07:25 +0100 (CET) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by dpdk.org (Postfix) with ESMTP id 0A7581BFEF for ; Mon, 2 Mar 2020 17:07:24 +0100 (CET) Received: by mail-pj1-f41.google.com with SMTP id o2so5462pjp.2 for ; Mon, 02 Mar 2020 08:07:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TlKpAxnik4c2M8jsfDTseXHKblKAqjbuRP62EnqQCC8=; b=bj0LYbL2wVxBz0k832IVuSuw6Z7/54NezqhS+CdnvUcyjFS1u6Tx6gxwsAnLcHG4j7 771WGOl0kpWNMsV1swcnOkgfqjc1WvxK7ZFEWhEz4pUYIAxahxEZwuR6W0LiV0euxIlc RRJQ1r6lKZkC9kiGVH731NxvTW6m6y2ObOIHL2W3SpHefnvtgGhmTAxkKvnFoTJsDPcm 2CDK0j/nWdf5+S/3cxczjskndD+Wqhzes6sDcOYzvIHMAqIKHNoypNhzCFe/44hBF0gR b3PZwIHNIm/CLGm5kMTj1p4XCM/TES4qOM6LOBX5mAK8F4StwJIWJCYX+S/X5a7rc/HA wmLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TlKpAxnik4c2M8jsfDTseXHKblKAqjbuRP62EnqQCC8=; b=Jt0rVyTlC3+8YfsIV/QavarX+stv+DW8Cd4ptQ2aqi7TQm2YIHNtQ/6Zf+Hc4xqFvG zDsalZ3C8Dl+uA/sj1y9eXF3EvriNhWPwEX+aAUMBFA5vh+nvaZb0gcj4CEKpFzhr4c+ bPhB+vZUQMWQHZFtpGzyUiJBBZU0o9P+YjKtOdss4wXB5uDqEKHjB3J3g5cDycqy4aCE mIz68tuSZXYIjcrLK2V9D/badW24UbwCHneQ4lgc98/lcGn4Mpzchi/IlGKvTnSI8nIv JPjCCO0wPhttiCtBtAFPKe+AJztXpVis1DqrBb1GUsV++gwpkxtR8e47wbbTE5e2P7IK Kvqg== X-Gm-Message-State: APjAAAVlrTY47J6367xSCjT+D13PGWLX/jMqsNKoM0fYd9tdueWik+BZ el5n6rwuGfqg8xe/+oy/ogS+lw== X-Google-Smtp-Source: APXvYqxxEYEcwd+PD3HlH5YYXNQhX93Tsam1pGjTvEzP6s8T8x3iPZWftskidupAtLbv8ciHtbluVA== X-Received: by 2002:a17:902:9a84:: with SMTP id w4mr18580776plp.21.1583165243770; Mon, 02 Mar 2020 08:07:23 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id k5sm72645pju.29.2020.03.02.08.07.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2020 08:07:23 -0800 (PST) Date: Mon, 2 Mar 2020 08:07:15 -0800 From: Stephen Hemminger To: Min Tang Cc: dev@dpdk.org Message-ID: <20200302080715.4d9abf4c@hermes.lan> In-Reply-To: References: <20200301095402.6d570e83@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" On Mon, 2 Mar 2020 10:40:17 -0500 Min Tang wrote: > 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. > > > > > > The way transmit works is that NVS_TYPE_RNDIS is sent and the response indicates a transmit completed.