> -----Original Message----- > From: dev [mailto:dev-boun...@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.