DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrzej Ostruszka <amo@semihalf.com>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library
Date: Tue, 14 Jan 2020 18:38:37 +0100	[thread overview]
Message-ID: <3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CE0@smartserver.smartshare.dk>

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.

> Unless the library is an O/S wrapper to make Linux NETLINK-like messages
> available from other operating systems, ...
The idea is to have this system independent - and in the "next things"
I've mentioned splitting current implementation into common and
system-dependent parts.  AFAIK we do not plan to provide implementation
for other systems, but would like to form it so that is clear how to do
that.  As mentioned in the description FreeBSD implementation could be
really similar but the Windows one would probably require some thread
polling periodically system with "IP Helper" lib calls - I'm not Windows
programmer.  So no - the intent is not to provide "NETLINK-like
messages" to other systems.

> ... I don't really see the value in this library... if it is Linux
> specific, why not just use NETLINK in the DPDK application's control
> plane?

NETLINK is just Linux specific implementation.  And if you confine
yourself only to a Linux specific world - you can think of this library
as what you have just described :).  Free implementation of NETLINK
handling - with a defined API.

Best regards
Andrzej

  reply	other threads:[~2020-01-14 17:38 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 [this message]
2020-01-15 10:15     ` Bruce Richardson
2020-01-15 11:27       ` Jerin Jacob
2020-01-15 12:28       ` Morten Brørup
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=3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com \
    --to=amo@semihalf.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).