From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EBB5C388F9 for ; Fri, 20 Nov 2020 00:17:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3504222244 for ; Fri, 20 Nov 2020 00:17:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726806AbgKTARU (ORCPT ); Thu, 19 Nov 2020 19:17:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726398AbgKTARU (ORCPT ); Thu, 19 Nov 2020 19:17:20 -0500 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7B07C0613CF for ; Thu, 19 Nov 2020 16:17:19 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1kfu6r-0005h0-6z; Fri, 20 Nov 2020 01:17:07 +0100 Date: Fri, 20 Nov 2020 01:17:05 +0100 From: Florian Westphal To: "Ramsay, Lincoln" Cc: Florian Westphal , Igor Russkikh , "David S. Miller" , Jakub Kicinski , "netdev@vger.kernel.org" , Dmitry Bogdanov Subject: Re: [PATCH v4] aquantia: Remove the build_skb path Message-ID: <20201120001705.GL15137@breakpoint.cc> References: <20201119221510.GI15137@breakpoint.cc> <20201119222800.GJ15137@breakpoint.cc> <20201119225842.GK15137@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Ramsay, Lincoln wrote: [ patch looks good to me, I have no further comments ] > > For build_skb path to work the buffer scheme would need to be changed > > to reserve headroom, so yes, I think that the proposed patch is the > > most convenient solution. > > I don't know about benefits/feasibility, but I did wonder if (in the event that the "fast path" is possible), the dma_mapping could use an offset? The page would include the skb header but the dma mapping would not. If that was done though, only 1 RX frame would fit into the page (at least on my system, where the RX frame seems to be 2k and the page is 4k). Also, there's a possibility to set the "order" variable, so that multiple pages are created at once and I'm not sure if this would work in that case. Yes, this is what some drivers do, they allocate a page, pass pageaddr + headroom_offset everywhere, except build_skb() which gets the pageaddr followed by skb_reserve(skb, headroom_offset). > > This only copies the initial part and then the rest is added as a frag. > > Oh yeah. That's not as bad as I had thought then :) > > I wonder though... if the "fast path" is possible, could the whole packet (including header) be added as a frag, avoiding the header copy? Or is that not how SKBs work? No, you can either have skb->head point to the page (build_skb), or skb->head needs to be kmalloc'd (napi_alloc_skb for example). Both can have page frags. In the second case, at least L2 header needs to be in skb->head (and ip stack would pull in L3 header as well later on anyway).