| #
fba98755 |
| 10-Jan-2025 |
Andre Muezerie <andremue@linux.microsoft.com> |
lib: replace packed attributes
MSVC struct packing is not compatible with GCC. Replace macro __rte_packed with __rte_packed_begin to push existing pack value and set packing to 1-byte and macro __rt
lib: replace packed attributes
MSVC struct packing is not compatible with GCC. Replace macro __rte_packed with __rte_packed_begin to push existing pack value and set packing to 1-byte and macro __rte_packed_end to restore the pack value prior to the push.
Macro __rte_packed_end is deliberately utilized to trigger a MSVC compiler warning if no existing packing has been pushed allowing easy identification of locations where the __rte_packed_begin is missing.
Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
show more ...
|
|
Revision tags: v24.11, v24.11-rc4, v24.11-rc3, v24.11-rc2, v24.11-rc1, v24.07, v24.07-rc4, v24.07-rc3, v24.07-rc2, v24.07-rc1, v24.03, v24.03-rc4, v24.03-rc3, v24.03-rc2 |
|
| #
c6552d9a |
| 04-Mar-2024 |
Tyler Retzlaff <roretzla@linux.microsoft.com> |
lib: move alignment attribute on types for MSVC
The current location used for __rte_aligned(a) for alignment of types is not compatible with MSVC. There is only a single location accepted by both to
lib: move alignment attribute on types for MSVC
The current location used for __rte_aligned(a) for alignment of types is not compatible with MSVC. There is only a single location accepted by both toolchains.
The standard offers no alignment facility that compatibly interoperates with C and C++ but it may be achieved by relocating the placement of __rte_aligned(a) to the aforementioned location accepted by all currently supported toolchains.
To allow alignment for both compilers, do the following:
* Expand __rte_aligned(a) to __declspec(align(a)) when building with MSVC.
* Move __rte_aligned from the end of {struct,union} definitions to be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired alignment to be imparted on the type regardless of the toolchain being used for all of GCC, LLVM, MSVC compilers building both C and C++.
Note: this move has an additional benefit as Doxygen is not confused anymore like for the rte_event_vector struct definition.
Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com> Acked-by: Morten Brørup <mb@smartsharesystems.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com> Acked-by: Chengwen Feng <fengchengwen@huawei.com> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com> Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
|
|
Revision tags: v24.03-rc1, v23.11, v23.11-rc4, v23.11-rc3, v23.11-rc2, v23.11-rc1, v23.07, v23.07-rc4, v23.07-rc3, v23.07-rc2, v23.07-rc1, v23.03, v23.03-rc4, v23.03-rc3, v23.03-rc2, v23.03-rc1, v22.11, v22.11-rc4, v22.11-rc3, v22.11-rc2 |
|
| #
7f9cf804 |
| 25-Oct-2022 |
Thomas Monjalon <thomas@monjalon.net> |
net: mark all big endian types
Some protocols (ARP, MPLS and HIGIG2) were using uint16_t and uint32_t types for their 16 and 32-bit fields. It was correct but not conveying the big endian nature of
net: mark all big endian types
Some protocols (ARP, MPLS and HIGIG2) were using uint16_t and uint32_t types for their 16 and 32-bit fields. It was correct but not conveying the big endian nature of these fields.
As for other protocols defined in this directory, all types are explicitly marked as big endian fields.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
show more ...
|
|
Revision tags: v22.11-rc1, v22.07, v22.07-rc4, v22.07-rc3, v22.07-rc2, v22.07-rc1, v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2, v22.03-rc1, v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2, v21.11-rc1 |
|
| #
20ab35d0 |
| 08-Sep-2021 |
Xiao Wang <xiao.w.wang@intel.com> |
net: promote make rarp packet function to stable
rte_net_make_rarp_packet was introduced in version v18.02, there was no change in this public API since then, and it's still being used by vhost lib
net: promote make rarp packet function to stable
rte_net_make_rarp_packet was introduced in version v18.02, there was no change in this public API since then, and it's still being used by vhost lib and virtio driver, so promote it as stable ABI.
Signed-off-by: Xiao Wang <xiao.w.wang@intel.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Chenbo Xia <chenbo.xia@intel.com> Acked-by: Olivier Matz <olivier.matz@6wind.com>
show more ...
|
|
Revision tags: v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1 |
|
| #
99a2dd95 |
| 20-Apr-2021 |
Bruce Richardson <bruce.richardson@intel.com> |
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also m
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also makes it awkward to add features referring to individual libraries in the build - should the lib names be specified with or without the prefix. Therefore, we can just remove the library prefix and use the library's unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
show more ...
|