On 3/26/20 6:42 PM, Andrzej Ostruszka wrote: > On 3/25/20 12:11 PM, Morten Brørup wrote: [...] >> And I am still strongly opposed to the callback method: > > Noted - however for now I would like to keep them. I don't have much > experience with this library so if they prove to be inadequate then we > will remove them. Right now they seem to add some flexibility that I like: > - if something should be changed globally and once (and it is safe to do > so!) then it can be done from the callback > - if something can be prepared once and consumed later by lcores then it > can be done in callback and the callback returns 0 so that event is > still queued and lcores (under assumption that queues are per lcore) > pick up what has been prepared.
Morten I've been thinking about this a bit and would like to know your (and others) opinion about following proposed enhancement. Right now, how queues are used is left to the application decision (per lcore, per port, ...) - and I intend to keep it that way - but they are "match all". What I mean by that is that (unlike callbacks where you have separate per event type) queue has no chance to be selective. So if someone would like to go with queues only they he would have to coordinate between queues (or their "owners") which one does the handling of an event that supposedly should be handled only once. Let's take this forwarding example - the queues are per lcore and each lcore keeps its own copy of ARP table (hash) so when the change is noticed the event is queued to all registered queue, each lcore updates its own copy and everything is OK. However the routing is global (and right now is updated from callback) and if no callback is used for that then the event would be queued to all lcores and application would need to select the one which does the update. Would that be easier/better to register queue together with a bitmask of event types that given queue is accepting? Than during setup phase application would select just one queue to handle "global" events and the logic of event handling for lcores should be simplier. Let me know what you think. With regards Andrzej Ostruszka
