On Wed, Jan 15, 2020 at 01:28:46PM +0100, Morten Brørup wrote: > > -----Original Message----- From: dev [mailto:dev-boun...@dpdk.org] On > > Behalf Of Bruce Richardson Sent: Wednesday, January 15, 2020 11:16 AM > > > > On Tue, Jan 14, 2020 at 06:38:37PM +0100, Andrzej Ostruszka wrote: > > > On 1/14/20 4:16 PM, Morten Brørup wrote: > > > > Andrzej, > > > > > > Hello Morten > > > > > > > Basically you are adding a very small subset of the Linux IP stack> > > to interface with DPDK applications via callbacks. > > > > > > Yes, at the moment this is limited - we'd prefer first to solicit > > > some input from community. > > > > > > > The library also seems to support interfacing to the route table, > > > > so it is not "interface proxy" but "IP stack proxy". > > > > > > True, to some extent - for example you can bring the interface up and > > > down which has nothing to do with IP stack. As for the name of the > > > library - that is actually part where we are completely open. The > > proxy > > > represents port (thus the name) but that is not all, so any better > > name > > > proposals are welcome. > > > > > > > You already mention ARP table as future work. How about namespaces, > > > > ip tables, and other advanced features... I foresee the Devil in > > the > > > > details for any real use case. > > > > > > Right now I don't know what other things are needed. This idea is > > still > > > early. However imagine you'd like to use DPDK to speed up packet > > > processing of IP stack - would you like to implement all the > > protocols > > > that are needed? Or just let the system handle the control path and > > > handle the data path and sniff the control params from the system. > > > > > Like Morten, I'd be a bit concerned at the possible scope of the work > > if we start pulling in functionality from the IP stack like ARP etc. To > > avoid this becoming a massive effort, how useful would it be if we just > > limited the scope to physical NIC setup only, and did not do anything > > above the l2 layer? > > Think about it... Regardless of scope, this is clearly a control plane > API, not a data plane API. > > It provides a proxy API for the O/S control plane (NETLINK in the case of > Linux), so the DPDK application can use the user interface that the O/S > already provides (e.g. "ip link set dev tap1 mtu 1600" etc.) for its > control plane, instead of implementing its own CLI (or GUI or whatever). > > In order to provide significant value, it will have to grow massively, so > I can use it as imagined: To make a Linux firewall where the DPDK > application handles the data plane, and the normal Linux commands are > used for setting up the firewall, incl. firewall rules, port forwarding, > NAPT, etc.. The Devil is in the details here! > > Although I like the concept and idea behind it, I don't think a control > plane proxy API belongs in DPDK. But it could possibly be hosted by the > DPDK project, if approved as such. > Personally, I wouldn't worry to much about control plane vs userplane for this, if it's of significant benefit to DPDK users then it should be considered.
/Bruce
