From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965991AbbBCPqg (ORCPT ); Tue, 3 Feb 2015 10:46:36 -0500 Received: from mail-bl2on0125.outbound.protection.outlook.com ([65.55.169.125]:21280 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965742AbbBCPqf (ORCPT ); Tue, 3 Feb 2015 10:46:35 -0500 From: Haiyang Zhang To: Jason Wang CC: "davem@davemloft.net" , "netdev@vger.kernel.org" , KY Srinivasan , "olaf@aepfle.de" , "linux-kernel@vger.kernel.org" , "driverdev-devel@linuxdriverproject.org" Subject: RE: [PATCH net] hyperv: Fix the error processing in netvsc_send() Thread-Topic: [PATCH net] hyperv: Fix the error processing in netvsc_send() Thread-Index: AQHQPrRgPyD0DaGOdEuEBUqp+E+oB5zfEIfA Date: Tue, 3 Feb 2015 15:46:31 +0000 Message-ID: References: <1422563689-31036-1-git-send-email-haiyangz@microsoft.com> <1422613519.8840.0@smtp.corp.redhat.com> <1422859762.7028.2@smtp.corp.redhat.com> In-Reply-To: <1422859762.7028.2@smtp.corp.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.237.174.38] authentication-results: redhat.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0706; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0706; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(6009001)(13464003)(164054003)(51704005)(377454003)(54356999)(62966003)(77156002)(54606007)(76176999)(66066001)(50986999)(86612001)(86362001)(33656002)(54206007)(74316001)(110136001)(92566002)(19580395003)(76576001)(19580405001)(46102003)(2656002)(87936001)(2950100001)(2900100001)(93886004)(106356001)(122556002)(106116001)(40100003)(99286002)(102836002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR0301MB0706;H:BN1PR0301MB0770.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2015 15:46:31.4144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0706 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t13Fkhl3011093 > -----Original Message----- > From: Jason Wang [mailto:jasowang@redhat.com] > Sent: Monday, February 2, 2015 1:49 AM > >> btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC > >> when > >> queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact? > > > > In this case, we don't request re-send, so set ret to a value other > > than > > -EAGAIN. > > Why not? We have available slots for it to be sent now. Dropping the > packet in this case may cause out of order sending. The EAGAIN error doesn't normally happen, because we set the hi water mark to stop send queue. If in really rare case, the ring buffer is full and there is no outstanding sends, we can't stop queue here because there will be no send-completion msg to wake it up. And, the ring buffer is likely to be occupied by other special msg, e.g. receive-completion msg (not a normal case), so we can't assume there are available slots. We don't request retry from the upper layer in this case to avoid possible busy retry. Thanks, - Haiyang {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I