From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id ABFBAA0543
for <public@inbox.dpdk.org>; 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 <users@dpdk.org>; Wed, 14 Dec 2022 09:12:48 +0100 (CET)
Received: by mail-qt1-f174.google.com with SMTP id c7so1901401qtw.8
for <users@dpdk.org>; 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: <CAO8pfF=dMSTb9y+jPyqmphdj++Kz3rsT2suzktUopLcaFY6PQg@mail.gmail.com>
<acc52634-c88a-597a-65bd-21683bac7deb@amd.com>
<20221213163447.14a96ea0@hermes.local>
<CAO8pfFkdR4sSWSbggnehnm44SvnZ0ffF9Wkyprb9mrCqnk4D7A@mail.gmail.com>
In-Reply-To: <CAO8pfFkdR4sSWSbggnehnm44SvnZ0ffF9Wkyprb9mrCqnk4D7A@mail.gmail.com>
From: Pavel Vazharov <freakpv@gmail.com>
Date: Wed, 14 Dec 2022 10:12:35 +0200
Message-ID: <CAK9EM1_0H=44+vH4Uxw4YPcBLUzjdr5E0VOtGZvgzLx7wvjH_w@mail.gmail.com>
Subject: Re: Anonymous structs in DPDK
To: Antonio Di Bacco <a.dibacco.ks@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Ferruh Yigit <ferruh.yigit@amd.com>, 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 <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
<mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
<mailto:users-request@dpdk.org?subject=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 <a.dibacco.ks@gmail.com>
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:
> > > >
> > > > /**
> > > > * 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
<div dir=3D"ltr"><div><div><div><div>Hi,<br><br></div>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?)<br></div>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.<br></div><div><br><=
/div>Regards,<br></div>Pavel.<br></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 14, 2022 at 10:03 AM Antonio D=
i Bacco <<a href=3D"mailto:a.dibacco.ks@gmail.com">a.dibacco.ks@gmail.co=
m</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Hi,<br>
<br>
I need to completely isolate my application from DPDK, I'm building a<b=
r>
C++ library that encapsulates the DPDK in order that the application<br>
doesn't need to include (either directly or indirectly) any DPDK<br>
header file. In the library cpp files I can include rte_spinlock.h but<br>
not in the .hpp files.<br>
<br>
Best regards.<br>
<br>
On Wed, Dec 14, 2022 at 1:34 AM Stephen Hemminger<br>
<<a href=3D"mailto:stephen@networkplumber.org" target=3D"_blank">stephen=
@networkplumber.org</a>> wrote:<br>
><br>
> On Tue, 13 Dec 2022 13:55:10 +0000<br>
> Ferruh Yigit <<a href=3D"mailto:ferruh.yigit@amd.com" target=3D"_bl=
ank">ferruh.yigit@amd.com</a>> wrote:<br>
><br>
> > On 12/13/2022 12:51 PM, Antonio Di Bacco wrote:<br>
> > > I noticed that DPDK include files have a number of anonymous=
/unnamed struct:<br>
> > ><br>
> > > For example:<br>
> > ><br>
> > > /**<br>
> > >=C2=A0 * The rte_spinlock_t type.<br>
> > >=C2=A0 */<br>
> > > typedef struct {<br>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0volatile int locked; /**<=
; lock status 0 =3D unlocked, 1 =3D locked */<br>
> > > } rte_spinlock_t;<br>
> > ><br>
> > > This choice doesn't allow to use forward declaration. I =
need forward<br>
> > > declaration because I'm using a rte_spinlock_t pointer i=
n a C++ class<br>
> > > and I don't want to include rte_spinlock.h to prevent my=
application<br>
> > > to include it as well.<br>
> > ><br>
> > > Is there any reason to use unnamed structures?<br>
> > ><br>
> ><br>
> > Hi Antonio Di,<br>
> ><br>
> > I don't think there is a specific reason to not use named str=
uct, I<br>
> > assume that is only because there was no need to have it.<br>
> ><br>
> > So if you need, you can send a simple patch to convert anonymous =
struct<br>
> > to named struct, although I am not clear why you can't includ=
e<br>
> > 'rte_spinlock.h' in the file you declare your class.<br>
> ><br>
> > Cheers,<br>
> > ferruh<br>
><br>
> Why not include rte_spinlock.h? Spinlocks are meant to be embedded<br>
> in the object using it. Using spinlocks by reference adds more space<b=
r>
> and causes a cache miss.<br>
</blockquote></div>
--0000000000004c313305efc54dd6--