[dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library

[Andrzej Ostruszka]

On 1/16/20 10:30 AM, Morten Brørup wrote:
[...]
>> You are thinking already about modification of the application data.
>> That is actually beyond the scope of the library.
> 
> Yes, it is beyond the scope of the library; but I prefer the library to
> be designed for how typical applications are going to use it.
> 
> I suggest that you supplement the library with an example DPDK application
> that is a simple IPv4 router, forwarding packets and responding to ARP
> requests - according to its configuration applied in the O/S via your proxy
> library. You could even add support for relevant ICMP packets (e.g. respond
> to ICMP Echo Request and send TTL Exceeded when appropriate).

Actually our thinking was more along the way: such router would see
these control packets so it will send them (tx burst) to proxy port and
let the system stack do its job: change config and possibly send reply.
The former would be listened on NETLINK (in Linux) and the later would
be just read from proxy port and forwarded to the bound port.  That way
DPDK application would not have to re-implement these control protocols.

> It will help you determine what is required by the library, and how
> the library best interfaces to a "typical" DPDK application.

Yes indeed, that kind usage discovery exercise would be good.

> I think a poll based design pattern is more appropriate. Getting a Netlink
> message from the O/S and converting it to a callback in the library, and
> then converting it back to a message in the DPDK application seems like
> crossing the river to get water.

You'd still need to repack the message and that could be the job of the
callback.

At the moment we don't have much experience with the library and to me
the callback is more generic approach with which one can achieve
different designs.  However nothing here is curved in stone so if we
figure out that this is too generic we will change it.

[...]
> It was a bitmap of wanted callbacks.

Aaa, right.  Currently the set of available callbacks is returned as a
bitmask.  This API will change if we find out the need for more callbacks.

With regards
Andrzej Ostruszka