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 6F658A0526; Wed, 22 Jul 2020 02:40:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 257521C0D1; Wed, 22 Jul 2020 02:40:34 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 428101C000; Wed, 22 Jul 2020 02:40:32 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C540C5C0125; Tue, 21 Jul 2020 20:40:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 21 Jul 2020 20:40:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= /mlcQdmkmW/SNUN+pGHFtQ8qTfuriK1kcouVnNASt7s=; b=umwvYQVSmg13hzhO smZ79Zrsf3Uf0A5K9nPQtJ6P9+ByCagWQ9/6AB/MWUJjye3xsvj067iC1CNgRRDa TXYUvcRIORjz3vBFpUWZ8+No2du36jLM05DX2YGUffxqKdHEPGIA0nqITG4dXICa gi7BkvAX0t1pNlW4fDwJEX1NzpGk7CeSfQ0pyiYcnV0xcK2wNJi1uDnmf1OnJrLu gXc+r8DD+vbT2tpU3V++JVmjL3MReXHq1uLi2b4ntcgx4Tx4xeRpTY62IdVVAab2 SBRKELlqF1xAnf+E45kMTtISvgXpy/tqeGGhJXvHkgJdR2KBGkRS1OoDlWZqyE44 dK2r4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/mlcQdmkmW/SNUN+pGHFtQ8qTfuriK1kcouVnNASt 7s=; b=qDW8Xxa9b55qb8dAguIwWB4y2kYN9vfaKy81Gk5hk+vDraefZhzR2nBAf ht37e/dgKb+xlxf6rQHosBVBGAeb445YUSJ7gHXUSZLUHrqknl8LEUD7SYs7R035 mxF4SyTo1GbZQKi/B6azbjVvH6Hl6wd1/BzJVVD4QQBrfpLWzk1sPvN9/9u6Xn/W WiJeuH3utvINqUGowCYCT1rGUTQfEIj1Rs23/dWw3W4cJorP5+KhDEym/PaQcWep 4pFVkzSyiwrsKr0d7p2qETaTaw/HiiocCiVAFIQHFb9/n3n1BDHpcklqm8xDtvil fc+wXnFHGQUXy3GggqY3DTUrJK40Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgeekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 97AD830600A3; Tue, 21 Jul 2020 20:40:30 -0400 (EDT) From: Thomas Monjalon To: "Andrzej Ostruszka [C]" Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= , Stephen Hemminger , dev@dpdk.org, techboard@dpdk.org Date: Wed, 22 Jul 2020 02:40:29 +0200 Message-ID: <1734533.zqhfolzEdB@thomas> In-Reply-To: <41291e3d-b902-46af-2915-2a76c6d89097@marvell.com> References: <20200306164104.15528-1-aostruszka@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35C6110C@smartserver.smartshare.dk> <41291e3d-b902-46af-2915-2a76c6d89097@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/4] lib: 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" 09/07/2020 10:43, Andrzej Ostruszka [C]: > First of all let me thank you all one again for the time you took > looking at this and summarize your feedback as I understand it. > > 1. Don't use interrupt thread because in heavy load scenarios this might > cause problems. Yes For this usage, and for other configuration controls like log/trace, we should have a new communication channel. The telemetry and IPC are other examples of communication channels. Ideally we should keep only one channel. > 2. Provide higher level functionality - so that application can just use > it instead of maintaining the info on their own. As said below, higher layers can come later. > 3. Provide way to have control over the changes - if I remember > correctly someone wanted apps to be able to reject the changes (meaning > rolling back the changes to the kernel) Yes, the DPDK app must remain in control of any change. > 4. Don't parse netlink on your own (use e.g. libmnl) > 5. Don't use callbacks Not sure about which communication API to use. It must be discussed. > These are the specific things that I managed to understand. Have I > missed anything? If so please add this to the list! > > To that I say: > Ad1. Agree, will change that. > Ad2. OK, but this can be added later. > Ad3. Currently the lib was meant to be one way but as in previous point > this can change in the future. > Ad4. As mentioned in previous mail I judged it not worthy of adding > dependency but I'm OK with using it. This might be more relevant when > we address point 3 and can be introduced then, but I can do it now. No problem with adding dependencies, especially with meson. > Ad5. There are now notification queues and I'm fine with adapting to any > standard of notification/communication that DPDK will agree on. > > In addition may I ask your opinion on the changes that are required > before the library can be accepted? Very few contributors take time to look at it. Clearly we want this feature. We really want it, but we are not able to dedicate enough time for its review (blaming myself). That's why I Cc the techboard to try a new process: For such feature requiring a community design, and not having enough feedback to progress in a timely manner, I propose drafting the design in a Technical Board meeting (a regular or specific one).