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 AD576A0513; Wed, 15 Jan 2020 12:28:18 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DED1D1C10D; Wed, 15 Jan 2020 12:28:17 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 70CF71C034 for ; Wed, 15 Jan 2020 12:28:16 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id g12so14539194ild.2 for ; Wed, 15 Jan 2020 03:28:16 -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=QMMyReWM4Rs+wTRoN7/De4W5KAt8gBuHSXBz9SlhNwg=; b=PfHXMkn6iYLnQIwAJLxBLZN8nK+MdyiC0I0Sb1H+EGZbtfBv8zy0mCdFJ4RodUd0od QKSZZQ6xKxCEYDsRWoozVbkjZzJqZTxNj4hHMf/YCvXX2k0JHD1wj23Lc12BEq5PSyh0 nWMGMJkSiC8d4OSeXLZTMpCEjINVcDePg2ycCueIjmcq1m6ONSsw0RyK1cURr3kyad0K +QT9rJuoCfJZkG2uu2fskCTaJ2TsuuovlqDDb4ftvo9IJ6A8l4i9YHW8z408++nL079K 7fL19lX7xeSaEOJDDdnf/8QamF+SKGbsiW22p53ZjQIUOFjPIpg/YjZG1J+42oCd61k2 g7OA== 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=QMMyReWM4Rs+wTRoN7/De4W5KAt8gBuHSXBz9SlhNwg=; b=dvQtTfHkDr5sf3+MNFWlbFy8flaJypcZoa6Fmuab6txwB1BqIK9xrWS7O6FkAiIwrC YvUnibvPwaO9ROlrfAErymYcz9UoJHy7VhyFTxAMKGsGZmKnFPqf14I0d4DakPjlm54y EYvEIz8gqaXt1M99bQzN6ZxfRyfk9Qc92N1G6XBSgqXnKSBtcBrcLMDmXnRS7Ld7xFDE 2INzrucMqZNG/oDsvRZ0ds7qvSSemuVEDnh+C+bIEPNazlxuSlsKrjcYnelBywfRneqI Gtl8wFIrf+UpX9KsB/hQ7x6FvhqFNNgeS2dCRmcWFK4RTgPnhwTjzCHcdBw5ME7+7B5k ufBw== X-Gm-Message-State: APjAAAVFkfrnIkts3qytFZn5zmT0A9S+d8DOl21V174522MjuzzPbiGT y8KKMV96fupVnIgyvrUDxPwneoxVp5rmvpV+ynw= X-Google-Smtp-Source: APXvYqxDihB4/BJu0+KZx7Ltto2UgKM5a+n8b7sEgt9ZpW38xzTwn9NEsoLhzSq68qnBjmgGG7rnPIIbedx5YdGEg88= X-Received: by 2002:a92:c747:: with SMTP id y7mr2850781ilp.60.1579087695670; Wed, 15 Jan 2020 03:28:15 -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> In-Reply-To: <20200115101537.GA1666@bricha3-MOBL.ger.corp.intel.com> From: Jerin Jacob Date: Wed, 15 Jan 2020 16:57:59 +0530 Message-ID: To: Bruce Richardson , mb@smartsharesystems.com Cc: dpdk-dev , Andrzej Ostruszka 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 3:45 PM Bruce Richardson wrote: > > On Tue, Jan 14, 2020 at 06:38:37PM +0100, Andrzej Ostruszka wrote: > > On 1/14/20 4:16 PM, Morten Br=C5=99rup wrote: > > > Andrzej, > > > > Hello Morten > > > > > Basically you are adding a very small subset of the Linux IP stack> t= o 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 prox= y > > 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 stil= l > > 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 l= 2 > layer? Like the IPSec library, Marvell would like to add support for additional protocols (probably begin with IPv4, UDP) to DPDK. One of our concerns was the contro= l plane interface for those protocols for effective use in DPDK. Since DPDK h= as support for FreeBSD and Windows OS now, We can not use NETLINK directly in the library. This is the sole intention of this library was the abstract control plane interface. We can start with only the L2 layer for now and but in the future when we add the L3 layer then we need to add the additional items. Suggestions?