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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 90E93C2D0E4 for ; Tue, 24 Nov 2020 19:02:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36197206E5 for ; Tue, 24 Nov 2020 19:02:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="sN5ZukW2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404125AbgKXTCG (ORCPT ); Tue, 24 Nov 2020 14:02:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:42782 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390881AbgKXTCF (ORCPT ); Tue, 24 Nov 2020 14:02:05 -0500 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 35C00204FD; Tue, 24 Nov 2020 19:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606244525; bh=PW4WMI4gJ6Ccl9hIj/7wrZ3x0ZDqbNJOOj0gKSntkbc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sN5ZukW2s3wpA8/aMX1/mW0W5ROOvDFe7mOIUTu3xUvhDw/tsBBp6s4lpPgfBBjko wrpcUsvv8QbDp0YR+Q6nRCV4RBgAT5Z6MhSYWqWvtd1UqssF0eVGeL5IyvE6dkNkFQ zbqmuYjzMJqWYQm21z1Zqo/ZLA2N4rMHd6i1jGSs= Date: Tue, 24 Nov 2020 11:02:02 -0800 From: Jakub Kicinski To: "Ramsay, Lincoln" Cc: Florian Westphal , Igor Russkikh , "David S. Miller" , "netdev@vger.kernel.org" , Dmitry Bogdanov Subject: Re: [PATCH net v5] aquantia: Remove the build_skb path Message-ID: <20201124110202.38dc6d5b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20201119221510.GI15137@breakpoint.cc> <20201119222800.GJ15137@breakpoint.cc> <20201119225842.GK15137@breakpoint.cc> <20201121132204.43f9c4fb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20201121132324.72d79e94@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20201123084243.423b23a4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, 23 Nov 2020 21:40:43 +0000 Ramsay, Lincoln wrote: > From: Lincoln Ramsay > > When performing IPv6 forwarding, there is an expectation that SKBs > will have some headroom. When forwarding a packet from the aquantia > driver, this does not always happen, triggering a kernel warning. > > aq_ring.c has this code (edited slightly for brevity): > > if (buff->is_eop && buff->len <= AQ_CFG_RX_FRAME_MAX - AQ_SKB_ALIGN) { > skb = build_skb(aq_buf_vaddr(&buff->rxdata), AQ_CFG_RX_FRAME_MAX); > } else { > skb = napi_alloc_skb(napi, AQ_CFG_RX_HDR_SIZE); > > There is a significant difference between the SKB produced by these > 2 code paths. When napi_alloc_skb creates an SKB, there is a certain > amount of headroom reserved. However, this is not done in the > build_skb codepath. > > As the hardware buffer that build_skb is built around does not > handle the presence of the SKB header, this code path is being > removed and the napi_alloc_skb path will always be used. This code > path does have to copy the packet header into the SKB, but it adds > the packet data as a frag. > > Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code") > Signed-off-by: Lincoln Ramsay Applied, queued of stable. Thanks!