DPDK usage discussions
 help / color / mirror / Atom feed
* Anonymous structs in DPDK
@ 2022-12-13 12:51 Antonio Di Bacco
  2022-12-13 13:55 ` Ferruh Yigit
  0 siblings, 1 reply; 6+ messages in thread
From: Antonio Di Bacco @ 2022-12-13 12:51 UTC (permalink / raw)
  To: users

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?

Thx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Anonymous structs in DPDK
  2022-12-13 12:51 Anonymous structs in DPDK Antonio Di Bacco
@ 2022-12-13 13:55 ` Ferruh Yigit
  2022-12-14  0:34   ` Stephen Hemminger
  0 siblings, 1 reply; 6+ messages in thread
From: Ferruh Yigit @ 2022-12-13 13:55 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: users

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Anonymous structs in DPDK
  2022-12-13 13:55 ` Ferruh Yigit
@ 2022-12-14  0:34   ` Stephen Hemminger
  2022-12-14  8:03     ` Antonio Di Bacco
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2022-12-14  0:34 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Antonio Di Bacco, users

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Anonymous structs in DPDK
  2022-12-14  0:34   ` Stephen Hemminger
@ 2022-12-14  8:03     ` Antonio Di Bacco
  2022-12-14  8:12       ` Pavel Vazharov
  0 siblings, 1 reply; 6+ messages in thread
From: Antonio Di Bacco @ 2022-12-14  8:03 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Ferruh Yigit, users

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Anonymous structs in DPDK
  2022-12-14  8:03     ` Antonio Di Bacco
@ 2022-12-14  8:12       ` Pavel Vazharov
  2022-12-14  8:16         ` Antonio Di Bacco
  0 siblings, 1 reply; 6+ messages in thread
From: Pavel Vazharov @ 2022-12-14  8:12 UTC (permalink / raw)
  To: Antonio Di Bacco; +Cc: Stephen Hemminger, Ferruh Yigit, users

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 3257 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Anonymous structs in DPDK
  2022-12-14  8:12       ` Pavel Vazharov
@ 2022-12-14  8:16         ` Antonio Di Bacco
  0 siblings, 0 replies; 6+ messages in thread
From: Antonio Di Bacco @ 2022-12-14  8:16 UTC (permalink / raw)
  To: Pavel Vazharov; +Cc: Stephen Hemminger, Ferruh Yigit, users

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 <freakpv@gmail.com> 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 <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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-12-14  8:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-13 12:51 Anonymous structs in DPDK Antonio Di Bacco
2022-12-13 13:55 ` Ferruh Yigit
2022-12-14  0:34   ` Stephen Hemminger
2022-12-14  8:03     ` Antonio Di Bacco
2022-12-14  8:12       ` Pavel Vazharov
2022-12-14  8:16         ` Antonio Di Bacco

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).