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 1FBBCA04FD; Wed, 15 Jan 2020 11:15:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 659C61BF7C; Wed, 15 Jan 2020 11:15:45 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 457AA1B9B5 for ; Wed, 15 Jan 2020 11:15:43 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 02:15:40 -0800 X-IronPort-AV: E=Sophos;i="5.70,322,1574150400"; d="scan'208";a="218078690" 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 02:15:39 -0800 Date: Wed, 15 Jan 2020 10:15:37 +0000 From: Bruce Richardson To: Andrzej Ostruszka Cc: dev@dpdk.org Message-ID: <20200115101537.GA1666@bricha3-MOBL.ger.corp.intel.com> References: <20200114142517.29522-1-aostruszka@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35C60CE0@smartserver.smartshare.dk> <3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com> 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 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?