Since we've defined user metadata for packets, why not for events as well, since events are the superset of packets? The user metadata structures are, in fact, anchored to the buffer/event type (at least in linux-generic) and hence are already there. We've just chosen to only expose them for packet types.
On Thu, Apr 30, 2015 at 2:48 PM, Ola Liljedahl <[email protected]> wrote: > The timeout event carries a (one) user pointer. > The crypto completion event also carries a (one) user pointer (user > context). > > Now when actually starting to use ODP for an application, I can see the > usefulness for such notification events to carry *two* user-defined > pointers. This would simplify my application. > > My application is very modular and would like to be able to directly > extract (from the notification event) which module is associated with the > event. E.g. multiple modules may be using timers (crypto is in practice > less likely to be used by multiple modules). So when I receive a timeout, > who should process it? I can't really go searching for timer handles in > some data structure. > > The expected usage of the user/context pointer is also required, i.e. to > point to some (flow-) specific state or context. > > I can derive the queue context from the source queue of the event but this > is not granular enough. Many modules will be associated with the same queue > and queue context but will use separate module-specific contexts. > > Essentially (but not necessarily exactly like this) I want to be able to do > event->function(event->state, event); > where function (call-back) pointer and state (context) pointer are stored > in the event. > > There are probably more or less clumsy workarounds using the single > user/context pointer but I would like to know what you guys think about the > idea outlined above. And SoC companies, are two user-defined pointers worse > than one? > > -- Ola > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
