https://bugs.dpdk.org/show_bug.cgi?id=1436
Bug ID: 1436
Summary: DPDK20.11.9 runs failure on intel atom cpu
Product: DPDK
Version: 20.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
On Sun, 5 May 2024 22:42:57 +0300
Abdullah Ömer Yamaç wrote:
> > Also, this looks wrong. The initialized arrays looked better before.
> >
> >
> > -static const char *tuntap_types[ETH_TUNTAP_TYPE_MAX] = {
> > - "UNKNOWN", "TUN", "TAP"
> > -};
> > +static const char *tuntap_types[ETH_TUNTAP_
On Sun, May 5, 2024 at 7:21 PM Stephen Hemminger
wrote:
> On Sat, 4 May 2024 19:18:37 +
> Abdullah Ömer Yamaç wrote:
>
> > clang-format is a tool to format C/C++/Objective-C code. It can be used
> > to reformat code to match a given coding style, or to ensure that code
> > adheres to a spec
On Sun, May 5, 2024 at 7:18 PM Stephen Hemminger
wrote:
> On Sat, 4 May 2024 19:18:37 +
> Abdullah Ömer Yamaç wrote:
>
> > clang-format is a tool to format C/C++/Objective-C code. It can be used
> > to reformat code to match a given coding style, or to ensure that code
> > adheres to a spec
This commit adds legacy algorithms flag to the qat_device
struct. This will allow handling this flag within the device
itself, and not using the global variable.
Signed-off-by: Arkadiusz Kusztal
---
v2:
- added session parameters handling
drivers/common/qat/qat_common.h | 9 ++
On Sat, 4 May 2024 19:18:37 +
Abdullah Ömer Yamaç wrote:
> clang-format is a tool to format C/C++/Objective-C code. It can be used
> to reformat code to match a given coding style, or to ensure that code
> adheres to a specific coding style. It helps to maintain a consistent
> coding style a
On Sat, 4 May 2024 19:18:37 +
Abdullah Ömer Yamaç wrote:
> clang-format is a tool to format C/C++/Objective-C code. It can be used
> to reformat code to match a given coding style, or to ensure that code
> adheres to a specific coding style. It helps to maintain a consistent
> coding style a
On Sun, 5 May 2024 13:09:42 +0600
Fuji Nafiul wrote:
> I have a DPDK-enabled port (Linux server) that serves around 5,000-50,000
> concurrent calls, per packet size of 80 bytes to 200 bytes. so in peak
> time, I require packet capture + file writing speed of around 1GByte/s or 8
> Gbit/sec (at le
2024-05-05 03:25 (UTC+), Lombardo, Ed:
> Hi Dmitry,
> I tried your settings tonight and the application VIRT memory is now 7.9G and
> is in the ball park, you are amazing.
>
> #define RTE_MAX_MEMSEG_LISTS 2
> #define RTE_MAX_MEMSEG_PER_LIST 1024
> #define RTE_MAX_MEM_MB_PER_LIST 2048
> #defin
Extend bitops tests to cover the rte_bit_atomic_*() family of
functions.
RFC v4:
* Add atomicity test for atomic bit flip.
RFC v3:
* Rename variable 'main' to make ICC happy.
Signed-off-by: Mattias Rönnblom
Acked-by: Morten Brørup
Acked-by: Tyler Retzlaff
---
app/test/test_bitops.c | 315 +
Add atomic bit test/set/clear/assign/flip and
test-and-set/clear/assign/flip functions.
All atomic bit functions allow (and indeed, require) the caller to
specify a memory order.
RFC v7:
* Replace compare-exchange-based rte_bitset_atomic_test_and_*() and
flip() with implementations that use t
Extend bitops tests to cover the rte_bit_once_*() family of functions.
RFC v5:
* Atomic bit op implementation moved from this patch to the proper
patch in the series. (Morten Brørup)
RFC v4:
* Remove redundant continuations.
Signed-off-by: Mattias Rönnblom
Acked-by: Morten Brørup
Acked-by
Add test/set/clear/assign/flip functions which prevents certain
compiler optimizations and guarantees that program-level memory loads
and/or stores will actually occur.
These functions are useful when interacting with memory-mapped
hardware devices.
The "once" family of functions does not promise
Extend bitops tests to cover the
rte_bit_[test|set|clear|assign|flip]()
functions.
The tests are converted to use the test suite runner framework.
RFC v6:
* Test rte_bit_*test() usage through const pointers.
RFC v4:
* Remove redundant line continuations.
Signed-off-by: Mattias Rönnblom
Acked
Add functionality to test and modify the value of individual bits in
32-bit or 64-bit words.
These functions have no implications on memory ordering, atomicity and
does not use volatile and thus does not prevent any compiler
optimizations.
RFC v6:
* Have rte_bit_test() accept const-marked bitset
This patch set represent an attempt to improve and extend the RTE
bitops API, in particular for functions that operate on individual
bits.
All new functionality is exposed to the user as generic selection
macros, delegating the actual work to private (__-marked) static
inline functions. Public fun
Use a multi-word bitset to track which services are mapped to which
lcores, allowing the RTE_SERVICE_NUM_MAX compile-time constant to be >
64.
Replace array-of-bytes service-currently-active flags with a more
compact multi-word bitset-based representation, reducing memory
footprint somewhat.
Sign
To reduce flow migration overhead, replace the array-based
representation of which set of ports are bound to a particular queue
by a multi-word bitset.
Signed-off-by: Mattias Rönnblom
---
drivers/event/dsw/dsw_evdev.c | 19 +++
drivers/event/dsw/dsw_evdev.h | 3 ++-
drivers/even
Introduce a set of functions and macros that operate on sets of bits,
kept in arrays of 64-bit words.
RTE bitset is designed for bitsets which are larger than what fits in
a single machine word (i.e., 64 bits). For very large bitsets, the
API may be a more appropriate choice.
Depends-on: series-
Add test suite to exercise .
RFC v5:
* Parameterize tests to allow reuse across both atomic and non-atomic
functions.
RFC v4:
* Fix signed char issue in test cases. (Stephen Hemminger)
* Add test cases for logic operations.
* Use the unit test suite runner helper.
Signed-off-by: Mattias R
Extend bitset tests to cover the basic operation of the
rte_bitset_atomic_*() family of functions.
Signed-off-by: Mattias Rönnblom
---
app/test/test_bitset.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/app/test/test_bitset.c b/app/test/test_bit
Extend the bitset API with atomic versions of the most basic bitset
operations.
Signed-off-by: Mattias Rönnblom
---
lib/eal/include/rte_bitset.h | 155 +++
1 file changed, 155 insertions(+)
diff --git a/lib/eal/include/rte_bitset.h b/lib/eal/include/rte_bitset.h
I have a DPDK-enabled port (Linux server) that serves around 5,000-50,000
concurrent calls, per packet size of 80 bytes to 200 bytes. so in peak
time, I require packet capture + file writing speed of around 1GByte/s or 8
Gbit/sec (at least 0.5Gbyte/s is expected). dpdk official packet capture
examp
23 matches
Mail list logo
