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 A788143D73; Fri, 29 Mar 2024 01:10:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1345F410F9; Fri, 29 Mar 2024 01:10:46 +0100 (CET) Received: from ma-mailsvcp-mx-lapp01.apple.com (ma-mailsvcp-mx-lapp01.apple.com [17.32.222.22]) by mails.dpdk.org (Postfix) with ESMTP id D297140042 for ; Fri, 29 Mar 2024 01:10:44 +0100 (CET) Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SB3003811TVII20@ma-mailsvcp-mx-lapp01.apple.com> for dev@dpdk.org; Thu, 28 Mar 2024 17:10:44 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=o4fzu7SDUJt3BY+iFp6AuYby/XNXmkYZRI/l9PSLQ84=; b=rVLqTkOiFqiejq8VZ/NPdPx4pFnTcZK5uYPXEopXaazZDH1T6yBjGS9tBFMTCrJgMhT1 a08veHUonfOVXIiwatd+Yl/fnCH738kRGUd+IWaZ9w3OtqbbFCuVjAQo2NIMppl++t9W aukJh0qJXH2K3awW4V7GOdHUtDNtDwflOKBbA7HObO6XozLwYogCNRl0QYW6YC0ptjVC fqluK1/JtaU7MM/4Au8Wpv8OBJW0KB92jik1XVEgLrYkOo6HHLr12uTDVstzAN+j9j5v GVOmLauGj9TpmZFcUMgPPSMS8n1Cp/wuI2adm1cvbHCZBGb31ZJ5LI7bDIF+ZzfG2NUB Jg== Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SB300XTC1TV2OC0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 28 Mar 2024 17:10:43 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0SB3004001D6Q300@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 28 Mar 2024 17:10:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 8b991c899b0140bbc0633b05bb55b6c9 X-Va-E-CD: 03ce057ed806074bba9f7851475acfb1 X-Va-R-CD: 75776beac6e1118ff94cbe184688ea71 X-Va-ID: e2a361a4-ee5a-4c16-8f75-166747d9bbd2 X-Va-CD: 0 X-V-A: X-V-T-CD: 8b991c899b0140bbc0633b05bb55b6c9 X-V-E-CD: 03ce057ed806074bba9f7851475acfb1 X-V-R-CD: 75776beac6e1118ff94cbe184688ea71 X-V-ID: 1688b371-1e09-42a5-b0db-7b61f6b24fd6 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-28_18,2024-03-28_01,2023-05-22_02 Received: from localhost (unknown [17.192.171.224]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0SB300VPD1TUY100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 28 Mar 2024 17:10:43 -0700 (PDT) Date: Thu, 28 Mar 2024 17:10:42 -0700 From: Andrey Ignatov To: Stephen Hemminger Cc: dev@dpdk.org, Maxime Coquelin , Chenbo Xia , Wei Shen Subject: Re: [PATCH] vhost: optimize mbuf allocation in virtio Tx packed path Message-id: References: <20240328233338.56544-1-rdna@apple.com> <20240328164426.5b600cd1@hermes.local> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-disposition: inline In-reply-to: <20240328164426.5b600cd1@hermes.local> User-Agent: Mutt/2.2.7 (2022-08-07) 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 Thu, Mar 28, 2024 at 04:44:26PM -0700, Stephen Hemminger wrote: > On Thu, 28 Mar 2024 16:33:38 -0700 > Andrey Ignatov wrote: > > > > > +static __rte_always_inline uint16_t > > +get_nb_avail_entries_packed(const struct vhost_virtqueue *__rte_restrict vq, > > + uint16_t max_nb_avail_entries) > > +{ > > You don't need always inline, the compiler will do it anyway. I can remove it in v2, but it's not completely obvious to me how is it decided when to specify it explicitly and when not? I see plenty of __rte_always_inline in this file: % git grep -c '^static __rte_always_inline' lib/vhost/virtio_net.c lib/vhost/virtio_net.c:66