RE: [PATCH v16 0/4] add support for self monitoring

2024-12-01 Thread Tomasz Duszynski 
>-Original Message-
>From: Tomasz Duszynski 
>Sent: Monday, November 18, 2024 8:37 AM
>To: Tomasz Duszynski 
>Cc: ruifeng.w...@arm.com; bruce.richard...@intel.com; 
>david.march...@redhat.com; dev@dpdk.org;
>Jerin Jacob ; konstantin.v.anan...@yandex.ru; 
>mattias.ronnb...@ericsson.com;
>m...@smartsharesystems.com; roret...@linux.microsoft.com; 
>step...@networkplumber.org;
>tho...@monjalon.net; zhou...@loongson.cn
>Subject: [PATCH v16 0/4] add support for self monitoring
>
>This series adds self monitoring support i.e allows to configure and read 
>performance measurement
>unit (PMU) counters in runtime without using perf utility. This has certain 
>advantages when
>application runs on isolated cores running dedicated tasks.
>
>Events can be read directly using rte_pmu_read() or using dedicated tracepoint
>rte_eal_trace_pmu_read(). The latter will cause events to be stored inside CTF 
>file.
>
>By design, all enabled events are grouped together and the same group is 
>attached to lcores that
>use self monitoring funtionality.
>
>Events are enabled by names, which need to be read from standard location 
>under sysfs i.e
>
>/sys/bus/event_source/devices/PMU/events
>
>where PMU is a core pmu i.e one measuring cpu events. As of today raw events 
>are not supported.
>
>v16:
>- fix build issue related to ALLOW_EXPERIMENTAL_API not always defined
>- rename tracepoints upfront to make it easier to decouple for tracing
>- minor doc improvements
>- make sure non EAL threads can't read PMU
>v15:
>- add some basic logs related to API failures
>- get rid of thread-local-storage
>- do not support MT-safety (which was buggy anyway) in management APIs 
>(rte_pmu_init(),
>  rte_pmu_fini(), rte_pmu_add_{event,events_by_pattern}() as it impacts 
> rte_pmu_read()
>  performance because more logic needs to be incorporated to handle all corner 
> cases
>- improve documentation slightly
>- various other improvements here and there
>v14:
>- replace __atomic_xxx with rte_atomic_xxx
>- rebase to dpdk/main since that's a new feature
>v13:
>- allow init/fini calling from multiple contexts
>- get rid of conditional compilation and return erors in case APIs are
>  used on unsupported OS
>v12:
>- rebase old series
>- slightly refresh existing documentation
>- make sure compiler won't optimize accesses to certain variables during
>  event readout
>- drop previous Acked-by to respin a fresh review cycle
>v11:
>- skip fast test in case init fails
>v10:
>- check permissions before using counters
>- do not use internal symbols in exported functions
>- address review comments
>v9:
>- fix 'maybe-uninitialized' warning reported by CI
>v8:
>- just rebase series
>v7:
>- use per-lcore event group instead of global table index by lcore-id
>- don't add pmu_autotest to fast tests because due to lack of suported
>  on every arch
>v6:
>- move codebase to the separate library
>- address review comments
>v5:
>- address review comments
>- fix sign extension while reading pmu on x86
>- fix regex mentioned in doc
>- various minor changes/improvements here and there
>v4:
>- fix freeing mem detected by debug_autotest
>v3:
>- fix shared build
>v2:
>- fix problems reported by test build infra
>
>Tomasz Duszynski (4):
>  lib: add generic support for reading PMU events
>  pmu: support reading ARM PMU events in runtime
>  pmu: support reading Intel x86_64 PMU events in runtime
>  eal: add PMU support to tracing library
>
> MAINTAINERS  |   5 +
> app/test/meson.build |   1 +
> app/test/test_pmu.c  |  55 +++
> app/test/test_trace_perf.c   |  10 +
> doc/api/doxy-api-index.md|   3 +-
> doc/api/doxy-api.conf.in |   1 +
> doc/guides/prog_guide/profile_app.rst|  31 ++
> doc/guides/prog_guide/trace_lib.rst  |  32 ++
> doc/guides/rel_notes/release_24_11.rst   |   7 +
> lib/eal/common/eal_common_trace.c|   5 +-
> lib/eal/common/eal_common_trace_pmu.c|  38 ++
> lib/eal/common/eal_common_trace_points.c |   5 +
> lib/eal/common/eal_trace.h   |   4 +
> lib/eal/common/meson.build   |   1 +
> lib/eal/include/rte_eal_trace.h  |  11 +
> lib/eal/meson.build  |   3 +
> lib/eal/version.map  |   1 +
> lib/meson.build  |   1 +
> lib/pmu/meson.build  |  22 +
> lib/pmu/pmu_arm64.c  |  94 
> lib/pmu/pmu_private.h|  32 ++
> lib/pmu/rte_pmu.c| 536 +++
> lib/pmu/rte_pmu.h| 250 +++
> lib/pmu/rte_pmu_pmc_arm64.h  |  30 ++
> lib/pmu/rte_pmu_pmc_x86_64.h |  24 +
> lib/pmu/version.map  |  15 +
> 26 files changed, 1215 insertions(+), 2 deletions(-)  create mode 100644 
> app/test/test_pmu.c
>create mode 100644 lib/eal/common/eal_common_trace_pmu.c
> create mode 100644 lib/pmu/meson.buil

[PATCH v3] doc: reword glossary

2024-12-01 Thread Nandini Persad 
I added additional reference links and definitions to many
of the terms in the glossary. Please feel free to provide
feedback to ensure my definitions suit the proper context
in the DPDK community.

Signed-off-by: Nandini Persad 
---
 doc/guides/prog_guide/glossary.rst | 120 -
 1 file changed, 84 insertions(+), 36 deletions(-)

diff --git a/doc/guides/prog_guide/glossary.rst 
b/doc/guides/prog_guide/glossary.rst
index 8d6349701e..d832d4c0be 100644
--- a/doc/guides/prog_guide/glossary.rst
+++ b/doc/guides/prog_guide/glossary.rst
@@ -6,70 +6,90 @@ Glossary
 
 
 ACL
-   Access Control List
+   An `access control list (ACL) 
`_
+   is a set of rules that define who can access a resource and what actions 
they can perform.
 
 API
Application Programming Interface
 
 ASLR
-   Linux* kernel Address-Space Layout Randomization
+   `Address-Space Layout Randomization (ASLR) 
`_
+   is a computer security technique that protects against buffer overflow 
attacks by randomizing the location of
+   executables in memory.
 
 BSD
-   Berkeley Software Distribution
+   `Berkeley Software Distribution (BSD) 
`_
+   is an version of Unix™ operating system.
 
 Clr
Clear
 
 CIDR
-   Classless Inter-Domain Routing
+   `Classless Inter-Domain Routing (CIDR) 
`_
+   is a method of assigning IP address that improves data routing efficiency 
on the internet and is used in IPv4 and IPv6.
 
 Control Plane
-   The control plane is concerned with the routing of packets and with
-   providing a start or end point.
+   A `Control Plane `_ is a 
concept in networking that refers to the part of the system
+   responsible for managing and making decisions about where and how data 
packets are forwarded within a network.
 
 Core
A core may include several lcores or threads if the processor supports
-   hyperthreading.
+   `simultaneous multithreading (SMT) 
`_
 
 Core Components
-   A set of libraries provided by the DPDK, including eal, ring, mempool,
-   mbuf, timers, and so on.
+   A set of libraries provided by DPDK which are used by nearly all 
applications and
+   upon which other DPDK libraries and drivers depend. For example, eal, ring, 
mempool and mbuf.
 
 CPU
Central Processing Unit
 
 CRC
Cyclic Redundancy Check
+   An algorithm that detects errors in data transmission and storage.
 
 Data Plane
-   In contrast to the control plane, the data plane in a network architecture
-   are the layers involved when forwarding packets.  These layers must be
-   highly optimized to achieve good performance.
+   In contrast to the control plane, which is responsible for setting up and 
managing data connections,
+   the `data plane `_ in a network 
architecture includes the
+   layers involved when processing and forwarding data packets between 
communicating endpoints.
+   These layers must be highly optimized to achieve good performance.
 
 DIMM
Dual In-line Memory Module
+   A module containing one or several Random Access Memory (RAM) or Dynamic 
RAM (DRAM) chips on a printed
+   circuit board that connect it directly to the computer motherboard.
 
 Doxygen
-   A documentation generator used in the DPDK to generate the API reference.
+   `Doxygen `_ is a
+   documentation generator used in the DPDK to generate the API reference.
 
 DPDK
Data Plane Development Kit
 
 DRAM
-   Dynamic Random Access Memory
+   `Dynamic Random Access Memory 
`_
+   is  type of random access memory (RAM) that is used in computers to 
temporarily store information.
 
 EAL
-   The Environment Abstraction Layer (EAL) provides a generic interface that
-   hides the environment specifics from the applications and libraries.  The
-   services expected from the EAL are: development kit loading and launching,
-   core affinity/ assignment procedures, system memory allocation/description,
-   PCI bus access, inter-partition communication.
+   :doc:`Environment Abstraction Layer (EAL) `
+   is a the core DPDK library that provides a generic interface
+   that hides the environment specifics from the applications and libraries.
+   The services expected from the EAL are: loading and launching, core 
management,
+   memory allocation, bus management, and inter-partition communication.
+
+EAL Thread
+   An EAL thread is typically a thread that runs packet processing tasks. 
These threads are often
+   pinned to logical cores (lcores), which helps to ensure that packet 
processing tasks are executed with
+   minimal interruption and maximal performance by utilizing speci

[PATCH] examples/ipsec-secgw: fix cryptodev and eventdev ID

2024-12-01 Thread Tejasree Kondoj 
Fixing cryptodev and eventdev ID numbers.

Fixes: 0dbe550a4af5 ("examples/ipsec-secgw: initialize event crypto adapter")
Cc: sta...@dpdk.org

Signed-off-by: Tejasree Kondoj 
---
 examples/ipsec-secgw/event_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ipsec-secgw/event_helper.c 
b/examples/ipsec-secgw/event_helper.c
index 89fb7e62a5..5d8ce4df0b 100644
--- a/examples/ipsec-secgw/event_helper.c
+++ b/examples/ipsec-secgw/event_helper.c
@@ -881,7 +881,7 @@ eh_initialize_crypto_adapter(struct eventmode_conf *em_conf)
}
 
