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 32315A0352; Thu, 16 Jan 2020 10:09:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 592631BFD2; Thu, 16 Jan 2020 10:09:37 +0100 (CET) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by dpdk.org (Postfix) with ESMTP id 642D81BFD1 for ; Thu, 16 Jan 2020 10:09:36 +0100 (CET) Received: by mail-lf1-f66.google.com with SMTP id r14so14998445lfm.5 for ; Thu, 16 Jan 2020 01:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F0Gxa7xzYp/xBRefT2+T9/wVatvBF0h55TDE7PkwJVE=; b=rTB/YtBstXSPV6M6zftsopHZp9PT3RQNRMR1hDB2KCDPNVxoo2oQriyAdJZ++43O6M eLa0O/FGWXyg6nfhvF9q8mRE/dqzU9faWG2RjpNTYHKkdTCfjw0Exw+b5ppGNDBmJjMr IhDFzSTvpFVgwrHN4xlHqvyKkcU1xsoSsPCnK3xq1XtNwbUX28M3tYYk7BD5DHD/O/y1 tBM/9hkPsFu/uoYNCculOJRxeQm+wQvFqHFh5RH4pzXaT+WQ85t71Ibr8CGIKnDgwmQD iNvA8OaVD2cfjncuxDkFVTM4JuVv17RgoYwjyIyUMcahjfKcNTcqJTfaR2QXypTJinwn 8O1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F0Gxa7xzYp/xBRefT2+T9/wVatvBF0h55TDE7PkwJVE=; b=ef8TwIbitokxz5U+cSbgxIbuVmkfhbInJWDa/Sg5EXPj/tMSYUTgeKu++mt1kjqB4b SkcrK+zn2OzZV81DUrv6CJrxnPHJwdbzLgZkEqoJoyAgNsUdhP432H9a0VisiIIHX2j/ qVYeSvLwj7CASolO3NCso/esX6ZsVKau889KAlrKh3UM3a4QBN2ojIoueCPQaW/V5Vy6 JSSCDfo+ZIznUBjMi+39m5/zhzEaEPvM3pF/8vltRSuqkqYZ9DTnzNRI5etOIWJh1AJJ KTupvrvYT6zG5rCOHqx+AVY4WVJWu5W1lx8NuySJcDEKXvlAVxnc83zHSA1e4jneGojy l1Pg== X-Gm-Message-State: APjAAAVpnZQh/sTWyTOXwsJv3ai7DqKrDKzsvW1oFoYwkqY8ljUcG0ob gFKTb024I9x2+ZPVpfGnk+TFuNYjp1Cq3w== X-Google-Smtp-Source: APXvYqzmBh9TfPaWIgcTnugSk+/10heG8jnnFOVpQAdNfebJft9ekakq9ymaO4KyzfUpOYCCdZoMLw== X-Received: by 2002:ac2:5604:: with SMTP id v4mr1715825lfd.152.1579165775648; Thu, 16 Jan 2020 01:09:35 -0800 (PST) Received: from [10.0.0.72] (31-172-191-173.noc.fibertech.net.pl. [31.172.191.173]) by smtp.gmail.com with ESMTPSA id t1sm10393576lji.98.2020.01.16.01.09.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 01:09:34 -0800 (PST) To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Jerin Jacob Cc: Bruce Richardson , dpdk-dev 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> From: Andrzej Ostruszka Message-ID: <2d686f1b-0fbe-055f-1a1c-493c317ab770@semihalf.com> Date: Thu, 16 Jan 2020 10:09:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60CF6@smartserver.smartshare.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 1/15/20 7:15 PM, Morten Brørup wrote: [...] > OK, you convinced me that a general API for interfacing to the O/S > control plane might be useful. Glad to hear that. [...] > 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 cannot be added in the DPDK route library while it is also > being used by for lookups by a DPDK data plane thread. The same goes > for the hash table library. You are thinking already about modification of the application data. That is actually beyond the scope of the library. The intention of the library is to provide with notification of a change. It is meant to be the task of the callback (provided by the user) to act on the change. It can store the change to be picked up at the next packet burst iteration, or use some RCU synchronization or even stop the world and push the change (if the writer of application deems that appropriate). > This means that callbacks are probably not the right design pattern. What are other possibilities? The library could keep "copy" of the interesting configuration and periodically update it and mark the changes to let application notice. But that would be inefficient - I would have to query all data to check for the diff. So I think the callback is the right design - we get only changes. However please note above explanation, that it is up to application writer to provide callback that would fit design of the application and in cooperation with it will move the network config change into internal data structures. > Furthermore, I have now skimmed the other parts of your patch set. > If I got it right, it looks like there's a limit of 64 callbacks; > this will probably not suffice in the long run. This is interesting. What has given you that impression? I'm really curious since I've written it :). There is a limit on a number of proxies (but this is the same as limit on DPDK ports - so not really a limitation of this lib). BTW since this is a slow path, and I don't need a fast access I keep proxies in a list, so that only those active have allocated memory. Each type of callback is just a member of rte_ifpx_callbacks struct - and yes, as you previously noted, this struct will grow with additional functionality added, but there is no real limit on it. At the moment callbacks are meant to be global - there is a list of callback sets (ifpx_callbacks) that is common for all proxies. I expect that the most common use will be just one set of callbacks for application. But instead of having just one global var I keep a list of sets so many can be registered. There are other options possible: - each type of callback can be a list - callbacks could be "per proxy" - meaning that each proxy port could have its own callbacks The first one could be beneficial if user wants many callbacks registered for some particular type of notification and is not interested in others. The second one can be useful if different proxies should be treated differently - in that case one could avoid conditionals in callback switching behaviour depending on the proxy used. But again this kind of uses are not what I expect as a common use case so I went with current design. > And on the administrative side, I assume one of you guys will volunteer > as the maintainer of this library? Yes. With regards Andrzej Ostruszka