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 964D8A0352; Thu, 16 Jan 2020 08:15:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6600A1C020; Thu, 16 Jan 2020 08:15:25 +0100 (CET) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 468251C013 for ; Thu, 16 Jan 2020 08:15:24 +0100 (CET) Received: by mail-io1-f65.google.com with SMTP id i7so12234632ioo.5 for ; Wed, 15 Jan 2020 23:15:24 -0800 (PST) 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=Kw2C4L/qnBKg8BfHfESkKJE0z/Pz8OgYislK77f1W0I=; b=cZYUriUZIos/71SAOsKUmXrieP7cXYZLJK4dbMvyZEeikQJ1ypIk3iiinb8txw2y1M 1Byco1jy/wmRWD3YyNCrT3rxNlPDbubYUJMD34fhou5yqWlT0zOFghNc74cu3/x5fuqH p8hHtSvfl8gnzksjgiRQgkqsty6A5MIkRsRHn6rcNpuVUsfmtnK4arfjzx+k1PkTuwLy po1rQk0xyf2qXAA53fmk4+b6TMDIViDo1ocELXdZROo6fWpXV2jsvKId1TwdZK7sY0n/ QPO8hbOpCCURJOGie1734i4jtDj5/lPXUHzLLE5HirIpP4SDtrm9VTeJABVbVdMVdQ6M OJOA== 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=Kw2C4L/qnBKg8BfHfESkKJE0z/Pz8OgYislK77f1W0I=; b=PpdIKXtTOTabMmRySpDhpUntczTF4X3Jyge0aFrAQFwq8ZJAFmmLPaezuEvfGA79Bu 181+FNJROF1r6iWUm1t955V9rZQqc6b0tE5bYh1PadhKY9x9ROWKwMUK9qcK51aD64zv qvfTgxpg70ZY4jpDgKD/Y2eyhR+UUFicJTSfxCRCnjOsNZSmIRQ2EupDuN6VmMkEVtEe tIZ+DphfVc0URgEF6k50gOZdD+rJqzrx8qW1MPop625R/bBK7ED7E/mS82jdkhLKkN72 wMLvOQJAVAdXLi8Lj1PrMHzBGcbT/mVSgiHbXKCOEQCcyQpga0Dt/es2OFtdILiw+DNw mH8g== X-Gm-Message-State: APjAAAUQM/BeCzeJStUyThPx+fOKhz8g+UWNiML7e0fY/mkd5juYoWd9 elXSdqM0AYk/NOXeTl+ImBvFWy0UgJnwI1Y7tt0= X-Google-Smtp-Source: APXvYqxna2yzU2CfTyqEffdVeZW+FtSPK96G2etoRYdxXQrkOhUwWe7hbbfsLJa4EVw3/0ldkUIO6lV6bOqvkttsMH4= X-Received: by 2002:a5e:8b44:: with SMTP id z4mr25114763iom.271.1579158923495; Wed, 15 Jan 2020 23:15:23 -0800 (PST) MIME-Version: 1.0 References: <20200114142517.29522-1-aostruszka@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35C60CE0@smartserver.smartshare.dk> <3d3bec6c-723e-0f4e-4b67-d4b9e0ee6902@semihalf.com> <20200115101537.GA1666@bricha3-MOBL.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC35C60CEC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C60CF3@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C60CF6@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CF6@smartserver.smartshare.dk> From: Jerin Jacob Date: Thu, 16 Jan 2020 12:45:07 +0530 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Bruce Richardson , Andrzej Ostruszka , dpdk-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC PATCH 0/3] 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 Wed, Jan 15, 2020 at 11:45 PM Morten Br=C3=B8rup wrote: > > > > IMO, in order to have effective use of data plane, the control > > > > plane has to be integrated together in an OS-independent way. > > > > > > > > > > Also remember that not all DPDK applications need an IP stack resembl= ing > > what Linux has. E.g. the SmartShare StraightShaper is a transparent > > bandwidth optimization appliance, and it doesn't perform any routing, i= t > > doesn't use any O/S-like features in the data path, and thus it doesn't > > need to integrate with the IP stack in the O/S. (The management interfa= ce > > uses the Linux IP stack, but it is completely isolated from the DPDK > > application's data plane.) The same can be said about e.g. T-Rex. > > > > > > Obviously, not all DPDK applications use all DPDK libraries, and sinc= e > > I'm not obligated to use it, I'm not strongly opposed against it. I onl= y > > question its usefulness outside of the specific use case of replacing t= he > > fast path in the Linux kernel. > > > > Of course, We still follow the "=C3=80 la carte" model, where we are no= t > > forcing to use the library in the end-user application. You can always > > use whatever control path that makes sense with the end-user > > applications. > > But if some application wants to write control plane SW that needs to > > work Linux/FreeBSD/Windows or other RTOS then it can be used (Again if > > someone wishes to do so). > > We can also provide the means for NOPing out the callbacks or override > > with something it is the specific end-user library as well, so that > > complete flexibly will be still with the application wrt the usage. > > > > OK, you convinced me that a general API for interfacing to the O/S contro= l plane might be useful. So let me switch from arguing against it to provid= ing some constructive feedback: Good news :-) > > You should consider that most DPDK APIs are not thread safe, meaning that= their internal structures cannot be manipulated/reconfigured by a control = plane thread while data plane threads are accessing them. E.g. a route cann= ot be added in the DPDK route library while it is also being used by for lo= okups by a DPDK data plane thread. The same goes for the hash table library= . This means that callbacks are probably not the right design pattern. I think, we can have only two design patterns for this case. 1) push model(i.e callback). In this case, DP gets the callback, if it is not the correct time to apply the configuration then DP can store it in its own queue and pull it latter. 2) pull model. In this case, the library stores the events. When DP needs the events, it can pull the events from the library. Do you have any other model in mind? and what is your preference among two? > > AFAIK, the DPDK documentation doesn't mention any "best practices" for in= teraction between the control plane and data plans threads, so I understand= why you chose a design pattern similar to the NIC Link Status Change inter= rupt design pattern. > > Furthermore, I have now skimmed the other parts of your patch set. If I g= ot it right, it looks like there's a limit of 64 callbacks; this will proba= bly not suffice in the long run. Yes. We will increase it. > And on the administrative side, I assume one of you guys will volunteer a= s the maintainer of this library? Yes > > -Morten