From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 06FDAA0543 for ; Wed, 14 Dec 2022 09:16:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F0D43400D6; Wed, 14 Dec 2022 09:16:25 +0100 (CET) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by mails.dpdk.org (Postfix) with ESMTP id A7BF24003F for ; Wed, 14 Dec 2022 09:16:24 +0100 (CET) Received: by mail-ed1-f46.google.com with SMTP id c17so21357901edj.13 for ; Wed, 14 Dec 2022 00:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IjTZRTauVh6bK7I4UUTVuJS4DY7YvlaDWB0oPwR+8Dw=; b=CM+UE9g37Z0J4FERU5bF/g3+H22hbFfYe1BqGWhgaaDB9boKLCW9Cj5sNoaGOOOEbK ixL4jENPN84R9j4UiYm99tQJAyml8T8algNyMH1S8djqh15AUobKbpEmgsLfQX0bjudb 9CWPSd500LqalIwpxTFRlF5tVbINVxdZnY76l/hjhQANAMkiAXDPTrJtxAR6jIeU4Nhj 5z8VKvTcYo09FroC7Rw8wdtg1nFUMRzzi1jaPoSyO1MyEcepkD76tMf0qy9FkYANNJ5n 6UpAK0vqXSQKasQp/R0Hs2fCRKelOLwIfHKBJ+LfkFAktXIb6cmeWkXINCbPhnpKVBM9 D1MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IjTZRTauVh6bK7I4UUTVuJS4DY7YvlaDWB0oPwR+8Dw=; b=yx0mza3HpR8s1Uo09s0V6bKieXbgaVJHqicF7+XrugeMOGis00eh2By8E8us53IOPZ yQ1NUZJQMFOY0eTv/b5MZK9oq3VKCQCegI1VwwBCM/RjJy53nPkaLqsjlmxwZLzHcDBm MebmPyN/W6GopWsD57LlyYTfUQTLYOodyuW+IE8Ir+U8HptEcDHG4SXKwLHXwz6LSTrD pd5mfnvO9SXlQ8nuNzmhtVGRdEpFta280nyTVtKbJ+ot8lTAlGJSj3YbDlOtEuIRmaAk 48w8qHbJjKQc8V0MIAGtKpzFqpLhsIDW1GVdnpxeuZjIR/VH0f4jXnIunJE8ajm/eOG/ mI4g== X-Gm-Message-State: ANoB5pmFGMyYiRhH1lIBOzVAwNpj3wJE7aUF3U11cySWb1NgupKQEO0+ 22Dz+yHJRCSL70WSSmBWT2wSnJtoZJH2SiawHQ8= X-Google-Smtp-Source: AA0mqf7+Y1JwltxEHyY13agh7775sxTcNlyxV83K2OQR2h2TK9NhNVTJeuFeVMvWNpvtHpg8fHgqfO8M4KNrVB0AJyQ= X-Received: by 2002:a05:6402:5021:b0:460:5340:d522 with SMTP id p33-20020a056402502100b004605340d522mr16081234eda.87.1671005784457; Wed, 14 Dec 2022 00:16:24 -0800 (PST) MIME-Version: 1.0 References: <20221213163447.14a96ea0@hermes.local> In-Reply-To: From: Antonio Di Bacco Date: Wed, 14 Dec 2022 09:16:13 +0100 Message-ID: Subject: Re: Anonymous structs in DPDK To: Pavel Vazharov Cc: Stephen Hemminger , Ferruh Yigit , users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Right, I'm trying to avoid PIMPL because there are a few cases where I need to put a DPDK data type in my classes. Anyway, I will propose a patch adding a tag name to rte_spinlock_t that shouldn't be harmful. Regards, Antonio. On Wed, Dec 14, 2022 at 9:12 AM Pavel Vazharov wrote: > > Hi, > > In my opinion, in that case you'll need to use things like PIMPL to hide the implementation in the .cpp files. (I guess you were just trying to avoid the need of PIMPL by other means?) > And if you need to pass some DPDK related types to the outside world you'll need to wrap them as well. You may need type erasure here and there. It depends on the final goal. > > Regards, > Pavel. > > On Wed, Dec 14, 2022 at 10:03 AM Antonio Di Bacco wrote: >> >> Hi, >> >> I need to completely isolate my application from DPDK, I'm building a >> C++ library that encapsulates the DPDK in order that the application >> doesn't need to include (either directly or indirectly) any DPDK >> header file. In the library cpp files I can include rte_spinlock.h but >> not in the .hpp files. >> >> Best regards. >> >> On Wed, Dec 14, 2022 at 1:34 AM Stephen Hemminger >> wrote: >> > >> > On Tue, 13 Dec 2022 13:55:10 +0000 >> > Ferruh Yigit wrote: >> > >> > > On 12/13/2022 12:51 PM, Antonio Di Bacco wrote: >> > > > I noticed that DPDK include files have a number of anonymous/unnamed struct: >> > > > >> > > > For example: >> > > > >> > > > /** >> > > > * The rte_spinlock_t type. >> > > > */ >> > > > typedef struct { >> > > > volatile int locked; /**< lock status 0 = unlocked, 1 = locked */ >> > > > } rte_spinlock_t; >> > > > >> > > > This choice doesn't allow to use forward declaration. I need forward >> > > > declaration because I'm using a rte_spinlock_t pointer in a C++ class >> > > > and I don't want to include rte_spinlock.h to prevent my application >> > > > to include it as well. >> > > > >> > > > Is there any reason to use unnamed structures? >> > > > >> > > >> > > Hi Antonio Di, >> > > >> > > I don't think there is a specific reason to not use named struct, I >> > > assume that is only because there was no need to have it. >> > > >> > > So if you need, you can send a simple patch to convert anonymous struct >> > > to named struct, although I am not clear why you can't include >> > > 'rte_spinlock.h' in the file you declare your class. >> > > >> > > Cheers, >> > > ferruh >> > >> > Why not include rte_spinlock.h? Spinlocks are meant to be embedded >> > in the object using it. Using spinlocks by reference adds more space >> > and causes a cache miss.