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 995A7A057C; Thu, 26 Mar 2020 13:41:07 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 764FF2BAE; Thu, 26 Mar 2020 13:41:06 +0100 (CET) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by dpdk.org (Postfix) with ESMTP id 9A7FCF3E for ; Thu, 26 Mar 2020 13:41:05 +0100 (CET) Received: by mail-lf1-f46.google.com with SMTP id z23so4674782lfh.8 for ; Thu, 26 Mar 2020 05:41:05 -0700 (PDT) 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=PX2PtBGBT65uNEFDjWwfGq7ASnbddUtOtLCmuDL4Od4=; b=ap2eXO34FJAsOR6pzqlpsaye7nAD8EfEsws2mK/1AxDMDlHDU4rsfWJEfIiPQh7Hhm M01pMhITJlPomN1SUIEbb5AVuJj3PlGAy6OLOo6Zvi43ee5j4yFRUfXlw1FnUpz3WhCD DQVmYoEaDAtBPVIJzlEhGxAO7oSSC76d6Fh/XqcIEdVBPIlA7oIJiqFLBzJ5Cp0fMz6R K3vluQ4s60TE1053QmYlFBZLG8gYaFYq+sZ94CfXM57Yr0ZrOD9vulHPol2JFwDFGjb/ ufhPjYKdGc48NV/mX6At3rk+z/zZMzgFlPlrKtbGRUwoDKxEj9XEp22kiMtEkqTghlPI Y6ZA== 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=PX2PtBGBT65uNEFDjWwfGq7ASnbddUtOtLCmuDL4Od4=; b=exftajQbFlrCca9OhUX1MmCwFtewBuhR2dXIczviyg7B/nCVlSrcWFrqNfxvpM+nqN P24zLYVdc1nxqpH7odf7kLV1aQ+JcP19rJnLCgr8yscEQBgvRWObcPq41OUdVR7MSr8c 0FrRjQcuJ7j3nUmaEaXgRbhGy5xZJv7VyP8Oxk9or+lZkfjv6iK4J+lR9JaM0RSHXEsU 3unH/Tv1heslYJTYuDvCDHqhoJcw6eyKwWAuAg1FVzgvvEKZCZuV/oLjf/mnqJYIk/8j isvjmoFT+W/8ASZ2Rn/0oH7HezYokNLFUEGJ25Si+mDMFtAh7PkAmDI+ixPBOfVcDJk5 edUw== X-Gm-Message-State: ANhLgQ3TQMPqzT9ZtOvGg3zxj0dn/H3ors+TbTsXdKOGCzUxU10QGEfD B0kU8VeoDCKzgtYiH4+hp6S7/ez0aNsDAg== X-Google-Smtp-Source: ADFU+vuDTsezXtNQvdeK6M7mH5RliY2zcMlSqm+qLOMCHxkElbibzwm+d0qLmM0ZRE/eni6Ov3/PLw== X-Received: by 2002:a05:6512:10cf:: with SMTP id k15mr5896330lfg.142.1585226464081; Thu, 26 Mar 2020 05:41:04 -0700 (PDT) Received: from [192.168.8.100] (user-5-173-40-232.play-internet.pl. [5.173.40.232]) by smtp.gmail.com with ESMTPSA id y184sm1400590lfc.97.2020.03.26.05.41.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Mar 2020 05:41:03 -0700 (PDT) To: David Marchand , Andrzej Ostruszka Cc: dev References: <20200306164104.15528-1-aostruszka@marvell.com> <20200310111037.31451-1-aostruszka@marvell.com> From: Andrzej Ostruszka Message-ID: <55a2b3c7-b2f5-e4dc-6267-d8a27a2a8eee@semihalf.com> Date: Thu, 26 Mar 2020 13:41:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" Thank you David for taking time to look at this. On 3/25/20 9:08 AM, David Marchand wrote: > Hello Andrzej, > > On Tue, Mar 10, 2020 at 12:11 PM Andrzej Ostruszka [...] > I can see we end up exposing structures for registering callbacks. Right. I was thinking more in terms of user convenience so it seemed like a good choice to gather them in one struct and call 'register' once. The fact that the same structure is used to keep them is an implementation choice and this can be decoupled. > Did you consider some ways to avoid exposure of those? (thinking of > ABI maintenance for when this library will elect to non-experimental). I will. So far I used the union for the input since I like when things are well typed :) and there is no need for casting. However I will spend some time on this and will get back to you soon (if you have already something in your head please share). Right now I'm thinking about taking array of callbacks with each entry being ("event type", callback) pair, however need to figure out how to have minimum amount of type casting. > I can see some canary at the end of an enum, can we do without it? I followed discussion on the list about that and have thought about it but deemed that to be not a problem. This enum value is never returned from the library and the event type enum is never taken as an input (only used for event notification). So this is really implementation thing and you are right it would be better to hide it. This might be resolved by itself when I come up with something for the above ABI stability issue. > Is there a pb with merging ifpx support into the existing l3fwd > application rather than introduce a new example? I don't see a problem with merging per se. That might be my misunderstanding of what the examples are. I thought that each library can have its own example to show how it is supposed to be used. So decided to have simplified version of l3fwd - and initially I thought about updating l3fwd but it has some non-trivial optimizations and two modes of operations (hash/lpm) so I wanted something simple to just show how to use the library. Don't know what is the reason for this bi-modality of l3fwd: - if this is just a need to show LPM/Hash in use then I can replace that with single mode of l3fwd-ifpx where LPM is used for routing and Hash is used to keep neighbouring info - if this is to show that both LPM and Hash can be used for routing then it would complicate things as these two have different update properties. I assume (but don't have a solid proof for that) that LPM can be updated by a single writer while being used by multiple readers and use this assumption to show how such structures can be updated (Morten please cover your eyes ;-)) from a callback while other can be updated via event queuing. So if the community decides that it would be OK to morph l3fwd to: - strip the bi-modality - use LPM and Hash for different things (not both for routing) then I'm OK with that and will happily do that. Otherwise adding IFPX to l3fwd will end up with two modes with different routing implementation and different update strategies - a bit like two different apps bundled into one and chosen by the command arg. There is also a question of not having FreeBSD and Windows support yet - so things might get complicated. With regards Andrzej Ostruszka