From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 70CAEA09E0; Fri, 13 Nov 2020 18:40:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6AEBEC86C; Fri, 13 Nov 2020 18:40:53 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2564DC868 for ; Fri, 13 Nov 2020 18:40:50 +0100 (CET) IronPort-SDR: BwOvYOigH8j1Z7+Ll2lhtI8qIW2n++/yHRmikMx7Qq0kzSMdpsciWrUg6r+5M0tXun3UVZ0B3O eDmt1X5UvaWQ== X-IronPort-AV: E=McAfee;i="6000,8403,9804"; a="167928789" X-IronPort-AV: E=Sophos;i="5.77,476,1596524400"; d="scan'208";a="167928789" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 09:40:49 -0800 IronPort-SDR: sECQ7ZAPaKS9UPzKCGNtnUyKf5K3cCB8lyVwMLiTgbNMStm+mjAMkZwg10AFaADNFCNpiht2K3 gzgD6T1arbqA== X-IronPort-AV: E=Sophos;i="5.77,476,1596524400"; d="scan'208";a="474746182" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.3.208]) ([10.252.3.208]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 09:40:47 -0800 To: "Li,Rongqing" , "Loftus, Ciara" Cc: "dev@dpdk.org" References: <1601016336-12233-1-git-send-email-lirongqing@baidu.com> <0bf5839c183544559e33846c7b0bc053@intel.com> <7f657f37e6ab448a891e7d6505ff5d77@baidu.com> From: Ferruh Yigit Message-ID: <5bcb4afc-b29d-9bc0-0ddb-476d01a1f7b1@intel.com> Date: Fri, 13 Nov 2020 17:40:45 +0000 MIME-Version: 1.0 In-Reply-To: <7f657f37e6ab448a891e7d6505ff5d77@baidu.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH][v2] net/af_xdp: avoid to unnecessary allocation and free mbuf in rx path X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/14/2020 1:15 PM, Li,Rongqing wrote: > > >> -----Original Message----- >> From: Loftus, Ciara [mailto:ciara.loftus@intel.com] >> Sent: Friday, October 02, 2020 12:24 AM >> To: Li,Rongqing >> Cc: dev@dpdk.org >> Subject: RE: [PATCH][v2] net/af_xdp: avoid to unnecessary allocation and free >> mbuf in rx path >> >>> >>> when receive packets, the max bunch number of mbuf are allocated if >>> hardware does not receive the max bunch number packets, it will free >>> redundancy mbuf, that is low-performance >>> >>> so optimize rx performance, by allocating number of mbuf based on >>> result of xsk_ring_cons__peek, to avoid to redundancy allocation, and >>> free mbuf when receive packets >> >> Hi, >> >> Thanks for the patch and fixing the issue I raised. > > Thanks for your finding > >> With my testing so far I haven't measured an improvement in performance >> with the patch. >> Do you have data to share which shows the benefit of your patch? >> >> I agree the potential excess allocation of mbufs for the fill ring is not the most >> optimal, but if doing it does not significantly impact the performance I would be >> in favour of keeping that approach versus touching the cached_cons outside of >> libbpf which is unconventional. >> >> If a benefit can be shown and we proceed with the approach, I would suggest >> creating a new function for the cached consumer rollback eg. >> xsk_ring_cons_cancel() or similar, and add a comment describing what it does. >> > > Thanks for your test. > > Yes, it has benefit > > We first see this issue when do some send performance, topo is like below > > Qemu with vhost-user ----->ovs------->xdp interface > > Qemu sends udp packets, xdp has not packets to receive, but it must be polled by ovs, and xdp must allocated/free mbuf unnecessary, with this packet, we has about 5% benefit for sending, this depends on flow table complexity > > > When do rx benchmark, if packets per batch is reaching about 32, the benefit is very little. > If packets per batch is far less than 32, we can see the cycle per packet is reduced obviously > Hi Li, Ciara, What is the status of this patch, is the patch justified and is a new versions requested/expected?