From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 19F95A0503; Wed, 18 May 2022 18:53:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0947640A7D; Wed, 18 May 2022 18:53:26 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2082.outbound.protection.outlook.com [40.107.243.82]) by mails.dpdk.org (Postfix) with ESMTP id 37EAD400D6 for ; Wed, 18 May 2022 18:53:24 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I4IMYVdvbt+eBRm71Lqj18qitnTuBaaYeO/64vjW+S5nAL5VT/kZLVgEI6tHoohvE9sweKhrqC7r2fHJ2pfPc5o2zJ3WNMcohT7opXxBWm52gKQ6TZyzESVZFVqn/gpaLoslad9ROf38zQQI6S2MNoFWfvmL/vG8DLc09v1e4BQv2Vkb+5V6UsCcbU9UfdHqVlgrkxPQ3bspRQNRlGsb9Z21PHZ1aZtaqpJxHQeFvQ9TzbFIkHx2r061rJkuSfX8fMwVWPLRT1LSspIMONLbJtu524Uh7b1xxHKax0wSva9ZlSFEwjFcwzK+3fBKZr0ywMoqKOOe/NojxzlkzNaLQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RVaw3lPLHPutTqk9cQ87PN+9lA6uu/ls1pmTLHfg9LE=; b=OuH9Q4TzPjnkjpXWY3IyohjVqbAHOKeqqRjLvkgo4zBBlR5DqCMHEjO5EVLakHyhBR93Poz/Gxe+sJqz5KWxhoQdc5TfWFFI0EibRDWm1ikDdz9mvlAq/4fyBNjzwby2gxXm384SNdgbh6RNXMPxW8O/OSyiAVZfaVQR6BPy55DriVJL//vw85d2cgx+aif5VOh88c0iETTAvItYWbCFIC05BUQgh3JaYwxx0klLk6AYlo8Ajk7JVuc0y7/Mjssp/Be7iDcrrhe9sAiv8xqTlbewtMSiPX3kEZh2DGR3pyL9761N2XvE8EAZ08+WldiYcRajIH9qADi5++kU1nOXhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=arm.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RVaw3lPLHPutTqk9cQ87PN+9lA6uu/ls1pmTLHfg9LE=; b=aTI2vNy+szyc/QpznaHC1ZEJ7H/LILFGukpuiyLhDXMdw+MpQFzII0MduWBq1rON9t4YocQMVsKt+NTs5aXQqQB2nJLJzJqNn2p6YFeYgq1EYQb1thoTGhGPS7K6gAS8z3KsdUQM7Rvr3dtBoxBFFjj34uDmS9NfMYTvbkTEatY= Received: from SA9PR13CA0082.namprd13.prod.outlook.com (2603:10b6:806:23::27) by BL0PR02MB5428.namprd02.prod.outlook.com (2603:10b6:208:37::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.14; Wed, 18 May 2022 16:53:21 +0000 Received: from SN1NAM02FT0013.eop-nam02.prod.protection.outlook.com (2603:10b6:806:23:cafe::4a) by SA9PR13CA0082.outlook.office365.com (2603:10b6:806:23::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.5 via Frontend Transport; Wed, 18 May 2022 16:53:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.80.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.80.198; helo=xir-pvapexch02.xlnx.xilinx.com; pr=C Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by SN1NAM02FT0013.mail.protection.outlook.com (10.97.4.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5273.14 via Frontend Transport; Wed, 18 May 2022 16:53:21 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Wed, 18 May 2022 17:53:20 +0100 Received: from smtp.xilinx.com (172.21.105.198) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Wed, 18 May 2022 17:53:20 +0100 Envelope-to: joyce.kong@arm.com, jgrajcia@cisco.com, ruifeng.wang@arm.com, dev@dpdk.org, nd@arm.com Received: from [172.21.34.28] (port=52397) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1nrMvH-0000Ce-K9; Wed, 18 May 2022 17:53:19 +0100 Message-ID: <579ce4d1-cd10-46cd-709c-3ca66f4de37f@xilinx.com> Date: Wed, 18 May 2022 17:53:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v1 1/2] net/memif: add a Rx fast path Content-Language: en-US To: Joyce Kong , Jakub Grajciar CC: , , References: <20220412093243.3670187-1-joyce.kong@arm.com> <20220517105109.1086090-1-joyce.kong@arm.com> <20220517105109.1086090-2-joyce.kong@arm.com> From: Ferruh Yigit In-Reply-To: <20220517105109.1086090-2-joyce.kong@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21c4fb67-cf02-4111-7d1e-08da38eeea9c X-MS-TrafficTypeDiagnostic: BL0PR02MB5428:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n6XKNvjEp8u3qHDhzatXjz/W88/HnfQQU3bnUmYCZF3k2c1pGLq9VstECizKWI+XHKFG0wQ9JZtmHkqge9bqsj3HCZvFXvBRKQ+EafmLTwDUZvL21MhvwOgfb1llE6UMA9pkbTicTMYeSfPm2FWBQ70Y2wCyMObu5Cp3xFtDeyYS4Q+eauW3EqJyd5NvY/+ij543RC+pq0RgUZPakm8y4KwAfFUreUsK7/FSBYmuPsyBq05MBBE+D5MotjWKdZn2c0iEsXnI+Rzn3wUg/IOD16cGluitsnNe+Zsc75MGgO9e8/jpGBXDXLrg6BiV1OQG9lXP14tpN2CJOKd0NqjjSRvfEQY5+01nLiQA5BInrPNjHo9QZCfBHTG3/osZ+hSopfwtpIEcDQtb/Ek9fLDNowrT6cyR56wal+iI0lcc5U402Nwin60QgQ0xPaoQNrg98ivHhOeZsGH3SrYfHXfNo6OLz4KPLCBRr3MrOP0AUQFN/lhpVhUHXWoX7Lx8KfVkcOy2USyEvyqcSLA34a7j7gL8Cm4mnXAzMRvvuiAymwG3lTDyqxmozYVJRR4QkuJTZEDST25vuIsFAWMjuZwtl5Od8rCYdVD+YvsDhVCKNGqczIQMzr0poaT7XoYDFoi//naUD1mtCSe81fk2LZJEUrPtgmNBWHbLPGvzLhexmTT6oHGIFdTrVUglZy6agqkEvl/Ehp7acP6dsg3FJ79/FYBQbyVd4SLybiANh5ToEh4= X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(44832011)(8936002)(9786002)(110136005)(8676002)(5660300002)(4326008)(508600001)(356005)(7636003)(2906002)(40460700003)(70586007)(426003)(83380400001)(316002)(47076005)(2616005)(186003)(336012)(26005)(53546011)(36756003)(31696002)(54906003)(36860700001)(31686004)(82310400005)(70206006)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2022 16:53:21.3186 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21c4fb67-cf02-4111-7d1e-08da38eeea9c X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT0013.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB5428 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 5/17/2022 11:51 AM, Joyce Kong wrote: > For memif non-zero-copy mode, there is a branch to compare > the mbuf and memif buffer size during memory copying. Add > a fast memory copy path by removing this branch with mbuf > and memif buffer size defined at compile time. The removal > of the branch leads to considerable performance uplift. > > When memif <= buffer size, Rx chooses the fast memcpy path, > otherwise it would choose the original path. > > Test with 1p1q on Ampere Altra AArch64 server, > -------------------------------------------- > buf size | memif <= mbuf | memif > mbuf | > -------------------------------------------- > non-zc gain | 4.30% | -0.52% | > -------------------------------------------- > zc gain | 2.46% | 0.70% | > -------------------------------------------- > > Test with 1p1q on Cascade Lake Xeon X86server, > ------------------------------------------- > buf size | memif <= mbuf | memif > mbuf | > ------------------------------------------- > non-zc gain | 2.13% | -1.40% | > ------------------------------------------- > zc gain | 0.18% | 0.48% | > ------------------------------------------- > Hi Joyce, I have multiple questions, 1) The patch updates only non-zero-copy mode Rx path ('eth_memif_rx'), why zero-copy path performance also impacted? 2) As far as I can see there is a behavior change, more details below 3) patch talking about memif buffer size being defined in compile time, is the big "memif <= mbuf" if block optimized out? Since 'pkt_buffer_size' is a devarg, so it can change from run to run and it is not known in compile time, I doubt that it is optimized out. Is having 'pkt_buffer_size' as devarg breaks your logic? 4) One option gains performance and other loose performance, do you think gain performance case is more common use case? Is there any data around it? Jakub, Do you want to test this patch first before progressing with it? > Signed-off-by: Joyce Kong > --- > drivers/net/memif/rte_eth_memif.c | 124 ++++++++++++++++++++---------- > 1 file changed, 84 insertions(+), 40 deletions(-) > > diff --git a/drivers/net/memif/rte_eth_memif.c b/drivers/net/memif/rte_eth_memif.c > index 587ad45576..f55776ca46 100644 > --- a/drivers/net/memif/rte_eth_memif.c > +++ b/drivers/net/memif/rte_eth_memif.c > @@ -342,66 +342,111 @@ eth_memif_rx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) > goto refill; > n_slots = last_slot - cur_slot; > > - while (n_slots && n_rx_pkts < nb_pkts) { > - mbuf_head = rte_pktmbuf_alloc(mq->mempool); > - if (unlikely(mbuf_head == NULL)) > - goto no_free_bufs; > - mbuf = mbuf_head; > - mbuf->port = mq->in_port; > + if (likely(mbuf_size >= pmd->cfg.pkt_buffer_size)) { > + while (n_slots && n_rx_pkts < nb_pkts) { > + mbuf_head = rte_pktmbuf_alloc(mq->mempool); > + if (unlikely(mbuf_head == NULL)) > + goto no_free_bufs; > + mbuf = mbuf_head; > + mbuf->port = mq->in_port; > + > +next_slot1: > + s0 = cur_slot & mask; > + d0 = &ring->desc[s0]; > > -next_slot: > - s0 = cur_slot & mask; > - d0 = &ring->desc[s0]; > + cp_len = d0->length; > > - src_len = d0->length; > - dst_off = 0; > - src_off = 0; > + rte_pktmbuf_data_len(mbuf) = cp_len; > + rte_pktmbuf_pkt_len(mbuf) = cp_len; > + if (mbuf != mbuf_head) > + rte_pktmbuf_pkt_len(mbuf_head) += cp_len; > > - do { > - dst_len = mbuf_size - dst_off; > - if (dst_len == 0) { > - dst_off = 0; > - dst_len = mbuf_size; > + rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), > + (uint8_t *)memif_get_buffer(proc_private, d0), cp_len); > + > + cur_slot++; > + n_slots--; > > - /* store pointer to tail */ > + if (d0->flags & MEMIF_DESC_FLAG_NEXT) { > mbuf_tail = mbuf; > mbuf = rte_pktmbuf_alloc(mq->mempool); > if (unlikely(mbuf == NULL)) > goto no_free_bufs; > - mbuf->port = mq->in_port; > ret = memif_pktmbuf_chain(mbuf_head, mbuf_tail, mbuf); > if (unlikely(ret < 0)) { > MIF_LOG(ERR, "number-of-segments-overflow"); > rte_pktmbuf_free(mbuf); > goto no_free_bufs; > } > + goto next_slot1; > } It is very hard to comment on the correct part of the patch, since it is mixed a lot, but - previously when memif buffer is segmented, and its size is less than mbuf; mbuf is filled with as much memif data as possible and later switched to next mbuf, like: memif buffer +-+ +-+ +-+ +-+ |a|->|b|->|c|->|d| +-+ +-+ +-+ +-+ +---+ +---+ |abc|->|d | +---+ +---+ mbuf - Now each memif segment is a mbuf, memif buffer +-+ +-+ +-+ +-+ |a|->|b|->|c|->|d| +-+ +-+ +-+ +-+ +---+ +---+ +---+ +---+ |a |->|b |->|c |->|d | +---+ +---+ +---+ +---+ mbuf Can you please confirm this behavior change? If so can you please highlight is more in the commit log? And is this tradeoff something preferred?