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 E9DF142633; Mon, 25 Sep 2023 09:11:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7DB25402CC; Mon, 25 Sep 2023 09:11:42 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 1EED1402B7; Mon, 25 Sep 2023 09:11:41 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 8736B7A80; Mon, 25 Sep 2023 09:11:40 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 79FD5737F; Mon, 25 Sep 2023 09:11:40 +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 95C12791D; Mon, 25 Sep 2023 09:11:39 +0200 (CEST) Message-ID: <00d5595f-11a2-089f-f563-3d1d75df27df@lysator.liu.se> Date: Mon, 25 Sep 2023 09:11:38 +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 Content-Language: en-US To: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= , dev@dpdk.org Cc: 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> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20230922073825.351453-2-mattias.ronnblom@ericsson.com> 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-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.