From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752052AbbIQTxc (ORCPT ); Thu, 17 Sep 2015 15:53:32 -0400 Received: from mail-bn1bn0109.outbound.protection.outlook.com ([157.56.110.109]:38989 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751395AbbIQTxa convert rfc822-to-8bit (ORCPT ); Thu, 17 Sep 2015 15:53:30 -0400 From: KY Srinivasan To: David Miller CC: "David.Laight@ACULAB.COM" , "alexander.duyck@gmail.com" , Haiyang Zhang , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "jasowang@redhat.com" Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V Thread-Topic: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V Thread-Index: AQHQ8Jdrp1Mkwb76akCmi3unx8nMnp4/UsgAgAAEhICAABfyIIAAP8MAgAAEDQCAALQjAIAAY6KwgABH8QCAAALoEA== Date: Thu, 17 Sep 2015 19:52:01 +0000 Message-ID: References: <063D6719AE5E284EB5DD2968C1650D6D1CB989E9@AcuExch.aculab.com> <20150917.115218.655587837796826886.davem@davemloft.net> In-Reply-To: <20150917.115218.655587837796826886.davem@davemloft.net> 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:8c01:121d:61be:33da:497f:2c22] x-microsoft-exchange-diagnostics: 1;BY2PR0301MB0775;5:slPw8ZQ0UwqDFerwlv0N3LonpbAzOXJ/kIkXCEdSyWbWON5/JyHWkYSUd2OJMYmHGEhA1S0jYCLU2y4Y9FZoGkXv7WkCFfJA/m1G6gRhU2a3TVRq8LJfWnQfIjx+0JGDGAvm1JWQ3le1ZkDMJUnNfg==;24:MYBYGeyEc478mRRUEpD/8HLxFgmvo8148PN3mCTKGgTts/Oe9qVivHHvGZFkyNo0z26XCCV4yuVEyuBhZ7L/SdgkTBNhBI1Ca/zR9C5/How=;20:H9hx4ZzKbkqM1tC1gMWTjkg89UBLcOTxu7Ofjw59SaftEnKHwH2YhhCLamoU+4XDBG6/xcbb9C+aUKNqN9Cjaw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0775; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401001)(520078)(520075)(8121501046)(5005006)(3002001);SRVR:BY2PR0301MB0775;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0775; x-forefront-prvs: 07025866F6 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(6009001)(377454003)(189002)(199003)(13464003)(10400500002)(5005710100001)(10290500002)(8990500004)(105586002)(106356001)(106116001)(19580395003)(19580405001)(99286002)(189998001)(110136002)(74316001)(5001960100002)(5001860100001)(5003600100002)(5002640100001)(101416001)(54356999)(76176999)(50986999)(33656002)(10090500001)(87936001)(86362001)(2950100001)(11100500001)(2900100001)(86612001)(46102003)(62966003)(77156002)(122556002)(40100003)(93886004)(92566002)(68736005)(102836002)(77096005)(64706001)(97736004)(5001830100001)(76576001)(5004730100002)(5007970100001)(4001540100001)(81156007)(3826002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR0301MB0775;H:BY2PR0301MB1654.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2015 19:52:02.0161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0775 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: David Miller [mailto:davem@davemloft.net] > Sent: Thursday, September 17, 2015 11:52 AM > To: KY Srinivasan > Cc: David.Laight@ACULAB.COM; alexander.duyck@gmail.com; Haiyang Zhang > ; vkuznets@redhat.com; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org; jasowang@redhat.com > Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V > > From: KY Srinivasan > Date: Thu, 17 Sep 2015 15:14:05 +0000 > > > I think I can achieve my original goal of not having any allocation > > in the send path by carefully using the memory available in the skb: > > Please stop flat-out ignoring David L.'s suggestion. I am sorry; I did not mean to convey that impression. > > Have a pre-cooked ring of buffers for these descriptors that you can > point the chip at. No per-packet allocation is necessary at all. Even if I had a ring of buffers, I would still need to manage the life cycle of these buffers - selecting an unused one on the transmit path and marking it used (atomically). Once the transmit completes (as indicated by the transmit complete callback) this buffer needs to be marked free. I can certainly make these operations efficient and lock-free, but they are still at some level an allocation/free operation albeit potentially more efficient than having the kernel allocate the memory. > > If you play games with SKBs you will get burned. I will implement Dave L's suggestion. However, I am curious as to why you would consider my proposed usage of the skb headroom and the control buffer area in skb as non-standard usage. Regards, K. Y