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 ABFBAA0543 for ; Wed, 14 Dec 2022 09:12:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30992400D6; Wed, 14 Dec 2022 09:12:49 +0100 (CET) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by mails.dpdk.org (Postfix) with ESMTP id A0D424003F for ; Wed, 14 Dec 2022 09:12:48 +0100 (CET) Received: by mail-qt1-f174.google.com with SMTP id c7so1901401qtw.8 for ; Wed, 14 Dec 2022 00:12:48 -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=p42+1ndCQMLdj6vMcioaPjogafGbnCe3DoQscmYbUGs=; b=LBI9BlE5IbkCo7OiznVgASuiL7IxMoUYDjrptZX7w//PT4CdijQMEyweQ0KjKC3C6q ix7x1yC10rrZmOZucaY1eyair+jSGA/2RXBIozeSl+G3eHQTAIualOb4uQCemOMk0Nwd cvXCgVefKtopPJfqB96p/3558ABh2u1L5zY0iTMdRmPflOU00/yvrVsTOF5l2zUQqxfm PgDO/CFsqzMzg38xXoF7pgn7xoLj/FFcN+pSv2btB/TMfiRjS0JvaImQ+etyon7rLFSK P7z5ZTiym5Vkq+dQgcwdhKSlkC/vK6KgTk8VsF9XZTUsTmVkPbCMBSDepB4lGN8pGaGP Ix5g== 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=p42+1ndCQMLdj6vMcioaPjogafGbnCe3DoQscmYbUGs=; b=CiYE7rmHIKYDZGkQasSoDQRg/fcTNcndUi+LXOAPzOCB0xl7q1Mq9Vxe8oqvwkZrtc SUfBN7BMNUPhZ38HAo/33yJX5Wr+NTtwIF8i28f2km8uEBX2fiDQArFW7/1v/XQA/c7u iR4XmapoydhIzsFDkIR/9knLmh7ZZOZnGRLvrYN9YegS6OnIHm2ZqKvRrZUFwDuWuKb+ rZdLW5MObxcP4ftZ9la8yGlIxbk04Z8tOia3k+tLq/reuJOA7e6dWIRPtJOvjTsBSInF Zrnpg7+A/3m1SnzNaUBAphZH5F+Ie5XsN/q6PDju0HGTPyXKit7sq8b7IScPDuYob2gH mTVA== X-Gm-Message-State: ANoB5plIFHMJOqsCkCsmUIOQbuuvw9BphBQgWqjze1lvMGvkm9T+HFNm o9z5yFlQQM/s4hvMqPAcRkdTfQ673ubvD161Nws= X-Google-Smtp-Source: AA0mqf73hSl7gjNHHmSeKtCZEIKe9856aMW9zLhElm5+/LUiSleAmUL8Igs+NAW1lJdCJM04OzNq/dtw8YG5DqRv1v8= X-Received: by 2002:ac8:7382:0:b0:3a8:2e9f:6ae9 with SMTP id t2-20020ac87382000000b003a82e9f6ae9mr14733qtp.293.1671005567986; Wed, 14 Dec 2022 00:12:47 -0800 (PST) MIME-Version: 1.0 References: <20221213163447.14a96ea0@hermes.local> In-Reply-To: From: Pavel Vazharov Date: Wed, 14 Dec 2022 10:12:35 +0200 Message-ID: Subject: Re: Anonymous structs in DPDK To: Antonio Di Bacco Cc: Stephen Hemminger , Ferruh Yigit , users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000004c313305efc54dd6" 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 --0000000000004c313305efc54dd6 Content-Type: text/plain; charset="UTF-8" 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. > --0000000000004c313305efc54dd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In my opinion, in tha= t 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 typ= e erasure here and there. It depends on the final goal.

<= /div>Regards,
Pavel.

On Wed, Dec 14, 2022 at 10:03 AM Antonio D= i Bacco <a.dibacco.ks@gmail.co= m> 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
<stephen= @networkplumber.org> wrote:
>
> On Tue, 13 Dec 2022 13:55:10 +0000
> Ferruh Yigit <ferruh.yigit@amd.com> 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:
> > >
> > > /**
> > >=C2=A0 * The rte_spinlock_t type.
> > >=C2=A0 */
> > > typedef struct {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0volatile int locked; /**<= ; lock status 0 =3D unlocked, 1 =3D 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 i= n 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 str= uct, 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 includ= e
> > '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.
--0000000000004c313305efc54dd6--