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

[Andrzej Ostruszka [C]]

Thomas,

I have replied to the other mail, here I just want to confirm, that I'm
fine with the proposed "general messaging" which other libraries (IF
Proxy including) could utilize.

See also below.

On 4/3/20 7:19 PM, Thomas Monjalon wrote:
> 02/04/2020 15:48, Andrzej Ostruszka [C]:
>> On 3/26/20 6:42 PM, Andrzej Ostruszka wrote:
[...]
>> 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.

Do you have also inter-lcore communication in mind here?  Or just
"external" world to "some DPDK controller/dispatcher" and how that is
passed to other cores is an application writer problem.

> If you agree, we can start a new email thread to better discuss
> the generic messaging sub-system.

Yes, lets talk about that.

> 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?