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 94C20A0514; Wed, 15 Jan 2020 13:57:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 24CE71C12E; Wed, 15 Jan 2020 13:57:25 +0100 (CET) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by dpdk.org (Postfix) with ESMTP id 1AB6F1C134 for ; Wed, 15 Jan 2020 13:57:23 +0100 (CET) Received: by mail-io1-f49.google.com with SMTP id d15so17689667iog.3 for ; Wed, 15 Jan 2020 04:57:23 -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=IdlL60DnA/yMGKw2YU9jJuDu95pbG5z69rgam56YHYw=; b=RkKI/SypDhN3qeJGu+sJJmCdAeKaBuJ9dZVm2guLWOAVM4qWmcbr7T4KvILlFGJus/ r6OeWxtOpIPygChBTFobTbx+/IJx+76SvvGA7ygR6OmV64SGCNxtySXY4IxlhwwvXBVv 1SMz2h74hr8srwezn0z2fNtER40eanPEXfs5PKVY4R94VuARrgRQMdLgMH1irOC3WXLo Ac7zdRVrRP6ruOGFm1/vZGr2eYbyVcWBe3DtS/UvSAhkJXvpqRa1MNDtyUVh6Zkl5bMo R+3QP1vSpVFx0FQVPWfqoNFFUts/GcgRmAGHxTsErw97ArCQJUtYqSk4vKyZ1pyA7TQ6 3P5g== 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=IdlL60DnA/yMGKw2YU9jJuDu95pbG5z69rgam56YHYw=; b=JWwwMF5A452Pt2mXoHC+XkIHwSBSz5TrC4p0zZj09ORf9fSi4PVnRqt1fesfpchq8h lTxeA3r2arinE/34eDJ3qpLUlreaLj57y3z+6Klw1gGN1yd3u/lC2+LrKqliY9uqsJ05 8wd1VBurKoLlPpkpTyArbpSocqP716ZbfwrVhAaSNJoqZIAoQ6BlxlBdnvbPSgBXyFla Iv6q7AATx6p393YfGvQNPKPkrEFMNbPVHUgdJyZXxrsYFReJK2AA5SmRluMGSCEGhtWi ANW3vbDymQcJc3wGF3wxJZJ+3TmOXo0EOpOaQj0k3ekEqJc0luSmFKSECP66YC90Eh6X L7iw== X-Gm-Message-State: APjAAAVAhEe/W3yDI88VdTaGvzaNWMta4/v+ZlGl7NmIlIVWgt20avrk A8qbFbVvQckMDTijuaGSyThuV127kM/I3Vkqy0E= X-Google-Smtp-Source: APXvYqxXgrJD/sRRBlzPYitSyNlngwGCSpfz+XUWpVtPEDbD5261rmTDkNeF9gs7UGgde5imbRmrvsyxAD5+HrDq4uc= X-Received: by 2002:a5e:8b44:: with SMTP id z4mr21578946iom.271.1579093042309; Wed, 15 Jan 2020 04:57:22 -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> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk> From: Jerin Jacob Date: Wed, 15 Jan 2020 18:27:06 +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 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 AP= I, 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 al= ready 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 applicat= ion handles the data plane, and the normal Linux commands are used for sett= ing 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. > > Although I like the concept and idea behind it, I don't think a control p= lane 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.IMO, in order to have effective use of data plane, the control plane has to be integrated together in an OS-independent way. > > > Med venlig hilsen / kind regards > - Morten Br=C3=B8rup