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