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 AFBCFA0562; Sat, 4 Apr 2020 21:58:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BC54114583; Sat, 4 Apr 2020 21:58:29 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 03B46AAD5 for ; Sat, 4 Apr 2020 21:58:27 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id A694C2FD; Sat, 4 Apr 2020 15:58:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 04 Apr 2020 15:58:26 -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=mesmtp; bh=c2mFA0FmkfwJdaYgFMeLhcYAtwuGHfmEmSp/Yn/kRpQ=; b=hDfbPb1NL4BW KAhO04NPZxQQA8YGa+YNz9pXmDgrWb63zhUjLZjjW9m8ZBqzI4b2HAc6aHAKvgEz ALVr2N+bmn6kId597oD/gGpqY99P9sVissLhtrzCNPFve76nQdl2xWFJixHvcwXZ qSQ7eIk/mqahOvpBw755VNZ+IVUZeKE= 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=fm2; bh=c2mFA0FmkfwJdaYgFMeLhcYAtwuGHfmEmSp/Yn/kR pQ=; b=k+V+HsYhdNMzfV1T6NE0mASXPz1AbFUT/WojvcYdKjSpGrBTwKPu3gVHN fe4+9BcJSHUXvzqoBV3g8GYMDwHAi4bPtbWhP6qr/Xvx9bdE6MQfCpYunxBY5nPW csyhSzAidIBdR07AqaOiBd1OdN8crP0u+cxAhXQIUTXMBJPYaYfHGxatN000pNPv dR29GmLOEdA2jw0Fp0xhDT7MP0YJNndknYrExYCWMF7ItFURez9dMP6SgT1KO1M9 KpzQJMSnXkWPP2am/p6H7+6hNKy1jc3Bv080FSxSn+oWTYXUwATt+vbOyJYFsZnU 0MA9w5So4xwI2StIRVGylM19OVkYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdekgddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpeiivghrohhmqhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeeg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhoh hmrghssehmohhnjhgrlhhonhdrnhgvth 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 BE860328005A; Sat, 4 Apr 2020 15:58:23 -0400 (EDT) From: Thomas Monjalon To: "Andrzej Ostruszka [C]" Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= , David Marchand , "dev@dpdk.org" , "bruce.richardson@intel.com" , "anatoly.burakov@intel.com" Date: Sat, 04 Apr 2020 21:58:22 +0200 Message-ID: <2580933.jp2sp48Hzj@xps> In-Reply-To: References: <20200306164104.15528-1-aostruszka@marvell.com> <20334513.huCnfhLgOn@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/4] 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" 04/04/2020 20:30, Andrzej Ostruszka [C]: > Thomas, > > I have replied to the other mail, here I just want to confirm, that I'm > fine with the proposed "general messaging" which other libraries (IF > Proxy including) could utilize. > > See also below. > > On 4/3/20 7:19 PM, Thomas Monjalon wrote: > > 02/04/2020 15:48, Andrzej Ostruszka [C]: > >> On 3/26/20 6:42 PM, Andrzej Ostruszka wrote: > [...] > >> Would that be easier/better to register queue together with a bitmask of > >> event types that given queue is accepting? Than during setup phase > >> application would select just one queue to handle "global" events and > >> the logic of event handling for lcores should be simplier. > >> > >> Let me know what you think. > > > > I think we want to avoid complicate design. > > So let's choose between callback and message queue. > > I vote for message queue because it can handle any situation, > > and it allows to control the context of the event processing. > > The other reason is that I believe we need message queueing for > > other purposes in DPDK (ex: multi-process, telemetry). > > > > You start thinking about complex message management. > > And I start thinking about other usages of message queueing. > > So I think it is the right time to introduce a generic messaging in DPDK. > > Note: the IPC rte_mp should be built on top of such generic messaging. > > Do you have also inter-lcore communication in mind here? Or just > "external" world to "some DPDK controller/dispatcher" and how that is > passed to other cores is an application writer problem. I was thinking at communication with: - DPDK event from random context - secondary process - external application - remote application In all cases, I thought the message receiver would be the master core. But you are probably right that targeting a specific core may be interesting. > > If you agree, we can start a new email thread to better discuss > > the generic messaging sub-system. > > Yes, lets talk about that. Let's start with the requirements (as above). I'll write such email soon. > > I describe here the 3 properties I have in mind: > > > > 1/ Message policy > > One very important rule in DPDK is to let the control to the application. > > So the messaging policy must be managed by the application via DPDK API. > > > > 2/ Message queue > > It seems we should rely on ZeroMQ. Here is why: > > http://zguide.zeromq.org/page:all#Why-We-Needed-ZeroMQ > > > > 3/ Message format > > I am not sure whether we can manage with "simple strings", TLV, > > or should we use something more complex like protobuf?