[dpdk-dev] [PATCH v2 0/4] Introduce IF proxy library

[Thomas Monjalon]

02/04/2020 15:48, Andrzej Ostruszka [C]:
> 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.

I think we want to avoid complicate design.
So let's choose between callback and message queue.
I vote for message queue because it can handle any situation,
and it allows to control the context of the event processing.
The other reason is that I believe we need message queueing for
other purposes in DPDK (ex: multi-process, telemetry).

You start thinking about complex message management.
And I start thinking about other usages of message queueing.
So I think it is the right time to introduce a generic messaging in DPDK.
Note: the IPC rte_mp should be built on top of such generic messaging.

If you agree, we can start a new email thread to better discuss
the generic messaging sub-system.
I describe here the 3 properties I have in mind:

1/ Message policy
One very important rule in DPDK is to let the control to the application.
So the messaging policy must be managed by the application via DPDK API.

2/ Message queue
It seems we should rely on ZeroMQ. Here is why:
http://zguide.zeromq.org/page:all#Why-We-Needed-ZeroMQ

3/ Message format
I am not sure whether we can manage with "simple strings", TLV,
or should we use something more complex like protobuf?