From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C8885A0513; Wed, 15 Jan 2020 17:04:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 617721C1F1; Wed, 15 Jan 2020 17:04:36 +0100 (CET) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by dpdk.org (Postfix) with ESMTP id 0675D1C1EF for ; Wed, 15 Jan 2020 17:04:34 +0100 (CET) Received: by mail-io1-f45.google.com with SMTP id i11so18303884ioi.12 for ; Wed, 15 Jan 2020 08:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U3eYETJFvKaqot2HYX6s4UFfGQ2FSjvA8GhgYj2hoGU=; b=mXUq3VnO4F4WF3krUft3Uw3fgmYrjPwqKDjM3GTltJbbVxALz7ZmRKbkLLT0HKivFu OViZwUP9Bi/1dw+9x7P1EORDuKEENQCZpvwEIggf7iaiToaVxJIAhtka7CcPmsvwbVuO BLZjH1BL6kRhge8xUTSyOGz1mAkVa8JN841gWZQhbXLxHL/hgwSTuNL2PZRUGC1JGlc2 BDLbSILzuCrSeCT2BvtxP57U1uwG5ynzanNPpwx1VkAr+FiFSwa2VD8bYBNJM7QT15kf qkX+6W+/0gGc4rc4oPvw3ljzN9LfaNtSnE4MHUdy0ZIH+ta4gjHsXjkBWtSCTEkPZSp+ 7I8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U3eYETJFvKaqot2HYX6s4UFfGQ2FSjvA8GhgYj2hoGU=; b=pOUvM15kDUzbXKklXzF3wCXgvhwM289Ge4rEszgBDAAMOcN8SEOaW90ZcC9LqL3a2B B4pkTPyL15yYcvjwqsHE7/RSIl7mUmYZ1lQGh36GkX60QNBbobewmlnk/A/J3rD8DHR/ Cy0mFQT1RX/TwXPuSGINgwfi8/q22z/FSjoBGYS7SpMjezmET7GB9GWHyWzRgxrnFwN6 7Yq/UbnQ84pAaMI5hMjKsjNn4sUrpJtwLafAqz6DeG5eq7iF/Ba0Oz51OVcd0eR3fRKO mSR6OvlmFfUBNtxBFhl3TDC89mO1xdkHkutYh7F+M118JIS8PvhCMMLlInRbbfR8SfHm K3xA== X-Gm-Message-State: APjAAAUtmIZ/gg4snoWwlsdJjPBDU5tLVT6LrCylIkju0InV09GCzG6B SKlMi3XTPv3nNg2F5LQ1t0sAmVunodlpYCkdo1Q= X-Google-Smtp-Source: APXvYqzb7AsKIoL54sKPyjr+QwaCQI0A2Ice5F/IoIWvWlkKXOuZLwLZb7No5pQoMod346eT2IjZJXzvyPPhlqne8zY= X-Received: by 2002:a6b:c742:: with SMTP id x63mr22607598iof.162.1579104274193; Wed, 15 Jan 2020 08:04:34 -0800 (PST) MIME-Version: 1.0 References: <20200114142517.29522-1-aostruszka@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35C60CE0@smartserver.smartshare.dk> <3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com> <20200115101537.GA1666@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C60CF3@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CF3@smartserver.smartshare.dk> From: Jerin Jacob Date: Wed, 15 Jan 2020 21:34:17 +0530 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Bruce Richardson , Andrzej Ostruszka , dpdk-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jan 15, 2020 at 9:00 PM Morten Br=C3=B8rup wrote: > > > -----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=C3=B8rup > > 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=C3=B8rup 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 st= ack 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 k= ernel's data plane. IMO, it not replacing the Linux IP stack, instead, using the slow path services from Linux or any OS. The use case would vary from simple WiFI router to 5G transport stack. > > For this use case, I think an example application would be a much more us= eful 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 p= roxy library might need to include. > > But consider an advanced router with VRFs, VLANs, policy based routing, m= ultiple WANs provided through network namespaces... the library will be hug= e! We thought of adding the infrastructure and the need per basics, we can scale it up. There is no such infrastructure now with DPDK. At least if someone wishes to contribute to this these area then there should be the path to improve things wrt current situation. > > > > > > > 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 tha= n data plane. Another example to prove your point: The whole process schedu= ling library has very little to do with packet processing. Vaguely related = features are creeping in when objections are not strong enough. Yes. That's the reason for the control path vs data path argument that doesn't have any value. If it is useful for packet processing use cases then have it. > > > 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 bandwid= th optimization appliance, and it doesn't perform any routing, it doesn't u= se any O/S-like features in the data path, and thus it doesn't need to inte= grate with the IP stack in the O/S. (The management interface uses the Linu= x 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 ques= tion its usefulness outside of the specific use case of replacing the fast = path in the Linux kernel. Of course, We still follow the "=C3=80 la carte" model, where we are not forcing to use the library in the end-user application. You can always use whatever control path that makes sense with the end-user applications. But if some application wants to write control plane SW that needs to work Linux/FreeBSD/Windows or other RTOS then it can be used (Again if someone wishes to do so). We can also provide the means for NOPing out the callbacks or override with something it is the specific end-user library as well, so that complete flexibly will be still with the application wrt the usage. > > -Morten >