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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57810EB64D7 for ; Fri, 16 Jun 2023 18:47:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344676AbjFPSrT (ORCPT ); Fri, 16 Jun 2023 14:47:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232347AbjFPSrO (ORCPT ); Fri, 16 Jun 2023 14:47:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A35183A9D for ; Fri, 16 Jun 2023 11:47:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3C07F61375 for ; Fri, 16 Jun 2023 18:47:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1909BC433C8; Fri, 16 Jun 2023 18:47:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686941231; bh=/Qr0GLXmqNAy+vLSOaufC5FpI6BR6vkDi5r1CSKe30A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S7ri9AujBQSOsuj+NUkAT5AcrRqR1wK5bAffw7fsPR4vCkL4onocjtO3Q7Gqj/LNK zljqj3vhsUYnKPxNwuTQi61MpVm7sdkuRX5D93OCohEh9L/DEvXtuKz7ebBzc2MOIx NEWszrXK1bjESq/wrW4Q8NHZyVNQ4IUST1WWzmfpKJefEos3L+VrUQ9zd+QsDYGDR5 xBvUKerZwywBlzfnQZn4Q//vUR50Gz1gTnfgkvCR081InJ235lMWdhvf6ppJqJN3N+ zoALPRN/w+gQnYXb4r9x7PfUoAy9cvRkU0hxav1/ch8Oua4l1W2Zk29XFOwoViSCNZ 4JSAVNkY9Kztg== Date: Fri, 16 Jun 2023 11:47:10 -0700 From: Jakub Kicinski To: Jesper Dangaard Brouer Cc: Alexander Duyck , brouer@redhat.com, Yunsheng Lin , davem@davemloft.net, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Jesper Dangaard Brouer , Ilias Apalodimas , Eric Dumazet , Maryam Tahhan , bpf Subject: Re: [PATCH net-next v3 3/4] page_pool: introduce page_pool_alloc() API Message-ID: <20230616114710.7e746dea@kernel.org> In-Reply-To: <699563f5-c4fa-0246-5e79-61a29e1a8db3@redhat.com> References: <20230609131740.7496-1-linyunsheng@huawei.com> <20230609131740.7496-4-linyunsheng@huawei.com> <36366741-8df2-1137-0dd9-d498d0f770e4@huawei.com> <0ba1bf9c-2e45-cd44-60d3-66feeb3268f3@redhat.com> <699563f5-c4fa-0246-5e79-61a29e1a8db3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Jun 2023 20:41:45 +0200 Jesper Dangaard Brouer wrote: > > This is a sort-of. One thing that has come up as of late is that all > > this stuff is being moved over to folios anyway and getting away from > > pages. In addition I am not sure how often we are having to take this > > path as I am not sure how many non-Tx frames end up having to have > > fragments added to them. For something like veth it might be more > > common though since Tx becomes Rx in this case. > > I'm thinking, that is it very unlikely that XDP have modified the > fragments. So, why are we allocating and copying the fragments? > Wouldn't it be possible for this veth code to bump the refcnt on these > fragments? (maybe I missed some detail). They may be page cache pages, AFAIU.