From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 970014123A; Tue, 5 Dec 2023 23:58:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RCcunRxY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67DB5C433C7; Tue, 5 Dec 2023 23:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701820731; bh=y7BHMggNMyVLWocVtAJeFzIhuoTSI7WJB9Ya42bDpPc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RCcunRxYB49iecVNOoB875jbF2Efw6Fz9dexz6X6J4FR2np0/PhiID7vIYUARrKA9 jN7SrHTHP1w66d+kqvrjqYirJ1UGqg5Eib+uHe1ig73Ggd4Sfme6RgB/CCZ57dbgWa j0t2EHNfFuEpU0Y6w5cWw43so4l+XY/bTcBpZx19ThHsymgAtDRifPhF662+jsh/sB LCTdQF1qSL3nWuUKT9/BLW/+tYS4YMB0ZQLNwGJWQvCJBuPFH6OFZsW8ARD+LZGVuJ ykjAOuDKF09uY+ooWecSC/XSNPjlnpvTBXwCzqzCSu0znxKNVy0YMr63S8UDY/S/z6 DeBWoPaP+B6Tw== Date: Tue, 5 Dec 2023 15:58:49 -0800 From: Jakub Kicinski To: Lorenzo Bianconi Cc: aleksander.lobakin@intel.com, netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, lorenzo.bianconi@redhat.com, bpf@vger.kernel.org, hawk@kernel.org, toke@redhat.com, willemdebruijn.kernel@gmail.com, jasowang@redhat.com, sdf@google.com Subject: Re: [PATCH v3 net-next 2/2] xdp: add multi-buff support for xdp running in generic mode Message-ID: <20231205155849.49af176c@kernel.org> In-Reply-To: References: <20231201194829.428a96da@kernel.org> <20231204120153.0d51729a@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 6 Dec 2023 00:08:15 +0100 Lorenzo Bianconi wrote: > v00 (NS:ns0 - 192.168.0.1/24) <---> (NS:ns1 - 192.168.0.2/24) v01 ==(XDP_REDIRECT)==> v10 (NS:ns1 - 192.168.1.1/24) <---> (NS:ns2 - 192.168.1.2/24) v11 > > - v00: iperf3 client (pinned on core 0) > - v11: iperf3 server (pinned on core 7) > > net-next veth codebase (page_pool APIs): > ======================================= > - MTU 1500: ~ 5.42 Gbps > - MTU 8000: ~ 14.1 Gbps > - MTU 64000: ~ 18.4 Gbps > > net-next veth codebase + page_frag_cahe APIs [0]: > ================================================= > - MTU 1500: ~ 6.62 Gbps > - MTU 8000: ~ 14.7 Gbps > - MTU 64000: ~ 19.7 Gbps > > xdp_generic codebase + page_frag_cahe APIs (current proposed patch): > ==================================================================== > - MTU 1500: ~ 6.41 Gbps > - MTU 8000: ~ 14.2 Gbps > - MTU 64000: ~ 19.8 Gbps > > xdp_generic codebase + page_frag_cahe APIs [1]: > =============================================== This one should say page pool? > - MTU 1500: ~ 5.75 Gbps > - MTU 8000: ~ 15.3 Gbps > - MTU 64000: ~ 21.2 Gbps > > It seems page_pool APIs are working better for xdp_generic codebase > (except MTU 1500 case) while page_frag_cache APIs are better for > veth driver. What do you think? Am I missing something? IDK the details of veth XDP very well but IIUC they are pretty much the same. Are there any clues in perf -C 0 / 7? > [0] Here I have just used napi_alloc_frag() instead of > page_pool_dev_alloc_va()/page_pool_dev_alloc() in > veth_convert_skb_to_xdp_buff() > > [1] I developed this PoC to use page_pool APIs for xdp_generic code: Why not put the page pool in softnet_data?