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 8836DA0562; Fri, 3 Apr 2020 19:19:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2FDDF1C19B; Fri, 3 Apr 2020 19:19:39 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id B29941C190 for ; Fri, 3 Apr 2020 19:19:37 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id F3F6F5C0258; Fri, 3 Apr 2020 13:19:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 03 Apr 2020 13:19:37 -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=80/isdZUNZvBUMKDwiegrk4pGM+df42cmGfBCGn1XOc=; b=mgNGXzUZXWDZ 5i5m+Dea+29N37S8PREs6OwhhTxHc/nxxfKP+h1aAIGIeqSqhJ/eIamfY7EE+P8u iom5/UNsoIbfIbBtFdex53dKhsDA71vkIiiPZkym+InkB+WF3d66n2y+SbQoDO1w hb/Gcmh2JUolDCPx6oOwfa+3pcgW0+U= 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=80/isdZUNZvBUMKDwiegrk4pGM+df42cmGfBCGn1X Oc=; b=lOTf9Uo9fwGzff6PfdNNYidiJkQabkSA0fb4LTvsbDE/RrNjOKqnedMC3 sll4CQXZHPSMFQAhuLvrVXwP3ucac4DeCBig+wC0j1qVsxzXnde/69kSTNPQFFpS ffgG5gsz58+AveaWl0xuhVnLwcvVlbTdi9jFFGAT+qb7VNj1x2KCXDBuDngBQewe 7ujji52kgFmnRHSAjixjMFz0ORBIdY9XpmI+As01ifu8X8ncOqLy5i0Zfbd0x/02 gBUTbMQA+2XIuMOD68Fp+uyrDn/4D8lpa7YMnZPZxE0JvUbyFkKWqPQZ2YiTFK1R ZCUzZ1mOwdsViwm8s2ZA7nrG3Bj2g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeigdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr 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 4CDD8306CF7A; Fri, 3 Apr 2020 13:19:35 -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: Fri, 03 Apr 2020 19:19:33 +0200 Message-ID: <20334513.huCnfhLgOn@xps> In-Reply-To: References: <20200306164104.15528-1-aostruszka@marvell.com> <7886ce41-84eb-c7c0-fa4d-cd3a44825630@semihalf.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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" 02/04/2020 15:48, Andrzej Ostruszka [C]: > On 3/26/20 6:42 PM, Andrzej Ostruszka wrote: > > On 3/25/20 12:11 PM, Morten Br=F8rup wrote: > [...] > >> And I am still strongly opposed to the callback method: > >=20 > > Noted - however for now I would like to keep them. I don't have much > > experience with this library so if they prove to be inadequate then we > > will remove them. Right now they seem to add some flexibility that I l= ike: > > - if something should be changed globally and once (and it is safe to do > > so!) then it can be done from the callback > > - if something can be prepared once and consumed later by lcores then it > > can be done in callback and the callback returns 0 so that event is > > still queued and lcores (under assumption that queues are per lcore) > > pick up what has been prepared. >=20 > Morten >=20 > I've been thinking about this a bit and would like to know your (and > others) opinion about following proposed enhancement. >=20 > Right now, how queues are used is left to the application decision (per > lcore, per port, ...) - and I intend to keep it that way - but they are > "match all". What I mean by that is that (unlike callbacks where you > have separate per event type) queue has no chance to be selective. >=20 > So if someone would like to go with queues only they he would have to > coordinate between queues (or their "owners") which one does the > handling of an event that supposedly should be handled only once. >=20 > Let's take this forwarding example - the queues are per lcore and each > lcore keeps its own copy of ARP table (hash) so when the change is > noticed the event is queued to all registered queue, each lcore updates > its own copy and everything is OK. However the routing is global (and > right now is updated from callback) and if no callback is used for that > then the event would be queued to all lcores and application would need > to select the one which does the update. >=20 > 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. >=20 > 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. If you agree, we can start a new email thread to better discuss the generic messaging sub-system. 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?