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 781A2A0562; Sat, 4 Apr 2020 12:18:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 489FE1BE96; Sat, 4 Apr 2020 12:18:54 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id A05D514583 for ; Sat, 4 Apr 2020 12:18:52 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id x16so9919952ilp.12 for ; Sat, 04 Apr 2020 03:18:52 -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=F4G2vpm5lPj3625DWCQGC/B7oZgsds13zU9LiUQcOSk=; b=tSBqW3ktX4/0uTMlXdqb0K/Z8n0b03bAl7f9WUqjkolR6C2uXPlgVwSztvdCNAsFbN A640rMI5Xna89auKfnlXNfGe/rO3g9EkGa8fEKeVFAcfA90RaikmVRyzLFhz9m2YasOC i6g48LE+BYnqM9QLk19faY2RJFdXTZXOAqdTvCbuyM/u9Bp8CrQfTRK7bNTzIrRXgH4a YGxYf0RCY2U1xwC8wXWxivhlciOtJF+/ZaUrSOfuYGUkGAsR7o8kAkO3CS2Wq9j8x1sq LroCS5oXrWnb7fHH6PG7ltzpNXZfx5TL1uitsCUlRdBRc+/nIdLZvsFPMFiH3X4o7rZN umHg== 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=F4G2vpm5lPj3625DWCQGC/B7oZgsds13zU9LiUQcOSk=; b=JHvVA0Ux8tA9h2PbphCyvy8I0vY8+f8jwIahjcQUUty0/3Z8tKO82SrAqPH0OiuG8d dl1JZ8JAoan+3F8MRaIb/J14dnEljadBp/UOZ2OzOj2Zv1imnsNeCgAWPfHAJXqa+TIF K7h9+zUyEuwkvDRJuxHPHTwBUmHRW8zdhBfXZIQM/pRsAHVRTsDc7RHTSQwXXn3lPods Ile1oV71Zp5OTLU9taTxqHbwF4G/CsXi754RvxSnggOEzjEB6o5q0zeiOW5GKxIT6PfG eKaL60leXpyKfM/6wYoa671cYqZ6SeOogt82JNLh11lU60ogolgeZnovpwsaItxwji7D 8lmQ== X-Gm-Message-State: AGi0Pub84SieWb/pdmp3Wht5f49XQEXIjWzdkkxu/VyMvh56ZM8LOpfb Kmp0pv7TZZZdR1UPLcDec7ePaRfUNMMQICJT0zA= X-Google-Smtp-Source: APiQypK+GYFSS5cHLSGGJQS+p8++w4kacuGHYdXcV00qJ/u4RVxBCaYwo7k+g8Nj5wegjA2iVkOdvKa3UH9Y7okkemk= X-Received: by 2002:a92:2804:: with SMTP id l4mr13363101ilf.130.1585995531783; Sat, 04 Apr 2020 03:18:51 -0700 (PDT) MIME-Version: 1.0 References: <20200306164104.15528-1-aostruszka@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35C60F40@smartserver.smartshare.dk> <2394105.vtBmWVcJkq@xps> In-Reply-To: <2394105.vtBmWVcJkq@xps> From: Jerin Jacob Date: Sat, 4 Apr 2020 15:48:35 +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 Sat, Apr 4, 2020 at 3:27 AM Thomas Monjalon wrote: > > 03/04/2020 23:18, Morten Br=C3=B8rup: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > > 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 hav= e > > > 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 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 lcore= s > > > 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 decisio= n > > > (per > > > > > lcore, per port, ...) - and I intend to keep it that way - but th= ey > > > 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 hav= e > > > 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 i= s > > > > > 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 fo= r > > > that > > > > > then the event would be queued to all lcores and application woul= d > > > need > > > > > to select the one which does the update. > > > > > > > > > > Would that be easier/better to register queue together with a > > > bitmask of > > > > > event types that given queue is accepting? Than during setup pha= se > > > > > 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 rig= ht > > > model. > > > 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 t= o > > > poll or call select() > > > get the event or in worst case check the message queue emptiness in > > > fastpath. > > > So why to enforce? > > > > > > Thoughts? > > > > A message queue would not require an additional control thread. It woul= d use the existing control thread that the application already has. Assuming every application has a control thread. > > > > I think you are missing an important point: > > > > The application needs to handle all control plane interactions, > > not just control plane interactions related to the interface proxy libr= ary. > > Yes this is the point. OK. I think the following message needs to have a unified message access sc= heme. 1) RTE_ETH_EVENT_ events registered using rte_eth_dev_callback_register() 2) rte_mp messages 3) telemetry control message for remote control Future: 4) IF proxy library messages 5) adding the trace control message for remote control. Since it is the control plane, slow path traffic without any performance requirement, Generalize the message comes for zero cost. +1 for standardizing the message if every subsystem planning to do the same= . > > So the application already has (or needs to add) mechanisms in place fo= r this. E.g. if a control plane event (from the interface proxy library or = some other trigger) needs to be distributed across a single or multiple dat= a plane lcores, the application already has (or needs to add) a mechanism f= or doing it. Adding a specific mechanism only in this library does not help= all the other control plane interactions the application needs to handle. = Actually it does the opposite: it requires that the application handles eve= nts from the interface proxy library in a specific way that is different fr= om the way the application already handles other control plane events. > > > > So I'm also voting for simplicity: A single event queue, leaving it up = to the application how to handle these events. +1 > > > > > > 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. > >