DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>,
	"Andrzej Ostruszka" <amo@semihalf.com>
Cc: <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library
Date: Wed, 15 Jan 2020 13:28:46 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk> (raw)
In-Reply-To: <20200115101537.GA1666@bricha3-MOBL.ger.corp.intel.com>

> -----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.


Med venlig hilsen / kind regards
- Morten Brørup

  parent reply	other threads:[~2020-01-15 12:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 14:25 Andrzej Ostruszka
2020-01-14 14:25 ` [dpdk-dev] [RFC PATCH 1/3] lib: introduce IF proxy library (API) Andrzej Ostruszka
2020-01-14 14:25 ` [dpdk-dev] [RFC PATCH 2/3] if_proxy: add preliminary Linux implementation Andrzej Ostruszka
2020-01-14 14:25 ` [dpdk-dev] [RFC PATCH 3/3] if_proxy: add example, test and documentation Andrzej Ostruszka
2020-01-14 15:16 ` [dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library Morten Brørup
2020-01-14 17:38   ` Andrzej Ostruszka
2020-01-15 10:15     ` Bruce Richardson
2020-01-15 11:27       ` Jerin Jacob
2020-01-15 12:28       ` Morten Brørup [this message]
2020-01-15 12:57         ` Jerin Jacob
2020-01-15 15:30           ` Morten Brørup
2020-01-15 16:04             ` Jerin Jacob
2020-01-15 18:15               ` Morten Brørup
2020-01-16  7:15                 ` Jerin Jacob
2020-01-16  9:11                   ` Morten Brørup
2020-01-16  9:09                 ` Andrzej Ostruszka
2020-01-16  9:30                   ` Morten Brørup
2020-01-16 10:42                     ` Andrzej Ostruszka
2020-01-16 10:58                       ` Morten Brørup
2020-01-16 12:06                         ` Andrzej Ostruszka
2020-01-15 14:09         ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=amo@semihalf.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).