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

["Morten Brørup" <mb@smartsharesystems.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrzej Ostruszka
> Sent: Thursday, January 16, 2020 11:43 AM
> 
> 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.
> 

You are right. I momentarily forgot that.

And the example application will show how to do this.

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

Please re-read my reply to Jerin Jacob why I prefer a pull model instead:
https://mails.dpdk.org/archives/dev/2020-January/155386.html

Take a stab at the example application, and see which design pattern is the best fit.