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

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

> -----Original Message-----
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Wednesday, January 15, 2020 1:57 PM
> 
> On Wed, Jan 15, 2020 at 5:58 PM Morten Brørup
> <mb@smartsharesystems.com> wrote:
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@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