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 6B7F9A0352; Thu, 16 Jan 2020 11:42:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3CF291C1E5; Thu, 16 Jan 2020 11:42:36 +0100 (CET) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by dpdk.org (Postfix) with ESMTP id F33A31C1C8 for ; Thu, 16 Jan 2020 11:42:34 +0100 (CET) Received: by mail-lf1-f66.google.com with SMTP id 203so15178784lfa.12 for ; Thu, 16 Jan 2020 02:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uSO9JIZ2M15cHPyRyfE+1uyKbzEfCHY7WM31d7erDOE=; b=Vdnv1L+pUMfqCRTlmmFQJnACGTsHkGSe0zXF+OrY0vO2HKdojgySwn/Tx5i8oWMxPN buxtbCcOZpYk74I6c9ipuYMg+Kk2UK8fB2JADpQoDM+NB6TROycvunGryCGKU6sOP+OJ h3nv68yltu94vB8VtCthaBhlzHqYGJl6pAuhBJsRIR6Bu/o86NG6SFmThEiVuj7DxUC5 5BGM3kaiONg0zF52EEresO5d9DJ5obWKfqwHRlcaGqx0wt3LPQMswPV31kIQpXpyxMv8 SI3oHFQK/Aj40rJbYJ9LfenAyHjmZHv03GbQTqqQ6wnWAY5Ol1IZ21LQyy9z+Xtxlf0K 9Q5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uSO9JIZ2M15cHPyRyfE+1uyKbzEfCHY7WM31d7erDOE=; b=NIlmLo3y5aQi733HirIj9WrEMzcApkHaJqvENfK2JsUcDHq3YX7CCFdF8pxhLJMvEv /vUr8tZ6gdLI11eBMIudpSoKp7WhrmXOUdKc9XgmDf9v4X2lCfafK+5Vlml5Q3hnAorj WOTdZnuTpRsP3mfX25sicKnnjGIedL+CzsIZEaQzlPadyYJJQH++OMmW0ECTCYTltkQ3 /WirXmYGDBcoM6lL4mgfi3x+m4YcJeY4MQ9TLQmtvvYbDVgluly4tU7dECc6W/ahKhm6 so9jpy7MpuY/NXgTH7sPzi4LsDOUdui3MwqviOIlszXRe4IsoEacIr38RNa3ItSvOAE6 IlpQ== X-Gm-Message-State: APjAAAU0ZsSGE7OVHXBGCrS51FOIdqoXIKPBEir5JYJt1dpLHn8O6ahf ly/CUgOfMUmKr7PlK8o1yjCW0J0pxaBuDQ== X-Google-Smtp-Source: APXvYqy1AqAapgKzTjUkk+4roRWHvYiBH5wvgkFLsqfNT3uaBrsyTy4heWhxnIGIj/mMJLDWNtyczw== X-Received: by 2002:a19:7701:: with SMTP id s1mr2100453lfc.180.1579171354166; Thu, 16 Jan 2020 02:42:34 -0800 (PST) Received: from [10.0.0.72] (31-172-191-173.noc.fibertech.net.pl. [31.172.191.173]) by smtp.gmail.com with ESMTPSA id e20sm10576810ljl.59.2020.01.16.02.42.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 02:42:33 -0800 (PST) To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Jerin Jacob Cc: Bruce Richardson , dpdk-dev 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> <98CBD80474FA8B44BF855DF32C47DC35C60CF6@smartserver.smartshare.dk> <2d686f1b-0fbe-055f-1a1c-493c317ab770@semihalf.com> <98CBD80474FA8B44BF855DF32C47DC35C60CFA@smartserver.smartshare.dk> From: Andrzej Ostruszka Message-ID: <928ffe12-be45-1f5b-8adb-365bac2f92af@semihalf.com> Date: Thu, 16 Jan 2020 11:42:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CFA@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 1/16/20 10:30 AM, Morten Brørup wrote: [...] >> You are thinking already about modification of the application data. >> That is actually beyond the scope of the library. > > Yes, it is beyond the scope of the library; but I prefer the library to > be designed for how typical applications are going to use it. > > I suggest that you supplement the library with an example DPDK application > that is a simple IPv4 router, forwarding packets and responding to ARP > requests - according to its configuration applied in the O/S via your proxy > library. You could even add support for relevant ICMP packets (e.g. respond > to ICMP Echo Request and send TTL Exceeded when appropriate). Actually our thinking was more along the way: such router would see these control packets so it will send them (tx burst) to proxy port and let the system stack do its job: change config and possibly send reply. The former would be listened on NETLINK (in Linux) and the later would be just read from proxy port and forwarded to the bound port. That way DPDK application would not have to re-implement these control protocols. > It will help you determine what is required by the library, and how > the library best interfaces to a "typical" DPDK application. Yes indeed, that kind usage discovery exercise would be good. > I think a poll based design pattern is more appropriate. Getting a Netlink > message from the O/S and converting it to a callback in the library, and > then converting it back to a message in the DPDK application seems like > crossing the river to get water. You'd still need to repack the message and that could be the job of the callback. At the moment we don't have much experience with the library and to me the callback is more generic approach with which one can achieve different designs. However nothing here is curved in stone so if we figure out that this is too generic we will change it. [...] > It was a bitmap of wanted callbacks. Aaa, right. Currently the set of available callbacks is returned as a bitmask. This API will change if we find out the need for more callbacks. With regards Andrzej Ostruszka