Thread (102 messages) 102 messages, 10 authors, 2023-10-12

Re: [PATCH v4 1/3] lib: introduce dispatcher library

From: Jerin Jacob <hidden>
Date: 2023-09-26 18:29:06

On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom [off-list ref] wrote:
On 2023-09-22 09:38, Mattias Rönnblom wrote:

<snip>
quoted
+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.
<snip>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help