/* Add crypto queue pairs to event crypto adapter */
-   ret = rte_event_crypto_adapter_queue_pair_add(cdev_id, 
eventdev_id,
+   ret = rte_event_crypto_adapter_queue_pair_add(eventdev_id, 
cdev_id,
-1, /* adds all the pre configured queue pairs 
to the instance */
&queue_conf);
if (ret < 0) {
-- 
2.25.1

[DPDK/core Bug 1590] rte_ipv6_phdr_cksum users wrong proto

2024-12-01 Thread bugzilla 
https://bugs.dpdk.org/show_bug.cgi?id=1590

Bug ID: 1590
   Summary: rte_ipv6_phdr_cksum users wrong proto
   Product: DPDK
   Version: 20.11
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: maa...@mail.ru
  Target Milestone: ---

It seems rte_ipv6_phdr_cksum implementation uses wrong proto field for
pseudo-header during calculating checksum:

static inline uint16_t
rte_ipv6_phdr_cksum(const struct rte_ipv6_hdr *ipv6_hdr, uint64_t ol_flags)
{
uint32_t sum;
struct {
rte_be32_t len;   /* L4 length. */
rte_be32_t proto; /* L4 protocol - top 3 bytes must be zero */
} psd_hdr;

psd_hdr.proto = (uint32_t)(ipv6_hdr->proto << 24);
if (ol_flags & PKT_TX_TCP_SEG) {
psd_hdr.len = 0;
} else {
psd_hdr.len = ipv6_hdr->payload_len;
}

sum = __rte_raw_cksum(ipv6_hdr->src_addr,
sizeof(ipv6_hdr->src_addr) + sizeof(ipv6_hdr->dst_addr),
0);
sum = __rte_raw_cksum(&psd_hdr, sizeof(psd_hdr), sum);
return __rte_raw_cksum_reduce(sum);
}

proto is taken directly from the header while RFC 8200 clearly states:

The Next Header value in the pseudo-header identifies the upper-layer protocol
(e.g., 6 for TCP or 17 for UDP).  It will differ from the Next Header value in
the IPv6 header if there are extension headers between the IPv6 header and the
upper-layer header.

see https://www.rfc-editor.org/rfc/rfc8200

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [PATCH dpdk] log: fix double free on cleanup

2024-12-01 Thread Robin Jarry 

Stephen Hemminger, Nov 29, 2024 at 17:54:

On Fri, 29 Nov 2024 17:10:14 +0100
Robin Jarry  wrote:


@@ -550,11 +555,8 @@ eal_log_init(const char *id)
 void
 rte_eal_log_cleanup(void)
 {
-   FILE *log_stream = rte_logs.file;
-
-   /* don't close stderr on the application */
-   if (log_stream != NULL)
-   fclose(log_stream);
-
+   if (rte_logs.is_internal_file && rte_logs.file != NULL)
+   fclose(rte_logs.file);
rte_logs.file = NULL;
+   rte_logs.is_internal_file = false;
 }


The internal flag is ok, but we still don't want to close
stderr in cleanup. Only places where syslog or journal wrapper is used.


There is no chance closing stderr will happen with my patch. stderr is 
only returned by rte_log_get_stream() when rte_logs.file is NULL, but 
rte_logs.file is not modified. It is only modified in eal_log_init() 
when --syslog or when running with journald. In both these cases, a new 
file is opened, not stderr.