On Thu, Apr 11, 2024 at 10:42 AM Bruce Richardson
wrote:
>
> On Thu, Apr 11, 2024 at 10:30:19AM +0200, David Marchand wrote:
> > On Mon, Apr 8, 2024 at 5:23 PM Bruce Richardson
> > wrote:
> > >
> > > On Fri, Apr 05, 2024 at 04:45:56PM +0200, David Marchand wrote:
> > > > At the moment, if the dri
On Mon, 15 Apr 2024 at 03:37, Xu, HailinX wrote:
>
> > -Original Message-
> > From: luca.bocca...@gmail.com
> > Sent: Thursday, April 4, 2024 7:11 AM
> > To: sta...@dpdk.org
> > Cc: dev@dpdk.org; Abhishek Marathe ;
> > Ali Alnubani ; benjamin.wal...@intel.com; David
> > Christensen ; Hema
On Fri, Apr 12, 2024 at 04:04:12PM -0700, Tyler Retzlaff wrote:
> On Fri, Apr 12, 2024 at 02:00:43PM +0100, Bruce Richardson wrote:
> > On Thu, Mar 14, 2024 at 11:30:21PM -0700, Tyler Retzlaff wrote:
> > > MSVC is the only compiler that can produce usable shared libraries for
> > > DPDK on Windows
Ping.
Thanks
Nithin
On Tue, Feb 20, 2024 at 5:10 PM Nithin Dabilpuram
wrote:
>
> VIRTIO_F_ORDER_PLATFORM is needed feature when working with
> real HW platforms that are exposing virtio-net devices
> via VDPA framework. This feature helps in having more
> real ordering requirements between descr
On Fri, Apr 12, 2024 at 03:52:12PM -0700, Tyler Retzlaff wrote:
> MSVC is the only compiler that can produce usable shared libraries for
> DPDK on Windows because of the use of exported TLS variables.
>
> Disable building of shared libraries with LLVM and MinGW so that
> remaining __declspec macro
On Fri, Apr 12, 2024 at 03:52:13PM -0700, Tyler Retzlaff wrote:
> Use the value of default_library and use it when building deps instead
> of always using static deps so we get the correct static or shared deps.
>
> Signed-off-by: Tyler Retzlaff
> ---
Reviewed-by: Bruce Richardson
This patch adds a new feature to the hash library to allow the user to
reclaim the defer queue. This is useful when the user wants to force
reclaim resources that are not being used. This API is only available
if the RCU is enabled.
Signed-off-by: Abdullah Ömer Yamaç
---
app/test/test_hash.c
The crypto callbacks macro is being used with ifdef instead of if,
so when the config file value is changed to 0 to disable, the code is
still being compiled in.
Fixes: 1c3ffb95595e ("cryptodev: add enqueue and dequeue callbacks")
Cc: abhinandan.guj...@intel.com
Cc: sta...@dpdk.org
Signed-off-by:
> @@ -1701,12 +1696,8 @@ static inline void
> rte_eth_linkstatus_get(const struct rte_eth_dev *dev,
> struct rte_eth_link *link)
> {
> - RTE_ATOMIC(uint64_t) *src = (uint64_t __rte_atomic *)&(dev->data-
> >dev_link);
> - uint64_t *dst = (uint64_t *)link;
> -
> - R
The previous code allowed the number of Tx queues to be set higher than the
number of Rx queues. If a packet was sent on a Tx queue with index
>= number Rx queues there was a segfault due to accessing beyond the end of the
>dev->data->rx_queues[] array.
#0 rte_spinlock_trylock (sl = invalid add
On 4/12/2024 3:44 PM, Morten Brørup wrote:
Mandate use of rte_eth_tx_prepare() in the mbuf Tx checksum
>> offload
examples.
>>>
>>> I strongly disagree with this change!
>>>
>>> It will cause a huge performance degradation for shaping
>> applications:
>>>
>
Add Odyssey ODM DMA device. This PMD abstracts ODM hardware unit on
Odyssey SoC which can perform mem to mem copies.
The hardware unit can support upto 32 queues (vchan) and 16 VFs. It
also supports 'fill' operation with specific values. It also supports
SG mode of operation with upto 4 src pointe
Add support for ODM DMA device in devbind.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
usertools/dpdk-devbind.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-
Add framework for Odyssey ODM DMA device.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
MAINTAINERS | 6 +++
drivers/dma/meson.build | 1 +
drivers/dma/odm/meson.build | 14 +++
drivers/dma/odm/odm.h
Add ODM registers and structures. Add mailbox structs as well.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
drivers/dma/odm/odm.h | 116 +
drivers/dma/odm/odm_priv.h | 49
From: Gowrishankar Muthukrishnan
Add ODM device init and fini.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
drivers/dma/odm/meson.build | 2 +-
drivers/dma/odm/odm.c| 97
drivers/d
From: Gowrishankar Muthukrishnan
Add DMA device control ops.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
drivers/dma/odm/odm.c| 144 ++-
drivers/dma/odm/odm.h| 58 ++
From: Gowrishankar Muthukrishnan
Add DMA dev stats.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
drivers/dma/odm/odm_dmadev.c | 63 ++--
1 file changed, 61 insertions(+), 2 deletions(-)
diff --g
From: Vidya Sagar Velumuri
Add ODM copy and copy SG ops.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
drivers/dma/odm/odm_dmadev.c | 233 +++
1 file changed, 233 insertions(+)
diff --git a/drive
From: Vidya Sagar Velumuri
Add all remaining ops such as fill, burst_capacity etc. Also update the
documentation.
Signed-off-by: Anoob Joseph
Signed-off-by: Gowrishankar Muthukrishnan
Signed-off-by: Vidya Sagar Velumuri
---
MAINTAINERS | 1 +
doc/guides/dmadevs/index.rst |
Use the value of default_library and use it when building deps instead
of always using static deps so we get the correct static or shared deps.
Signed-off-by: Tyler Retzlaff
---
buildtools/chkincs/meson.build | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/buildtools/chk
MSVC is the only compiler that can produce usable shared libraries for
DPDK on Windows because of the use of exported TLS variables.
Disable building of shared libraries with LLVM and MinGW so that
remaining __declspec macros needed for the functional libraries built by
MSVC can be used without tr
MSVC is the only compiler that can produce usable shared libraries for
DPDK on Windows because of the use of exported TLS variables.
Disable building of shared libraries with LLVM and MinGW so that
remaining __declspec macros needed for the functional libraries built by
MSVC can be used without tr
Use the value of default_library and use it when building deps instead
of always using static deps so we get the correct static or shared deps.
Signed-off-by: Tyler Retzlaff
Reviewed-by: Bruce Richardson
---
buildtools/chkincs/meson.build | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(
MSVC is the only compiler that can produce usable shared libraries for
DPDK on Windows because of the use of exported TLS variables.
Disable building of shared libraries with LLVM and MinGW so that
remaining __declspec macros needed for the functional libraries built by
MSVC can be used without tr
MSVC is the only compiler that can produce usable shared libraries for
DPDK on Windows because of the use of exported TLS variables.
Disable building of shared libraries with LLVM and MinGW so that
remaining __declspec macros needed for the functional libraries built by
MSVC can be used without tr
On Mon, Apr 15, 2024 at 10:12:47AM -0700, Tyler Retzlaff wrote:
> MSVC is the only compiler that can produce usable shared libraries for
> DPDK on Windows because of the use of exported TLS variables.
>
> Disable building of shared libraries with LLVM and MinGW so that
> remaining __declspec macro
On 4/12/2024 5:50 PM, Alan Elder wrote:
>
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Friday, April 12, 2024 6:23 AM
>> To: Alan Elder ; Long Li ;
>> Andrew Rybchenko
>> Cc: dev@dpdk.org; stephen
>> Subject: Re: [EXTERNAL] Re: [PATCH v3] net/netvsc: fix number Tx queues > Rx
On 4/15/2024 3:40 PM, Alan Elder wrote:
> The previous code allowed the number of Tx queues to be set higher than the
> number of Rx queues. If a packet was sent on a Tx queue with index
>> = number Rx queues there was a segfault due to accessing beyond the end of
>> the dev->data->rx_queues[] a
With modern CPUs, it is possible to have higher
CPU count thus we can have higher RTE_MAX_LCORES.
In testpmd application, the current config forwarding
cores option "--nb-cores" is hard limited to 255.
The patch fixes this constraint and also adjusts the lcore
data structure to 32-bit to align wit
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
After having established this as the conventional standard for lib/*
this series is intended to convert the remainder of the
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
Move location of __rte_aligned(a) to new conventional location. The new
placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for both C and C++. Additionally, it avoids confusion by Doxygen
when generating docume
1 - 100 of 158 matches
Mail list logo
