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

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jan 15, 2020 at 01:28:46PM +0100, Morten Brørup 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).
> 
> 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