From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1026C4360C for ; Thu, 10 Oct 2019 06:26:11 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 772C320B7C for ; Thu, 10 Oct 2019 06:26:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 772C320B7C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=solarflare.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 31A981C247; Thu, 10 Oct 2019 08:26:10 +0200 (CEST) Received: from dispatchb-us1.ppe-hosted.com (dispatchb-us1.ppe-hosted.com [148.163.129.53]) by dpdk.org (Postfix) with ESMTP id 336811C208 for ; Thu, 10 Oct 2019 08:26:08 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BE80F480059; Thu, 10 Oct 2019 06:26:05 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Oct 2019 07:25:58 +0100 To: Stephen Hemminger , =?UTF-8?Q?Morten_Br=c3=b8rup?= CC: , , , , , References: <20191009135511.84547-1-mb@smartsharesystems.com> <20191009135511.84547-2-mb@smartsharesystems.com> <20191009155441.5ecd1ae0@hermes.lan> From: Andrew Rybchenko Message-ID: Date: Thu, 10 Oct 2019 09:25:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191009155441.5ecd1ae0@hermes.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24966.003 X-TM-AS-Result: No-4.302000-8.000000-10 X-TMASE-MatchedRID: 9zTThWtzImvmLzc6AOD8DfHkpkyUphL91mc05rOhnpLg91xayX4L80uL vnSICMsvhfvEwiNg/I/xR780BAqSPifiWWEH8aB8zfqlpbtmcWjYuVu0X/rOkIvFa5XXUMbGe/p wbu325er3I4FxnzEes8AbTCLFUbjiqlpVVQEGUr7J5W6OZe5hhYyFtOxfKxTfCySgZBXFfsR3gA GtpjIjbufOVcxjDhcwAYt5KiTiutkLbigRnpKlKZx+7GyJjhAU51m2KEx3Lsf3zqPfIVe3ryrom yB69YuRUDmLuTUvaMlsvQIyHHIfrYcRapcd9kP6eCqsTjM5/DanoHuxTQQm7IWO2L4fq4mNh8xk x6AsMh4ZTSkqdqz5FucIl+0VmRmLNglg0VTTR7tgO21BQaodlQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.302000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24966.003 X-MDID: 1570688767-DRLabBq1pX_s Subject: Re: [dpdk-dev] [PATCH v5 1/1] mbuf: add bulk free function 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/10/19 1:54 AM, Stephen Hemminger wrote: > On Wed, 9 Oct 2019 13:55:11 +0000 > Morten Brørup wrote: > >> >> +/** >> + * @internal helper function for freeing a bulk of packet mbuf segments >> + * via an array holding the packet mbuf segments from the same mempool >> + * pending to be freed. >> + * >> + * @param m >> + * The packet mbuf segment to be freed. >> + * @param pending >> + * Pointer to the array of packet mbuf segments pending to be freed. >> + * @param nb_pending >> + * Pointer to the number of elements held in the array. >> + * @param pending_sz >> + * Number of elements the array can hold. >> + * Note: The compiler should optimize this parameter away when using a >> + * constant value, such as RTE_PKTMBUF_FREE_PENDING_SZ. >> + */ >> +static __rte_always_inline void >> +__rte_pktmbuf_free_seg_via_array(struct rte_mbuf *m, > Overall the patch looks good, but don't think always_inline > is required here. That should be reserved for things that use > inline assembly or other stuff that would be broken if it wasn't > inlined. > > Most compilers would inline it without any modifier anyway. I agree with Stephen that always_inline is not required here. Anyway, Reviewed-by: Andrew Rybchenko