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 43850A04B7; Wed, 14 Oct 2020 14:16:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DBD161DCAC; Wed, 14 Oct 2020 14:16:07 +0200 (CEST) Received: from baidu.com (mx21.baidu.com [220.181.3.85]) by dpdk.org (Postfix) with ESMTP id AD9A61DBFC for ; Wed, 14 Oct 2020 14:16:05 +0200 (CEST) Received: from BC-Mail-Ex14.internal.baidu.com (unknown [172.31.51.54]) by Forcepoint Email with ESMTPS id EC4527412DCB362F5C17; Wed, 14 Oct 2020 20:15:59 +0800 (CST) Received: from BJHW-Mail-Ex15.internal.baidu.com (10.127.64.38) by BC-Mail-Ex14.internal.baidu.com (172.31.51.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Wed, 14 Oct 2020 20:15:59 +0800 Received: from BJHW-Mail-Ex15.internal.baidu.com ([100.100.100.38]) by BJHW-Mail-Ex15.internal.baidu.com ([100.100.100.38]) with mapi id 15.01.1979.006; Wed, 14 Oct 2020 20:15:59 +0800 From: "Li,Rongqing" To: "Loftus, Ciara" CC: "dev@dpdk.org" Thread-Topic: [PATCH][v2] net/af_xdp: avoid to unnecessary allocation and free mbuf in rx path Thread-Index: AQHWkweR+JinpWhObkCY3I0GBwa/l6mC8bewgAv+g/A= Date: Wed, 14 Oct 2020 12:15:59 +0000 Message-ID: <7f657f37e6ab448a891e7d6505ff5d77@baidu.com> References: <1601016336-12233-1-git-send-email-lirongqing@baidu.com> <0bf5839c183544559e33846c7b0bc053@intel.com> In-Reply-To: <0bf5839c183544559e33846c7b0bc053@intel.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.198.42] Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" +AD4- -----Original Message----- +AD4- From: Loftus, Ciara +AFs-mailto:ciara.loftus+AEA-intel.com+AF0- +AD4- Sent: Friday, October 02, 2020 12:24 AM +AD4- To: Li,Rongqing +ADw-lirongqing+AEA-baidu.com+AD4- +AD4- Cc: dev+AEA-dpdk.org +AD4- Subject: RE: +AFs-PATCH+AF0AWw-v2+AF0- net/af+AF8-xdp: avoid to unnec= essary allocation and free +AD4- mbuf in rx path +AD4-=20 +AD4- +AD4- +AD4- +AD4- when receive packets, the max bunch number of mbuf are allocate= d if +AD4- +AD4- hardware does not receive the max bunch number packets, it will= free +AD4- +AD4- redundancy mbuf, that is low-performance +AD4- +AD4- +AD4- +AD4- so optimize rx performance, by allocating number of mbuf based = on +AD4- +AD4- result of xsk+AF8-ring+AF8-cons+AF8AXw-peek, to avoid to redund= ancy allocation, and +AD4- +AD4- free mbuf when receive packets +AD4-=20 +AD4- Hi, +AD4-=20 +AD4- Thanks for the patch and fixing the issue I raised. Thanks for your finding=20 +AD4- With my testing so far I haven't measured an improvement in performan= ce +AD4- with the patch. +AD4- Do you have data to share which shows the benefit of your patch? +AD4-=20 +AD4- I agree the potential excess allocation of mbufs for the fill ring is= not the most +AD4- optimal, but if doing it does not significantly impact the performanc= e I would be +AD4- in favour of keeping that approach versus touching the cached+AF8-con= s outside of +AD4- libbpf which is unconventional. +AD4-=20 +AD4- If a benefit can be shown and we proceed with the approach, I would s= uggest +AD4- creating a new function for the cached consumer rollback eg. +AD4- xsk+AF8-ring+AF8-cons+AF8-cancel() or similar, and add a comment desc= ribing what it does. +AD4-=20 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 -----+AD4-ovs-------+AD4-xdp interface Qemu sends udp packets, xdp has not packets to receive, but it must be poll= ed by ovs, and xdp must allocated/free mbuf unnecessary, with this packet, = we has about 5+ACU- benefit for sending, this depends on flow table complex= ity When do rx benchmark, if packets per batch is reaching about 32, the benefi= t is very little. If packets per batch is far less than 32, we can see the cycle per packet i= s reduced obviously -Li