|
Revision tags: 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 |
|
| #
22c0353a |
| 26-Oct-2023 |
Tyler Retzlaff <roretzla@linux.microsoft.com> |
timer: use stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with corresponding rte_atomic_xxx optional stdatomic API
Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
timer: use stdatomic API
Replace the use of gcc builtin __atomic_xxx intrinsics with corresponding rte_atomic_xxx optional stdatomic API
Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com> Acked-by: David Marchand <david.marchand@redhat.com>
show more ...
|
|
Revision tags: 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, v22.11-rc1 |
|
| #
eb63c85d |
| 14-Sep-2022 |
Naga Harish K S V <s.v.naga.harish.k@intel.com> |
timer: fix stopping all timers
There is a possibility of deadlock in this API, as same spinlock is tried to be acquired in nested manner.
If the lcore that is stopping the timer is different from t
timer: fix stopping all timers
There is a possibility of deadlock in this API, as same spinlock is tried to be acquired in nested manner.
If the lcore that is stopping the timer is different from the lcore that owns the timer, the timer list lock is acquired in timer_del(), even if local_is_locked is true. Because the same lock was already acquired in rte_timer_stop_all(), the thread will hang.
This patch removes the acquisition of nested lock.
Fixes: 821c51267bcd63a ("timer: add function to stop all timers in a list") Cc: stable@dpdk.org
Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com> Acked-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
show more ...
|
|
Revision tags: v22.07, v22.07-rc4, v22.07-rc3, v22.07-rc2 |
|
| #
2237e6da |
| 20-Jun-2022 |
Sean Morrissey <sean.morrissey@intel.com> |
timer: remove unneeded header includes
These header includes have been flagged by the iwyu_tool and removed.
Signed-off-by: Sean Morrissey <sean.morrissey@intel.com>
|
|
Revision tags: v22.07-rc1, v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2 |
|
| #
30a1de10 |
| 15-Feb-2022 |
Sean Morrissey <sean.morrissey@intel.com> |
lib: remove unneeded header includes
These header includes have been flagged by the iwyu_tool and removed.
Signed-off-by: Sean Morrissey <sean.morrissey@intel.com>
|
|
Revision tags: v22.03-rc1, v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2, v21.11-rc1, 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 ...
|