From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754253AbbIQIix (ORCPT ); Thu, 17 Sep 2015 04:38:53 -0400 Received: from smtp-out6.electric.net ([192.162.217.187]:56964 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753888AbbIQIiv convert rfc822-to-8bit (ORCPT ); Thu, 17 Sep 2015 04:38:51 -0400 From: David Laight To: "'KY Srinivasan'" , Alexander Duyck , Haiyang Zhang , "Vitaly Kuznetsov" , "netdev@vger.kernel.org" CC: "David S. Miller" , "linux-kernel@vger.kernel.org" , Jason Wang 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: AQHQ8JdrrdH0UFPg40aOMmCTh0J6r54/UOPwgAAFILCAAAnOgIAAPmwAgAAV94CAALH0MA== Date: Thu, 17 Sep 2015 08:38:12 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB989E9@AcuExch.aculab.com> References: <1442418625-11805-1-git-send-email-vkuznets@redhat.com> <063D6719AE5E284EB5DD2968C1650D6D1CB9800B@AcuExch.aculab.com> <55F9E172.2040008@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: KY Srinivasan > Sent: 16 September 2015 23:58 ... > > I think we get that. The question is does the Remote NDIS header and > > packet info actually need to be a part of the header data? I would > > argue that it probably doesn't. > > > > So for example in netvsc_start_xmit it looks like you are calling > > init_page_array in order to populate a set of page buffers, but the > > first buffer for the Remote NDIS protocol is populated as a separate > > page and offset. As such it doesn't seem like it necessarily needs to > > be a part of the header data but could be maintained perhaps in a > > separate ring buffer, or perhaps just be a separate page that you break > > up to use for each header. > > You are right; the rndis header can be built as a separate fragment and sent. > Indeed this is what we were doing earlier - on the outgoing path we would allocate > memory for the rndis header. My goal was to avoid this allocation on every packet being > sent and I decided to use the headroom instead. If we can completely avoid all memory > allocation for rndis header, it makes a significant perf difference: ... So just preallocate the header space as a fixed buffer for each ring entry (or tx frame). If you allocate a fixed buffer for each ring entry you may find there are performance gains from copying small fragments into the buffer instead of doing whatever mapping operations are required. David