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 03281A0562; Fri, 3 Apr 2020 21:09:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9D1101BF30; Fri, 3 Apr 2020 21:09:35 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id AC7C41BF1B for ; Fri, 3 Apr 2020 21:09:34 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id a6so8413176ilr.4 for ; Fri, 03 Apr 2020 12:09:34 -0700 (PDT) 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=goPRLztrIi/a7HhijucyG2darboT7tr419cJG+csg3A=; b=LVH4UWgCOGVpCVEu2alkED/n7ekQdLZDH0jKhzKQmJu+u/mFFejF2r8xLd8X7HhbTZ 3SOOedfCP5NyQEKxH/vlfpZcnAKkPQmOIohRqKDla4jpbOLYFWIVauczKQlk/+Df5lhe LaBSC2CVrAMpPatH3Fvj9hpo3eOP6n+lHKcyQKG6WdWHMncVAq6VTfXdO/NqLFC3Ehl3 IZ34FU8VkNdID3pd4B+n7zW8cHAdfwf6JOJcaiBLdPXkEFLKiKgL3QRoOEnEz4r3Y2Xl 4rkLziJ1Scsbt8NVHgjpBeJ8v3KtiJDj4KpKgNAh04UPgOOHD5D590J9NMnniNq/9id0 ZKhg== 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=goPRLztrIi/a7HhijucyG2darboT7tr419cJG+csg3A=; b=cXTSF/mozEjUR8jSVrAo3P0rfkwt22S35OrYGXCDjGbX79FUuD/dYivaJkYhdSuFUJ br726FEknvqjtXZwBIvSMOywXHmTRRW3d0Ac+3TrD5hySIE0MH6tnisxsPPaAK/oWDqo DSlgTeyHnmYKXL/wOxYQjKGPh7ykz/OYeIGdxmJRxM2A3v+aGZb6M7ehxCsTXfSRJtzT kx8NJ48FicTOdI3x4F91J2Fj83pTFObMRujgkhQy05aG/FsfuGHRyj7eyJfOnG9B6K19 iedO+bZwx845Ypk76FvZMdYB9owoHlfOUS/ariT/qrKk9aOskBzpfB3F3tsvYJKp7EYw xYsQ== X-Gm-Message-State: AGi0PubVNyFAYGH//7fzPG5KI2XWw7vUbKHAsuEz8Bvuu5IwF3plWEaS hizLvLyzpN/3956iQmkLTVprv+8awECDufbOfH4= X-Google-Smtp-Source: APiQypJFtX9Hh6uDpFbbZWq6OxiO0Zxng15702Dw4I++GHPKevb5ghTHnW3xxkpEQUIy5JQKTIc950eS2nNAtlpADwM= X-Received: by 2002:a92:48cb:: with SMTP id j72mr10303479ilg.162.1585940973884; Fri, 03 Apr 2020 12:09:33 -0700 (PDT) MIME-Version: 1.0 References: <20200306164104.15528-1-aostruszka@marvell.com> <7886ce41-84eb-c7c0-fa4d-cd3a44825630@semihalf.com> <20334513.huCnfhLgOn@xps> In-Reply-To: <20334513.huCnfhLgOn@xps> From: Jerin Jacob Date: Sat, 4 Apr 2020 00:39:17 +0530 Message-ID: To: Thomas Monjalon Cc: "Andrzej Ostruszka [C]" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , David Marchand , dpdk-dev , "Richardson, Bruce" , Anatoly Burakov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" On Fri, Apr 3, 2020 at 10:49 PM Thomas Monjalon wrote= : > > 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=C3=B8rup wrote: > > [...] > > >> And I am still strongly opposed to the callback method: > > > > > > 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 w= e > > > will remove them. Right now they seem to add some flexibility that I= like: > > > - 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. > > > > Morten > > > > I've been thinking about this a bit and would like to know your (and > > others) opinion about following proposed enhancement. > > > > 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. > > > > 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. > > > > 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. > > > > Would that be easier/better to register queue together with a bitmask o= f > > 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. IMO, it should be left to application decision, Application can use either callback or message queue based on their design and I don't think, DPDK needs to enforce certain model. On the upside, Giving two options, the application can choose the right mod= el. The simple use case like updating the global routing table, The callback scheme would be more than enough. The downside of pushing the architecture to message queue would be that application either need to create additional control thread to poll or call select() get the event or in worst case check the message queue emptiness in fastpat= h. So why to enforce? Thoughts? > The other reason is that I believe we need message queueing for > other purposes in DPDK (ex: multi-process, telemetry). As far as I know, telemetry is using Linux socket fro IPC, I am not sure why do we need to standardize message queue infra? Becasue, each use case is different. > > 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. Do you mean send() and recv() should be wrapped around DPDK call? > > 2/ Message queue > It seems we should rely on ZeroMQ. Here is why: > http://zguide.zeromq.org/page:all#Why-We-Needed-ZeroMQ IMO, ZeroMQ used for IPC over network etc. In this case, the purpose is to pass the Netlink message IN THE SAME SYSTEM to application. Do you need external library dependency? On the same system or multiprocess application, our rte_ring would be more than enough. Right? If not, please enumerate the use case. > > 3/ Message format > I am not sure whether we can manage with "simple strings", TLV, > or should we use something more complex like protobuf? In this use case, we are relying the Netlink message to application at leas= t in Linux case. I think the message should be similar to Netlink message and= give provision for other OS'es such as scheme. Why reinvent the wheel? > >