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 C85D142646; Tue, 26 Sep 2023 20:29:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C721402AA; Tue, 26 Sep 2023 20:29:05 +0200 (CEST) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by mails.dpdk.org (Postfix) with ESMTP id 0F3AD40269; Tue, 26 Sep 2023 20:29:04 +0200 (CEST) Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-7ab4c86eeb0so2812125241.2; Tue, 26 Sep 2023 11:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695752943; x=1696357743; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iT+bEHeDwG+6XA//Ks4weuubxxz1fSeGYUh8njBeL5c=; b=nMcYUopLlmwil/RZApqEtA4ZsA+7W271yHTibtY/4h/ecJZmA+tN2JSgnDcaue0eyG wSA9O7/fx3u9cxE+Nvwzlj3X0EZQcQMeBBC6e82lDymBHgeIv+ZPoEiXUAWTPNcElZEZ NUhHvlvY9Ugk/aYg5Pjd1O07cGXftGTe5NBhNigamgWPM6z85+2iWyAJ5I+NUkCyOjNC 8LKQvhUidooenJcH8Kke9DQT9/PnB1Syi2hN1P0jfpKKtjZZLHuKkraax9ThMpizWn30 +yZreqm6IJgvu4vIrA1vH7DSIdGIVach9PGlev3P+Exg/OkQcwWd20sS8Clk8WmjdfPJ HgzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695752943; x=1696357743; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iT+bEHeDwG+6XA//Ks4weuubxxz1fSeGYUh8njBeL5c=; b=FwI0SuHfl99SYz7EyZvalNVhC9HABcQ4PGxkvW0KREo8m+SNbwKZwKzmudNiQA2tsz LcTIpy1f2KCnBpPFdZTPshp8pZaN90zLaMXmCaIoC1yFxP18d159U08tN15m+kBcKFGG 0UUucm3OPRvN1f7QorAgOluhR7JM/8LY8o+yKkhOmni8+duIQTwnVPjFUitadB86v0ai qgiLWLiItz4oMRcSyTaDe6VMeor0kvJlUfe6tEbT/OuD8a2Qv3o5kQFAKnH7U/NxhlMQ SGPzjp0oV/pZNN9bhJxc6DG3vvTusb6nv5fXk1hiehQmwGhmqKpqUdlVRuHDMRSTgpLA JCGA== X-Gm-Message-State: AOJu0YzhsIOCZOnbnlDDhGawmIibYBYRon69YYZM4evGMlfinxA3fXTm XeNlJ/Hxh8emUA5l2w0CGR4MMVkxPh/5gjm2fqg= X-Google-Smtp-Source: AGHT+IFC93IqAz65iv1hplN3CZmWDJ6Lzk8kB9RnpsE62++ICExfY/2ACBzyoqFfeP/R3z7IAByb9vDWE2/LjIhqDe4= X-Received: by 2002:a67:fb18:0:b0:452:94a4:9c59 with SMTP id d24-20020a67fb18000000b0045294a49c59mr6198456vsr.10.1695752943178; Tue, 26 Sep 2023 11:29:03 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <00d5595f-11a2-089f-f563-3d1d75df27df@lysator.liu.se> From: Jerin Jacob Date: Tue, 26 Sep 2023 23:58:37 +0530 Message-ID: Subject: Re: [PATCH v4 1/3] lib: introduce dispatcher library To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Mon, Sep 25, 2023 at 12:41=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2023-09-22 09:38, Mattias R=C3=B6nnblom 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. > >