From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943985AbcJaPOJ (ORCPT ); Mon, 31 Oct 2016 11:14:09 -0400 Received: from mail-sn1nam01on0110.outbound.protection.outlook.com ([104.47.32.110]:40485 "EHLO NAM01-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S943942AbcJaPOH (ORCPT ); Mon, 31 Oct 2016 11:14:07 -0400 From: KY Srinivasan To: Vitaly Kuznetsov CC: "devel@linuxdriverproject.org" , "Van De Ven, Arjan" , "linux-kernel@vger.kernel.org" , Haiyang Zhang Subject: RE: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() Thread-Topic: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() Thread-Index: AQHSL3nDxc200yCc1Eix3byLo2G42qC7IolQgAc6/lOAAFZTcA== Date: Mon, 31 Oct 2016 15:14:02 +0000 Message-ID: References: <1477480307-5546-1-git-send-email-vkuznets@redhat.com> <87shrcbzqz.fsf@vitty.brq.redhat.com> In-Reply-To: <87shrcbzqz.fsf@vitty.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kys@microsoft.com; x-originating-ip: [2601:600:8c00:1040:b076:3b2a:409c:285e] x-ms-office365-filtering-correlation-id: dbba09b9-bcbf-4e42-04ed-08d401a08c52 x-microsoft-exchange-diagnostics: 1;BY1PR03MB1417;7:of/cL2BuwFxAfUWQWv9FOWbX1522TZgZUmjS1Wq9eEtm04iCXZTYGsR/SfKIfXgMhKYwYc3YqLtQwgzoz9PVDgvs7S5Ha2iiWeDRDe8WHxyxh1CrkqVWsMkve8LzCJ+sj28lOvVKlN1rKBOLthNXdg1I2GGQ1GNzSHSRXoN9t/rCZ2jf+lz5D0UUZ6oVoQ+JSbW6cOf3SSxzdcICRfotqQ7dVQ4Od/g1SbTq5NGD28ZBbmcP6eFqFQ/b+mXifr6N9sYRu20IeIqJkhW5VUX3dsVQvVH34V1HR4utpdZqd7NZUZMDe/ikPf2VhwdLlFyiiWd43nMghJxB9OIGnGYvK2+nlKNM+u+Di1y3daF4tFrIbChckKgFDVfSAST/DhyR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1417; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6045074)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6072074);SRVR:BY1PR03MB1417;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1417; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(199003)(13464003)(377454003)(189002)(7846002)(7736002)(3660700001)(9686002)(92566002)(8676002)(81156014)(11100500001)(81166006)(8936002)(86612001)(76576001)(5002640100001)(101416001)(3280700002)(68736007)(305945005)(33656002)(54356999)(76176999)(122556002)(50986999)(97736004)(99286002)(106356001)(106116001)(74316002)(7696004)(19580395003)(77096005)(105586002)(19580405001)(5660300001)(87936001)(110136003)(5005710100001)(10290500002)(10400500002)(107886002)(586003)(102836003)(6116002)(4326007)(189998001)(2906002)(2900100001)(4001430100002)(6916009)(8990500004)(2950100002)(86362001)(10090500001);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR03MB1417;H:DM5PR03MB2490.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 15:14:02.4471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1417 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 quoted-printable to 8bit by mail.home.local id u9VFEE0L029380 > -----Original Message----- > From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com] > Sent: Monday, October 31, 2016 3:05 AM > To: KY Srinivasan > Cc: devel@linuxdriverproject.org; Van De Ven, Arjan > ; linux-kernel@vger.kernel.org; Haiyang Zhang > > Subject: Re: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in > vmbus_post_msg() > > KY Srinivasan writes: > > >> -----Original Message----- > >> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com] > >> Sent: Wednesday, October 26, 2016 4:12 AM > >> To: devel@linuxdriverproject.org > >> Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; > >> Haiyang Zhang > >> Subject: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in > >> vmbus_post_msg() > >> > >> DoS protection conditions were altered in WS2016 and now it's easy to get > >> -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing > MTU > >> on a > >> netvsc device in a loop). All vmbus_post_msg() callers don't retry the > >> operation and we usually end up with a non-functional device or crash. > >> > >> While host's DoS protection conditions are unknown to me my tests show > >> that > >> it can take up to 46 attempts to send a message after changing udelay() to > >> mdelay() and caping msec at '256', this means we can wait up to 10 > seconds > >> before the message is sent so we need to use msleep() instead. Almost all > >> vmbus_post_msg() callers are ready to sleep but there is one special case: > >> vmbus_initiate_unload() which can be called from interrupt/NMI context > >> and > >> we can't sleep there. I'm also not sure about the lonely > >> vmbus_send_tl_connect_request() which has no in-tree users but its > >> external > >> users are most likely waiting for the host to reply so sleeping there is > >> also appropriate. > > > > Vitaly, > > > > One of the reasons why the delay was in microseconds was to make sure > that the boot time > > was not adversely affected by the delay we had in setting up the channel. > The change to microsecond > > delay and other changes in this code reduced the time it took to initialize > netvsc from > > 200 milliseconds to about 12 milliseconds. This is important for us as we look > at achieving sub-second > > boot times. > > The situation you are trying to address are test cases where you are hitting > the host with > > requests that triggers hosts DOS prevention code. Perhaps we could have a > hybrid approach: we > > retain microsecond wait until we hit a threshold and then we use > millisecond delays. This way, the normal boot > > path is still fast while we can handle some of the other cases where the host > DOS prevention code kicks in. > > > > Ok, > > I actually tested boot time with my patch and didn't see a difference > (so I guess our first attempt to send messages usually succeeds) but if > we're concearned about less-than-a-second boot time we'd rather keep the > microseonds delay for first several attempts. I'll do v2. Thank you. K. Y > > Thanks, > > > -- > Vitaly