> On Tue, 19 Mar 2024 08:52:13 +0530
> Jerin Jacob wrote:
>
> > On Wed, Feb 21, 2024 at 9:43 PM wrote:
> > >
> > > From: Pavan Nikhilesh
> > >
> > > Deprecate rte_node, rte_node_register and rte_graph_cluster_node_stats
> > > structures as will be extended to include node specific error counter
Hi chengwen,
> -Original Message-
> From: fengchengwen
> Sent: Wednesday, March 20, 2024 12:12 PM
> To: Ma, WenwuX ; dev@dpdk.org
> Cc: Jiale, SongX ; sta...@dpdk.org; Pavan Nikhilesh
> ; Thomas Monjalon
> Subject: Re: [PATCH v2] dmadev: fix structure alignment
>
> Hi Wenwu,
>
> On 202
The structure rte_dma_dev needs to be aligned to the cache line, but
the return value of malloc may not be aligned to the cache line. When
we use memset to clear the rte_dma_dev object, it may cause a segmentation
fault in clang-x86-platform.
This is because clang uses the "vmovaps" assembly instr
> Upon a successful comparison, NEON sets all the bits in the lane to 1
> We can skip shifting by simply masking with specific masks.
>
> Signed-off-by: Yoan Picchi
> Reviewed-by: Ruifeng Wang
> Reviewed-by: Nathan Brown
> ---
> lib/hash/arch/arm/compare_signatures.h | 24 +++--
> From: Robin Jarry [mailto:rja...@redhat.com]
> Sent: Tuesday, 19 March 2024 21.39
>
> Hi Vladimir,
>
> Medvedkin, Vladimir, Mar 19, 2024 at 18:16:
[...]
> > > 4) In rte_fib, every IPv4 address (route *and* next hop) needs to be
> > >in host order. This is not consistent with fib6 where ad
Members Attending
=
Aaron Conole
Bruce Richardson
Hemant Agrawal
Honappa Nagarahalli
Jerin Jacob
Kevin Traynor
Konstantin Ananyev
Maxime Coquelin
Morten Brørup (chair)
Stephen Hemminger
Thomas Monjalon
NOTE
The technical board meetings are on every second Wednesday at 3 pm UTC
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, 20 March 2024 04.34
>
> On Tue, 19 Mar 2024 17:13:35 +0100
> Morten Brørup wrote:
>
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Tuesday, 19 March 2024 16.52
> > >
> > > On Tue, 19 M
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, March 20, 2024 2:25 PM
> To: Yan, Zhirun ; dev@dpdk.org
> Cc: jer...@marvell.com; pbhagavat...@marvell.com; sta...@dpdk.org
> Subject: RE: [PATCH] graph: fix head move when graph walk in mcore dispatch
>
>
> > > /*
Reviewed-by: Chengwen Feng
On 2024/3/20 15:23, Wenwu Ma wrote:
> The structure rte_dma_dev needs to be aligned to the cache line, but
> the return value of malloc may not be aligned to the cache line. When
> we use memset to clear the rte_dma_dev object, it may cause a segmentation
> fault in cla
> -Original Message-
> From: Sivaramakrishnan, VenkatX
> Sent: Wednesday, February 28, 2024 9:21 AM
> Cc: dev@dpdk.org; Power, Ciara ; Sivaramakrishnan,
> VenkatX
> Subject: [PATCH v1] doc: update QAT compression doc IDs
>
> Missing GEN2, GEN3 and GEN4 devices updated for the QAT comp
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, February 8, 2024 11:36 AM
> To: Sivaramakrishnan, VenkatX
> Cc: dev@dpdk.org; Power, Ciara
> Subject: Re: [PATCH v4] doc: update guideline for fix commit messages
>
> On 2/8/2024 10:51 AM, Sivaramakrishnan Venkat wrote:
> > M
On 3/20/2024 6:06 AM, Gregory Etelson wrote:
> Hello Ferruh,
>
>>BUT overall how can we catch issues like this in the feature, we don't
>>have a good way to test testpmd flow commands.
>>@Ori, @Gregory, do you have any idea?
>>cc'ed CI mail list too.
>
> We have a tool for unit tests based on the
On 2024-03-19 13:52, Konstantin Ananyev wrote:
Hi Mattias,
Introduce DPDK per-lcore id variables, or lcore variables for short.
An lcore variable has one value for every current and future lcore
id-equipped thread.
The primary use case is for statically allocating
small chunks of often-used
Subject: [PATCH 0/2] introduce PM QoS interface
The system-wide CPU latency QoS limit has a positive impact on the idle
state selection in cpuidle governor.
Linux creates a cpu_dma_latency device under '/dev' directory to obtain the
CPU latency QoS limit on system and s
Add PM QoS request configuration to declease the process resume latency.
Signed-off-by: Huisong Li
---
examples/l3fwd-power/main.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
i
The system-wide CPU latency QoS limit has a positive impact on the idle
state selection in cpuidle governor.
Linux creates a cpu_dma_latency device under '/dev' directory to obtain the
CPU latency QoS limit on system and send the QoS request for userspace.
Please see the PM QoS framework in the fo
20/03/2024 08:23, Wenwu Ma:
> The structure rte_dma_dev needs to be aligned to the cache line, but
> the return value of malloc may not be aligned to the cache line. When
> we use memset to clear the rte_dma_dev object, it may cause a segmentation
> fault in clang-x86-platform.
>
> This is because
18/03/2024 22:26, Damodharam Ammepalli:
> On Mon, Mar 18, 2024 at 7:56 AM Thomas Monjalon wrote:
> >
> > 12/03/2024 08:52, Dengdui Huang:
> > > Some speeds can be achieved with different number of lanes. For example,
> > > 100Gbps can be achieved using two lanes of 50Gbps or four lanes of 25Gbps.
On 2/22/2024 7:35 AM, Thomas Monjalon wrote:
> A new DPDK release candidate is ready for testing:
> https://git.dpdk.org/dpdk/tag/?id=v24.03-rc1
>
> There are 521 new patches in this snapshot.
>
> Release notes:
> https://doc.dpdk.org/guides/rel_notes/release_24_03.html
>
> Highlight
On 3/18/2024 9:26 PM, Damodharam Ammepalli wrote:
> On Mon, Mar 18, 2024 at 7:56 AM Thomas Monjalon wrote:
>>
>> 12/03/2024 08:52, Dengdui Huang:
>>> Some speeds can be achieved with different number of lanes. For example,
>>> 100Gbps can be achieved using two lanes of 50Gbps or four lanes of 25Gb
ELF -> Executable and Linkable Format
Ethernet -> with an uppercase “E”
mark -> 'mark' flow action, no need to capitalise
max -> maximum
XSK -> XDP Socket. XDP (eXpress Data Path)
Signed-off-by: Ferruh Yigit
---
devtools/words-case.txt | 5 +
1 file changed, 5 insertions(+
On Wed, Mar 20, 2024 at 12:40:47PM +, Ferruh Yigit wrote:
> ELF -> Executable and Linkable Format
> Ethernet -> with an uppercase “E”
> mark -> 'mark' flow action, no need to capitalise
> max -> maximum
> XSK -> XDP Socket. XDP (eXpress Data Path)
>
> Signed-off-by: Ferruh Y
On 3/18/2024 8:02 AM, David Marchand wrote:
> I got some report for users that VLAN insertion was not working as the
> only thing they could see in verbose mode was a 0x0800 ethertype even
> though the RTE_MBUF_F_TX_VLAN flag was shown.
>
> Dump the VLAN TCI from mbuf metadata when VLAN insertion
> From: Huisong Li [mailto:lihuis...@huawei.com]
> Sent: Wednesday, 20 March 2024 11.55
>
> The system-wide CPU latency QoS limit has a positive impact on the idle
> state selection in cpuidle governor.
>
> Linux creates a cpu_dma_latency device under '/dev' directory to obtain the
> CPU latency
> >> Introduce DPDK per-lcore id variables, or lcore variables for short.
> >>
> >> An lcore variable has one value for every current and future lcore
> >> id-equipped thread.
> >>
> >> The primary use case is for statically allocating
> >> small chunks of often-used data, which is related logic
On Wed, 20 Mar 2024 09:34:21 +0100
Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, 20 March 2024 04.34
> >
> > On Tue, 19 Mar 2024 17:13:35 +0100
> > Morten Brørup wrote:
> >
> > > > From: Stephen Hemminger [mailto:step...@networkplum
From: Shai Brandes
Fixed an issue of double free of mbufs which is exposed
in mbuf fast free mode when handling multi-mbuf packets.
The faulty patch mishandled free of non-head mbufs as it
iterated over linked mbufs and collected them into an array,
which was then passed to rte_pktmbuf_free_bulk
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
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 219 matches
Mail list logo
