Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Haiyang Zhang <haiyangz@microsoft.com>
To:     "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>
CC:     KY Srinivasan <kys@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "olaf@aepfle.de" <olaf@aepfle.de>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path
Thread-Topic: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path
Thread-Index: AQHTwhBZzy0DeWsSN022dpFRpCYf5KPfm6SAgACCAMA=
Date:   Sun, 25 Mar 2018 00:41:37 +0000
Message-ID: <BL0PR2101MB110877CEB926DEB399ABA564CAAE0@BL0PR2101MB1108.namprd21.prod.outlook.com>
References: <20180322190114.25596-1-haiyangz@linuxonhyperv.com>
 <20180322190114.25596-2-haiyangz@linuxonhyperv.com>
 <DM5PR2101MB103003AA72955A6C6AD44D0CDCAF0@DM5PR2101MB1030.namprd21.prod.outlook.com>
In-Reply-To: <DM5PR2101MB103003AA72955A6C6AD44D0CDCAF0@DM5PR2101MB1030.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mikelley@ntdev.microsoft.com;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-24T16:48:04.3236663Z;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure
 Information Protection;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic;
 Sensitivity=General
x-originating-ip: [69.130.166.81]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BL0PR2101MB0977;7:KyKSBKOYQRUF7S2dBeIv6qLtz8jMDdRA9s6BF/gPCIbOr3/OA0X5atbdTMSfgLb2UEQd+3MKLTRGVl0M8zYyF6fY4zkXl8Yzth3pyYIyD+uOqEr1gdWk6cT6wgeVeBV0IpWj6pzcVHJ9IcA1BN5FLFXcEr3LYyMDSmsMlAK1IZM9II5PtOM7A7brYpu5ap0omRwN0dc+l7lSV6cSf670ly2HFQALtvX59I3EhHOpmnFun40cIWDG35QxiCWIEUfJ;20:WGKDRGSBXjaiBWf23zWrky4IWJP3D2cPttfO98QR1HaTBui6up69hhzCdizsXTisD+ZnuDKkyod+JaxyMzJlyUWXuCiTnoKm29RmPiKEp7FTeYHSkxLvColS+n7XiPoh9FzPqUXJdOaw/R40idctt2FU/8Qv/V8kb24ifCdRj2Q=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: dc97eaae-af28-438f-8205-08d591e92ad5
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(2017052603328)(7193020);SRVR:BL0PR2101MB0977;
x-ms-traffictypediagnostic: BL0PR2101MB0977:
x-microsoft-antispam-prvs: <BL0PR2101MB097744A9E925CEB1E49CE8DCCAAE0@BL0PR2101MB0977.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(20558992708506)(89211679590171)(9452136761055);
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011);SRVR:BL0PR2101MB0977;BCL:0;PCL:0;RULEID:;SRVR:BL0PR2101MB0977;
x-forefront-prvs: 0622A98CD5
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(346002)(376002)(396003)(366004)(39860400002)(39380400002)(189003)(199004)(13464003)(229853002)(8676002)(66066001)(76176011)(4326008)(74316002)(86362001)(14454004)(53936002)(54906003)(102836004)(26005)(8936002)(6116002)(6246003)(81166006)(6506007)(81156014)(110136005)(8990500004)(53546011)(2900100001)(99286004)(3846002)(86612001)(6346003)(9686003)(55016002)(10090500001)(316002)(106356001)(5250100002)(6436002)(2501003)(478600001)(22452003)(10290500003)(7696005)(446003)(5660300001)(7736002)(97736004)(1511001)(25786009)(68736007)(3280700002)(105586002)(33656002)(2906002)(305945005)(3660700001)(11346002)(2201001);DIR:OUT;SFP:1102;SCL:1;SRVR:BL0PR2101MB0977;H:BL0PR2101MB1108.namprd21.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=haiyangz@microsoft.com; 
x-microsoft-antispam-message-info: ZDHp8cyavxvcD5r/78rjb1ggbL8pIyNeBG8pQ2fiG3VIR96E+M3MDQaqQTyZWovWSBkGsN4/2BjczOgGSvsdEuUZCpR8TRqL3zl03ACVAgVuyfWUlSZBBxhNJo3VTYi0STmq0+CQzW91AgmImoWPaiQPvWOZ11f+gu3usXdYxszey7JmZMmG3hM+c3cSJA5ub+miO7cbfILVofXyHVIH15bQ2ntg2PWFi5rA2iMkbdGkUkT+YjCD4ySv4mGhCrskiXA7oZyxRxUzQycG25FHxTrtVqUBIJuL3m0sBLMKOerPXXRT24kvtlSC7znFdCxx3A+RlKPFmrtPGymWvuja6g==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc97eaae-af28-438f-8205-08d591e92ad5
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 00:41:37.2994
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0977
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Michael Kelley (EOSG)
> Sent: Saturday, March 24, 2018 12:48 PM
> To: Haiyang Zhang <haiyangz@microsoft.com>; davem@davemloft.net;
> netdev@vger.kernel.org
> Cc: KY Srinivasan <kys@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; olaf@aepfle.de; vkuznets@redhat.com;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX =
path
>=20
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > <linux-kernel-owner@vger.kernel.org> On Behalf Of Haiyang Zhang
> > Sent: Thursday, March 22, 2018 12:01 PM
> > To: davem@davemloft.net; netdev@vger.kernel.org
> > Cc: Haiyang Zhang <haiyangz@microsoft.com>; KY Srinivasan
> > <kys@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
> > olaf@aepfle.de; vkuznets@redhat.com; devel@linuxdriverproject.org;
> > linux-kernel@vger.kernel.org
> > Subject: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX
> > path
> >
> > From: Haiyang Zhang <haiyangz@microsoft.com>
> >
> > As defined in hyperv_net.h, the NVSP_STAT_SUCCESS is one not zero.
> > Some functions returns 0 when it actually means NVSP_STAT_SUCCESS.
> > This patch fixes them.
> >
> > In netvsc_receive(), it puts the last RNDIS packet's receive status
> > for all packets in a vmxferpage which may contain multiple RNDIS
> > packets.
> > This patch puts NVSP_STAT_FAIL in the receive completion if one of the
> > packets in a vmxferpage fails.
>=20
> This patch changes the status field that is being reported back to the Hy=
per-V
> host in the receive completion message in
> enq_receive_complete().   The current code reports 0 on success,
> and with the patch, it will report 1 on success.  So does this change aff=
ect
> anything on the Hyper-V side?  Or is Hyper-V just ignoring
> the value?   If this change doesn't have any impact on the
> interactions with Hyper-V, perhaps it would be good to explain why in the
> commit message.

Here is the definition of each status code for NetVSP.=20
enum {
        NVSP_STAT_NONE =3D 0,
        NVSP_STAT_SUCCESS,
        NVSP_STAT_FAIL,
        NVSP_STAT_PROTOCOL_TOO_NEW,
        NVSP_STAT_PROTOCOL_TOO_OLD,
        NVSP_STAT_INVALID_RNDIS_PKT,
        NVSP_STAT_BUSY,
        NVSP_STAT_PROTOCOL_UNSUPPORTED,
        NVSP_STAT_MAX,
};

Existing code returns NVSP_STAT_NONE =3D 0, and with this patch
we return NVSP_STAT_SUCCESS =3D 1.=20
Based on testing, either way works for now. But for correctness
and future stability (e.g. host side becomes more stringent), we
should follow the protocol.

Thanks,
- Haiyang