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 70DCC4265D; Thu, 28 Sep 2023 09:44:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4657540296; Thu, 28 Sep 2023 09:44:56 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 6E89A40273; Thu, 28 Sep 2023 09:44:55 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E5B3E1010F; Thu, 28 Sep 2023 09:44:54 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DA5CFFD40; Thu, 28 Sep 2023 09:44:54 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -2.3 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 87BBDFE38; Thu, 28 Sep 2023 09:44:52 +0200 (CEST) Message-ID: Date: Thu, 28 Sep 2023 09:44:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v4 1/3] lib: introduce dispatcher library To: Bruce Richardson , Jerin Jacob Cc: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= , dev@dpdk.org, Jerin Jacob , techboard@dpdk.org, harry.van.haaren@intel.com, Peter Nilsson , Heng Wang , Naga Harish K S V , Pavan Nikhilesh , Gujjar Abhinandan S , Erik Gabriel Carrillo , Shijith Thotton , Hemant Agrawal , Sachin Saxena , Liang Ma , Peter Mccarthy , Zhirun Yan References: <20230904130313.327809-2-mattias.ronnblom@ericsson.com> <20230922073825.351453-1-mattias.ronnblom@ericsson.com> <20230922073825.351453-2-mattias.ronnblom@ericsson.com> <00d5595f-11a2-089f-f563-3d1d75df27df@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2023-09-27 10:13, Bruce Richardson wrote: > On Tue, Sep 26, 2023 at 11:58:37PM +0530, Jerin Jacob wrote: >> On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom wrote: >>> >>> On 2023-09-22 09:38, Mattias Rönnblom wrote: >>> >>> >>> >>>> +int >>>> +rte_dispatcher_create(uint8_t id, uint8_t event_dev_id) >>>> +{ >>> >>> >>> There are two changes I'm considering: >>> >>> 1) Removing the "id" to identify the dispatcher, replacing it with an >>> forward-declared rte_dispatcher struct pointer. >>> >>> struct rte_dispatcher; >>> >>> struct rte_dispatcher * >>> rte_dispatcher_create(uint8_t event_dev_id); >>> >>> >>> The original reason for using an integer id to identify a dispatcher is >>> to make it look like everything else in Eventdev. I find this pattern a >>> little awkward to use - in particular the fact the id is >>> application-allocated (and thus require coordination between different >>> part of the application in case multiple instances are used). >>> >>> 2) Adding a flags field to the create function "for future use". But >>> since the API is experimental, there may not be that much need to >>> attempt to be future-proof? >>> >>> Any thoughts are appreciated. >> >> IMO, better to have rte_dispatcher_create(struct >> rte_dispatch_create_params *params) >> for better future proofing with specific >> rte_dispatch_crearte_params_init() API(No need to add reserved fields >> in rte_dispatch_create_params now, may need only for before removing >> experimental status) >> >> Just 2c. >> > > I don't like using structs in those cases, I'd much rather have a flags > parameter, as flags can be checked for explicit zeros for future proofing, > while a struct cannot be checked for extra space on the end for future > fields added. > > Furthermore, if we need to add new parameters to the create function, I > actually believe it is better to add them as explicit parameters rather > than new fields to the struct. Struct fields can be missed by a user just > recompiling, while new function parameters will be flagged by the compiler > to make the user aware of the change. [There would be no change for ABI > compatibility as function versioning would be usable in both cases] > I will just have the create() function take the eventdev id, only, and thus make no attempt at "future-proofing". Then we will see what the future holds; flags, function parameters, or function parameters packed into structs.