From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E87A9C33CB1 for ; Wed, 15 Jan 2020 14:09:18 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 7D18624656 for ; Wed, 15 Jan 2020 14:09:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D18624656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 43D661C031; Wed, 15 Jan 2020 15:09:17 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 44B7D1C020 for ; Wed, 15 Jan 2020 15:09:15 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 06:09:14 -0800 X-IronPort-AV: E=Sophos;i="5.70,322,1574150400"; d="scan'208";a="218137324" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.26]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jan 2020 06:09:13 -0800 Date: Wed, 15 Jan 2020 14:09:10 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Andrzej Ostruszka , dev@dpdk.org Message-ID: <20200115140910.GA1670@bricha3-MOBL.ger.corp.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk> User-Agent: Mutt/1.12.1 (2019-06-15) 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 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