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 09FE6A0487 for ; Tue, 2 Jul 2019 12:12:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 02BEA1B96B; Tue, 2 Jul 2019 12:12:04 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 9F3651B964 for ; Tue, 2 Jul 2019 12:12:02 +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-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E206D140053; Tue, 2 Jul 2019 10:12:00 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.154) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jul 2019 11:11:52 +0100 To: Adrien Mazarguil , Dekel Peled CC: "wenzhuo.lu@intel.com" , "jingjing.wu@intel.com" , "bernard.iremonger@intel.com" , Yongseok Koh , "Shahaf Shuler" , Slava Ovsiienko , "dev@dpdk.org" , Ori Kam References: <1389143e204e85c90b4fc124f9e561f43f78175e.1561989889.git.dekelp@mellanox.com> <7e07e792-edd4-b946-641d-4cff9cc2c830@solarflare.com> <20190702095716.GA4512@6wind.com> From: Andrew Rybchenko Message-ID: <42eb6936-9c92-f264-d055-7af44d38c6e7@solarflare.com> Date: Tue, 2 Jul 2019 13:11:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190702095716.GA4512@6wind.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.154] 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-24734.003 X-TM-AS-Result: No-15.499600-8.000000-10 X-TMASE-MatchedRID: gzVbiXtWD9vmLzc6AOD8DfHkpkyUphL9amDMhjMSdnlSAxvL+nqAnV8g kdmvvg/2NfXKx7uO91I5ZtwAbvsNRTM9BBRuZZ1vWTGejGdB9VKl9VzHf0qr7suSXx71bvSL2wR EP4ORcRjbM7Jj/AVcj5uaTBqYX9GVH9B97WCZlj01VHP4fCovgl7OZ6hrwwnzUCgEErrUGFwRFT YYeiiFjHKbhPZvVZNmjC970acVks9/aFyHeBluchlJRfzNw8afF9s8UTYYetXVjuDCvMnExdoDq 9VHWlHWs+eUXG6OjCbo5LO4Ts6jn8PQ1JYlRv1ZKD6w8bPtzSwbAqzdFRyxuJuQSXVIw/hVa0pU x+o1IjbkNMuFdF3RxHIrMsXo7IuOe+y3iJqKT6kSEYfcJF0pRctEPnVvPlFkQsvhZAzTGfjwTW/ s5sxAmxaG88DFWJ4M02PVzFmzBApfiNGIKTLcoWSIsH2qgnAffS0Ip2eEHny+qryzYw2E8LLn+0 Vm71Lcda/BQWxdCOYLbigRnpKlKSBuGJWwgxAr0t0ccteCeDc6pI+VRQbQ+zAX/R9NEDIsQbjz4 Ry1ydatqdbPJqh32r7rweoAIK8o X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--15.499600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24734.003 X-MDID: 1562062322-wx-HHetH_tXw Subject: Re: [dpdk-dev] [PATCH] ethdev: support action with any config object type 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 02.07.2019 12:57, Adrien Mazarguil wrote: > On Tue, Jul 02, 2019 at 08:42:41AM +0000, Dekel Peled wrote: >> Thanks, PSB. >> >>> -----Original Message----- >>> From: Andrew Rybchenko >>> Sent: Tuesday, July 2, 2019 11:09 AM >>> To: Dekel Peled ; Adrien Mazarguil >>> ; wenzhuo.lu@intel.com; >>> jingjing.wu@intel.com; bernard.iremonger@intel.com; Yongseok Koh >>> ; Shahaf Shuler ; Slava >>> Ovsiienko ; arybchenko@solarflare.com >>> Cc: dev@dpdk.org; Ori Kam >>> Subject: Re: [dpdk-dev] [PATCH] ethdev: support action with any config >>> object type >>> >>> On 01.07.2019 17:10, Dekel Peled wrote: >>>> In current implementation, an action which requires parameters must >>>> accept them enclosed in a structure. >>>> Some actions require a single, trivial type parameter, but it still >>>> must be enclosed in a structure. >>>> This obligation results in multiple, action-specific structures, each >>>> containing a single trivial type parameter. >>>> >>>> This patch introduces a new approach, allowing an action configuration >>>> object of any type, trivial or a structure. >>>> >>>> This patch introduces, in test-pmd, a new macro ARG_ENTRY_HTON, to >>>> allow using a single argument, not enclosed in a structure. >>>> >>>> Signed-off-by: Dekel Peled >>> The term "object" confuses me a bit, but I'm not a native speaker so it could >>> be just my wrong association. I'd prefer "configuration data". >> In previous version I wrote just "action configuration", and changed to "action configuration object" per Adrien's suggestion. I think it is better, but if it causes confusion maybe it should be changed. >> >> Adrien, what do you think? Does "configuration data" carry the correct meaning? > Well I'm no native speaker either but "object" is the term used in the C > standard with a well-defined meaning [1] and encompasses everything > (integers, floats, structures, unions, functions, pointers, arrays): > > "region of data storage in the execution environment, the contents of which > can represent values" > > I think it's a bit less vague than "data" because whenever objects are > mentioned in the standard, they always have a type. There's no such thing as > a C object without one, and rte_flow puts a lot of emphasis on documenting > them. > > int foo; > struct { ... } foo; > double foo; > char foo[]; > void *foo; > > Whatever the type, would you refer to "foo" itself as an "object" or as > "data"? Adrien, thanks a lot. Now "object" looks OK and better than "data". > Unrelated, but you must remove ARG_ENTRY_HTON from this patch since there's > no testpmd change in there that requires it. There's no tolerance for dead > code in testpmd as it doesn't expose an API. > > Thanks. > > [1] 3.14 "object" > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf >