On 2021-03-15 16:00, Van Haaren, Harry wrote: >> -----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.
Sure, and add to this list the contents of the mbuf (or other user payload). What you should keep in mind (and maybe you did), is that the primary aim is to allow decoupling of different parts of an application (or even multiple applications), sharing an event device. > 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? > The intention is that the event dispatcher is optional. For performance and/or flexibility, many applications would still use the normal event device enqueue and dequeue operations. The event dispatcher not supposed to cover all possible use cases in the sense that it will able to remove all conditional logic used to select the function call which marks the beginning of the processing for an event. It should be an aim to cover most cases, where one set of events goes to one software module, and another goes elsewhere. (The original RFC design stems from an actual use case - but it's just one.) An alternative design would be to turn the whole thing around, in the sense that instead of the application specifying which queue id/sched type/sub event type/etc goes to which callback, you split the callback in two: one callback to answer the question "is this your event" and another callback to actually dispatch the event (with the same signature as the callback in the RFC). If made completely generic (and thus remove any references made to queue id in the API), it would require a handful (or maybe more) callback calls per event in the dispatcher. Sounds less than ideal from a performance point of view. If you kept the queue id as the basic arbiter of the event stream, the overhead should be reduced to something more manageable in most applications. A side-effect of this scheme is it provides an opportunity for the dispatcher to order the just-dequeued events in batches to the different consumer callbacks, before dispatching them - basically for free. For many applications, this should have a large upside in the form of improved cache locality and fewer branch mispredicts. To reap those benefits, batching on queue id should also be performed. If there's interest, I could try to do a RFC of this alternative approach as well, and have a look at the performance implications. > Regards, -Harry > > <snip patch contents below>
