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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E65B0EB64D8 for ; Tue, 20 Jun 2023 15:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=luf1JZY83RP9FuPB9pz8mFKRCBoq6fmS1Txa9H8BUys=; b=bs7+D2MezXSpTp gcUUGcLMwPDxQ/7fx6KE/NQPWZ+iueZ+McFnIf4L1oek1sL0TxJAHJ7ugUPOy6Xyx9MMtcoo7ckp9 KprFkQmgp0/p5l+ZoSZp1x91+z2A1VkOKJ7G7xgC1JOsRsxr8QE7NO5zSkPdA5ydjyVppX1t2XfH1 P9EMT47z80ouLEitVg4wcvWFPknH9X9p9yIbmEKhMryJ/4MsUQoaznEbfPzv6oazrgv83KYZXQCD/ s83IRajvzU3ypHnJx9/ssdnM+KK5NpTKLfuk0kDjGO1JJ6OJvzmCRmViCeCFeSHmNYnH3kkqSLJ39 UPUC34Nnem6yb5yYsUQQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qBdS0-00Bh4a-2G; Tue, 20 Jun 2023 15:39:24 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qBdRx-00Bh41-1y; Tue, 20 Jun 2023 15:39:23 +0000 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 EA338612D3; Tue, 20 Jun 2023 15:39:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65912C433C8; Tue, 20 Jun 2023 15:39:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687275560; bh=eh34y9JToGjs/7tQpZPrFocGaATF0555w4p+49MYf6I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BChDFjZiWdpXuqeqasgk2boOiqjtppRkgXuquTvIS7LVqDZY7gCCSAcUsDL7RE6qk dL/oIyufJi7RFC3c58IfogutCWO72JdOcfN9fVjrt3UTLWIqa2pnFgA6FJSphu1ueg z7tSuJhyX8tTDSCa29z9nXZtfBp1REMty8YJjGxpdOxfnC4icpAjyx2hEXIp0mYOnQ ab906KaL1s0MOlgX7shSm1SCOplTvhRtuvwZpTQIoIKUAEshyWBChMc4hXy2YSlq+R M5dhBkPvYZmRffUG3qsa6RT5P2sRHMwfrW5N5bcyC0CFwpau0zNisO0bSKP53O9mvr pjZRXwa2lBxnA== Date: Tue, 20 Jun 2023 08:39:18 -0700 From: Jakub Kicinski To: Jesper Dangaard Brouer Cc: brouer@redhat.com, Alexander Duyck , Yunsheng Lin , davem@davemloft.net, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Yisen Zhuang , Salil Mehta , Eric Dumazet , Sunil Goutham , Geetha sowjanya , Subbaraya Sundeep , hariprasad , Saeed Mahameed , Leon Romanovsky , Felix Fietkau , Ryder Lee , Shayne Chen , Sean Wang , Kalle Valo , Matthias Brugger , AngeloGioacchino Del Regno , Jesper Dangaard Brouer , Ilias Apalodimas , linux-rdma@vger.kernel.org, linux-wireless@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Jonathan Lemon Subject: Re: Memory providers multiplexing (Was: [PATCH net-next v4 4/5] page_pool: remove PP_FLAG_PAGE_FRAG flag) Message-ID: <20230620083918.2e3dbade@kernel.org> In-Reply-To: <6909d28b-0ffc-a02a-235b-7bdce594965d@redhat.com> References: <20230612130256.4572-1-linyunsheng@huawei.com> <20230612130256.4572-5-linyunsheng@huawei.com> <20230614101954.30112d6e@kernel.org> <8c544cd9-00a3-2f17-bd04-13ca99136750@huawei.com> <20230615095100.35c5eb10@kernel.org> <908b8b17-f942-f909-61e6-276df52a5ad5@huawei.com> <72ccf224-7b45-76c5-5ca9-83e25112c9c6@redhat.com> <20230616122140.6e889357@kernel.org> <20230619110705.106ec599@kernel.org> <6909d28b-0ffc-a02a-235b-7bdce594965d@redhat.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230620_083921_744764_3170C132 X-CRM114-Status: GOOD ( 17.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 20 Jun 2023 17:12:41 +0200 Jesper Dangaard Brouer wrote: > > The workaround solution I had in mind would be to create a narrower API > > for just data pages. Since we'd need to sprinkle ifs anyway, pull them > > up close to the call site. Allowing to switch page pool for a > > completely different implementation, like the one Jonathan coded up for > > iouring. Basically > > > > $name_alloc_page(queue) > > { > > if (queue->pp) > > return page_pool_dev_alloc_pages(queue->pp); > > else if (queue->iouring..) > > ... > > } > > Yes, this is more the direction I'm thinking. > In many cases, you don't need this if-statement helper in the driver, as > driver RX side code will know the API used upfront. Meaning that the driver "knows" if it's in the XDP, AF_XDP, iouring or "normal" Rx path? I hope we can avoid extra code in the driver completely, for data pages. > The TX completion side will need this kind of multiplexing return > helper, to return the pages to the correct memory allocator type (e.g. > page_pool being one). See concept in [1] __xdp_return(). > > Performance wise, function pointers are slow due to RETPOLINE, but > switch-case statements (below certain size) becomes a jump table, which > is fast. See[1]. > > [1] https://elixir.bootlin.com/linux/v6.4-rc7/source/net/core/xdp.c#L377 SG! > Regarding room in "struct page", notice that page->pp_magic will have > plenty room for e.g. storing xdp_mem_type or even xdp_mem_info (which > also contains an ID). I was worried about fitting the DMA address, if the pages code from user space. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel