> -----Original Message----- > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > Sent: Wednesday, January 15, 2020 1:57 PM > > On Wed, Jan 15, 2020 at 5:58 PM Morten Brørup > <m...@smartsharesystems.com> 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). > > Yes. > > > > > 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! > > Yes. > Another use case would be to handle exception where DPDK may not > handle all the traffic, Traffic such ARP can be redirected to OS. This > would enable DP to focus on the real fast path protocols such as IPv4, > UDP etc. >
These are use cases for DPDK being used in an environment where the IP stack features provided by Linux suffices. It would be great for a simple CPE or Wi-Fi router, e.g. OpenWRT with a DPDK data plane replacing the Linux kernel's data plane. For this use case, I think an example application would be a much more useful way to achieve your goal. Implementing it as an application will also uncover what is really needed, instead of us all speculating about what a proxy library might need to include. But consider an advanced router with VRFs, VLANs, policy based routing, multiple WANs provided through network namespaces... the library will be huge! > > > > 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. > > Why? rte_flow, rte_tm all control plane APIs and it is part of > DPDK. Yes, there are some DPDK libraries leaning more towards control plane than data plane. Another example to prove your point: The whole process scheduling library has very little to do with packet processing. Vaguely related features are creeping in when objections are not strong enough. > IMO, in order to have effective use of data plane, the control > plane has to be integrated together in an OS-independent way. > Also remember that not all DPDK applications need an IP stack resembling what Linux has. E.g. the SmartShare StraightShaper is a transparent bandwidth optimization appliance, and it doesn't perform any routing, it doesn't use any O/S-like features in the data path, and thus it doesn't need to integrate with the IP stack in the O/S. (The management interface uses the Linux IP stack, but it is completely isolated from the DPDK application's data plane.) The same can be said about e.g. T-Rex. Obviously, not all DPDK applications use all DPDK libraries, and since I'm not obligated to use it, I'm not strongly opposed against it. I only question its usefulness outside of the specific use case of replacing the fast path in the Linux kernel. -Morten
