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 4946AA057B; Mon, 30 Mar 2020 21:23:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 08B432C15; Mon, 30 Mar 2020 21:23:31 +0200 (CEST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by dpdk.org (Postfix) with ESMTP id 3E9B3FFA for ; Mon, 30 Mar 2020 21:23:29 +0200 (CEST) Received: by mail-lj1-f172.google.com with SMTP id 19so19356735ljj.7 for ; Mon, 30 Mar 2020 12:23:29 -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=kvu05hFqK6diVknmfYeCvHySHJk8xFE56tv205GJ50c=; b=mEjjXs+0N++IuUPSvFhGwu63R/uMYjLET8AHv4R8u9YjAeenJKHPdPcbvMhRFh3OgN OLESTiUFEsxfOzo0MsJNJNs2VOAy0fsAvoB8WBFoqPDVJRRSSOaWcb7MEPVsYR+kVyEG DspNKtMlCRgZV3Oy6dLRWiF0/KGFN29ziTXzCtr0Ez1csQpjdZDXtI4DrNxssnpl7p8K lIR2RZ5+lQPvVISCRJSrl85Q1Hx9uVXUap7KEYyKoVUz2JPygtmH/MMXy5ZebednD3qD 9fr6lBpPNGx/rQvhwKUipC/pN1m7zFheXoWuKs5JxtPCEPCNRMQEH2hZtR9hPVDupO+m IBcQ== 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=kvu05hFqK6diVknmfYeCvHySHJk8xFE56tv205GJ50c=; b=DTXylhMdJMITfHbXPcKReQ/xtr0P+rgr2uDOHo7tvHay1XPl9qH51H0y7Qlp+dQ77Z D923YsNfLxpv8EeFWw2UQ/PBlmCZQ+wnTATXZkhgAy3CS046wwCooxaYJ2v98nmXRINk l7LHoAJXqRIH/L3AljTfZn5cMmCVSlMaZd8kqYRUVX5cM+Gi8XJMchY/AngT0A6ErIJi hp6QVfz8E2N4miHUGjHSHHEGLVXkIVuzJr8qiFe/eCzc3SNF3GmiBqRmdrEiaFIPQyTN 2cUKtYwbmtaTxhk+lEDsOnbOU0g6Vr+iuEQ2t8TrYyHPvEIdtA3DXEmLao+06RW5tFY6 QWLg== X-Gm-Message-State: AGi0PuaZZlcJwvZavZk+a7Gw3yq7Z1lB3fJO/3RqWh2emCvW21bQE8jE pAQKQC0kFzlX9dpayKls5+7neYagWwa9NCz1 X-Google-Smtp-Source: APiQypKQNsoPsUxP5q/cSltwUi5hWL3WJC8JZVfzAiuW1yLT6MZ28UzJzuByJphTNb+JVAZQtjIhcg== X-Received: by 2002:a2e:9d83:: with SMTP id c3mr8004643ljj.3.1585596208011; Mon, 30 Mar 2020 12:23:28 -0700 (PDT) Received: from [192.168.8.100] (user-5-173-56-20.play-internet.pl. [5.173.56.20]) by smtp.gmail.com with ESMTPSA id e14sm7144693ljb.97.2020.03.30.12.23.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2020 12:23:27 -0700 (PDT) To: David Marchand , Andrzej Ostruszka Cc: dev References: <20200306164104.15528-1-aostruszka@marvell.com> <20200310111037.31451-1-aostruszka@marvell.com> <55a2b3c7-b2f5-e4dc-6267-d8a27a2a8eee@semihalf.com> From: Andrzej Ostruszka Message-ID: Date: Mon, 30 Mar 2020 21:23:24 +0200 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: <55a2b3c7-b2f5-e4dc-6267-d8a27a2a8eee@semihalf.com> 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" On 3/26/20 1:41 PM, Andrzej Ostruszka wrote: > 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. David, I thought about this a bit and here is my proposal. Define "typeful" callback pointer (public): union rte_ifpx_cb_ptr { int (*mac_change)(const struct mac_change *ev); int (*mtu_change)(const struct mtu_change *ev); ... int (*cfg_done)(void); }; In implementation make sure its size is as expected: _Static_assert(sizeof(union rte_ifpx_cb_ptr) == sizeof (int(*)(void*)), "Size of callback pointer has to be" "equal to size of function pointer"); Accept as input tagged callbacks (also public type): struct rte_ifpx_callback { enum rte_ifpx_event_type type; union rte_ifpx_cb_ptr callback; }; The user would be defining array of callbacks: struct rte_ifpx_callback callbacks[] = { {RTE_IFPX_MAC_CHANGE, {.mac_change = mac_change}}, {RTE_IFPX_MTU_CHANGE, {.mtu_change = mtu_change}}, ... {RTE_IFPX_CFG_DONE, {.cfg_done = finished}}, }; and passing it to registration together with its length like: int rte_ifpx_callbacks_register(int len, const struct rte_ifpx_callback *cbs) { for (int i = 0; i < len; ++i) { switch (cbs[i].type) { case RTE_IFPX_MAC_CHANGE: priv_cbs.mac_change = cbs[i].callback.mac_change; break; ... } This way we should be protected from ABI breakage when adding new event types and how the callbacks are stored would not be visible to the user. Let me know what do you think about it. With regards Andrzej Ostruszka