> -----Original Message----- > From: dev <dev-boun...@dpdk.org> On Behalf Of Mattias Rönnblom > Sent: Monday, March 15, 2021 2:45 PM > To: Jerin Jacob <jerinjac...@gmail.com> > Cc: Jerin Jacob <jer...@marvell.com>; dpdk-dev <dev@dpdk.org>; Richardson, > Bruce <bruce.richard...@intel.com> > Subject: Re: [dpdk-dev] [RFC] eventdev: introduce event dispatcher > > On 2021-03-07 14:04, Jerin Jacob wrote: > > On Fri, Feb 26, 2021 at 1:31 PM Mattias Rönnblom > > <mattias.ronnb...@ericsson.com> wrote: > >> On 2021-02-25 13:32, Jerin Jacob wrote: > >>> On Fri, Feb 19, 2021 at 12:00 AM Mattias Rönnblom > >>> <mattias.ronnb...@ericsson.com> wrote: > >>>> The purpose of the event dispatcher is primarily to decouple different > >>>> parts of an application (e.g., processing pipeline stages), which > >>>> share the same underlying event device. > >>>> > >>>> The event dispatcher replaces the conditional logic (often, a switch > >>>> statement) that typically follows an event device dequeue operation, > >>>> where events are dispatched to different parts of the application > >>>> based on the destination queue id. > >>> # If the device has all type queue[1] this RFC would restrict to > >>> use queue ONLY as stage. A stage can be a Queue Type also. > >>> How we can abstract this in this model? > >> > >> "All queue type" is about scheduling policy. I would think that would be > >> independent of the "logical endpoint" of the event (i.e., the queue id). > >> I feel like I'm missing something here. > > Each queue type also can be represented as a stage. > > For example, If the system has only one queue, the Typical IPsec > > outbound stages can be > > Q0-Ordered(For SA lookup) -> Q0(Atomic)(For Sequence number update) -> > > Q0(Orderd)(Crypto operation)->Q0(Atomic)(Send on wire) > > > OK, this makes sense. > > > Would such an application want to add a callback > per-queue-per-sched-type, or just per-sched-type? In your example, if > you would have a queue Q1 as well, would want to have the option to have > different callbacks for atomic-type events on Q0 and Q1? > > > Would you want to dispatch based on anything else in the event? You > could basically do it on any field (flow id, priority, etc.), but is > there some other field that's commonly used to denote a processing stage?
I expect that struct rte_event::event_type and sub_event_type would regularly be used to split out different type of "things" that would be handled separately. Overall, I think we could imagine the Queue number, Queue Scheduling type (Re-Ordered, Atomic), Event type, sub event type, Flow-ID.. all contributing somehow to what function to execute in some situation. As a somewhat extreme example to prove a point: An RX core might use rte_flow rules to split traffic into some arbitrary grouping, and then the rte_event::flow_id could be used to select the function-pointer to jump to handle it? I like the *concept* of having a table of func-ptrs, and removing of a switch() in that way, but I'm not sure that DPDK Eventdev APIs are the right place for it. I think Jerin already suggested the "helper function" concept, which seems a good idea to allow optional usage. To be clear, I'm not against upstreaming of such an event-dispatcher, but I'm not sure its possible to build it to be generic enough for all use-cases. Maybe focusing on an actual use-case and driving the design from that is a good approach? Regards, -Harry <snip patch contents below>
