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 E13C8A00C4; Thu, 31 Oct 2019 10:26:05 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 314541C1E7; Thu, 31 Oct 2019 10:26:04 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 0508E1C1CE for ; Thu, 31 Oct 2019 10:26:02 +0100 (CET) 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 04757B40071; Thu, 31 Oct 2019 09:25:59 +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, 31 Oct 2019 09:25:53 +0000 To: Olivier Matz CC: Slava Ovsiienko , Thomas Monjalon , "dev@dpdk.org" , Matan Azrad , Ori Kam , Yongseok Koh References: <1571922495-4588-1-git-send-email-viacheslavo@mellanox.com> <1572201636-16374-1-git-send-email-viacheslavo@mellanox.com> <20191030154910.d4lcerz3hpbvj6le@platinum> From: Andrew Rybchenko Message-ID: Date: Thu, 31 Oct 2019 12:25:49 +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: <20191030154910.d4lcerz3hpbvj6le@platinum> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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-25012.003 X-TM-AS-Result: No-11.279300-8.000000-10 X-TMASE-MatchedRID: QW5G6BKkLTrmLzc6AOD8DfHkpkyUphL9EhBU1cI2uIMM74Nf6tTB9pRo Ctt1D3ovscy9L7UrjruZWq2xmJ2JDNWqK5V30sx5h2VzUlo4HVOdCQesAegqpkxZkOQ//1dpPYb nA4Nb6v5ujOuMzX351UvxjFO0PDsDV1eFUkqaF5EZSUX8zcPGnzKx0awWOyc10PEN1dptgRCoh2 YV4dKDJn3GnlFv1WKgDum4M15KOSx2VtAvpvEqITBgCmbnj9JmwKkbpBpJKUITY5uS6Wcos6PFj JEFr+olA9Mriq0CDAgBi3kqJOK62YmGcq1C0C9WxEHRux+uk8h+ICquNi0WJFSzMknRk1A8gdwH 0UzOAmyMzFpcBDnlOlLsRSavey0MftwZ3X11IV0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--11.279300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25012.003 X-MDID: 1572513960-oLdXFIUgDTrP Subject: Re: [dpdk-dev] [PATCH v4] ethdev: extend flow metadata 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/30/19 6:49 PM, Olivier Matz wrote: > Hi, > > On Wed, Oct 30, 2019 at 10:35:16AM +0300, Andrew Rybchenko wrote: >> @Olivier, please, take a look at the end of the mail. >> > (...) > >> On 10/29/19 8:19 PM, Slava Ovsiienko wrote: >>>>> +}; >>>>> + >>>>> +/* Mbuf dynamic field offset for metadata. */ extern int >>>>> +rte_flow_dynf_metadata_offs; >>>>> + >>>>> +/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t >>>>> +rte_flow_dynf_metadata_mask; >>>> These two global variables look frightening to me. >>>> It does not look good to me. >>> For me too. But we need the performance, these ones are >>> intended for usage in datapath, any overhead is painful. >> @Olivier, could you share your thoughts, please. > Having a global variable looks unavoidable to me, if we want > performance. > > An alternative can be to use static global variables in every file that > use this dynamic field, and call the register method from it. But I > don't think it would scale if a dynamic field is widely used. Yes, I see. > Why does it look frigthening to you? It is just a good/bad design feeling. No specific technical reasons right now. Let's try and take a look how it goes. > The constraint is that before using this variable, the register function > has to be called. I don't think there are race conditions, because the > field/flag registration is lock protected and always return the same > value.