Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
On Thu, Apr 13, 2023 at 7:51 PM Tummala, Sivaprasad
wrote:
>
> [AMD Official Use Only - General]
>
> Hi David,
>
> > -Original Message-
> > From: David Marchand
> > Sent: Thursday, April 13, 2023 5:30 PM
> > To: Tummala, Sivaprasad
> > Cc: david.h...@intel.com; dev@dpdk.org; Thomas Monjalon
> > ; Burakov, Anatoly
> > Subject: Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Thu, Apr 13, 2023 at 1:54 PM Sivaprasad Tummala
> > wrote:
> > >
> > > Add a new CPUID flag to indicate support for monitorx instruction on
> > > AMD Epyc processors.
> > >
> > > Signed-off-by: Sivaprasad Tummala
> > > ---
> > > lib/eal/include/generic/rte_cpuflags.h | 2 ++
> > > lib/eal/x86/include/rte_cpuflags.h | 1 +
> > > lib/eal/x86/rte_cpuflags.c | 3 +++
> > > 3 files changed, 6 insertions(+)
> > >
> > > diff --git a/lib/eal/include/generic/rte_cpuflags.h
> > > b/lib/eal/include/generic/rte_cpuflags.h
> > > index d35551e931..db653a8dd7 100644
> > > --- a/lib/eal/include/generic/rte_cpuflags.h
> > > +++ b/lib/eal/include/generic/rte_cpuflags.h
> > > @@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
> > > /**< indicates support for rte_power_pause function */
> > > uint32_t power_monitor_multi : 1;
> > > /**< indicates support for rte_power_monitor_multi function */
> > > + uint32_t amd_power_monitorx : 1;
> > > + /**< indicates amd support for rte_power_monitor function */
> >
> > I did not look at the patch detail, I just stopped at this part.
> > What makes the AMD monitorx stuff special that it needs to be exposed in the
> > generic API?
>
> Monitorx is different ISA /opcode (0F 01 FA) as compared to UMonitor (0F 01
> C8). This need to be distinguished
> on specific x86 platforms. Hence in the current power intrinsics, for x86 we
> require a new flag to
> distinguish MonitorX and UMonitor and invoke the appropriate x86 ISA in the
> datapath.
Requiring a new x86 cpuflag to identify this ISA presence is ok.
But here, I am talking about the generic power instrinsic API.
Let me phrase my comment differently...
As described in the API:
uint32_t power_monitor : 1;
/**< indicates support for rte_power_monitor function */
Does AMD thing behave completely different from the x86?
Looking at patch 3, I understand this is not the case.
So we don't need a "amd" flag in the generic flags.
The indirection for calling the right ISA should be hidden in
rte_power_* helpers implemented for x86.
--
David Marchand
Re: [PATCH] usertools: add tool to generate balanced rss traffic flows
13/04/2023 22:30, Robin Jarry:
> From: 6WIND
I don't remember drinking a beer with grumly.
Maybe it is not his real name?
> usage: dpdk-rss-flows.py [-h] [-s SPORT_RANGE] [-d DPORT_RANGE] [-r]
> [-k RSS_KEY] [-t RETA_SIZE] [-j]
> RX_QUEUES SRC DST
>
> Craft IP{v6}/{TCP/UDP} traffic flows that will evenly spread over a
> given number of RX queues according to the RSS algorithm.
>
> positional arguments:
> RX_QUEUES The number of RX queues to fill.
> SRC The source IP network/address.
> DST The destination IP network/address.
>
> options:
> -h, --helpshow this help message and exit
> -s SPORT_RANGE, --sport-range SPORT_RANGE
> The layer 4 (TCP/UDP) source port range. Can
> be a single fixed value or a range
> -.
> -d DPORT_RANGE, --dport-range DPORT_RANGE
> The layer 4 (TCP/UDP) destination port range.
> Can be a single fixed value or a range
> -.
> -r, --check-reverse-traffic
> The reversed traffic (source <-> dest) should
> also be evenly balanced in the queues.
> -k RSS_KEY, --rss-key RSS_KEY
> The random key byte-stream used to compute the
> RSS hash. This option supports either a
> supported driver name or the hex value of the
> key (default: intel).
> -t RETA_SIZE, --reta-size RETA_SIZE
> Size of the redirection table or "RETA"
> (default: 128).
> -j, --jsonOutput in parseable JSON format.
How do you parse the JSON format?
Is there a tool able to use this table and generate the traffic?
Re: [PATCH] usertools: add tool to generate balanced rss traffic flows
Thomas Monjalon, Apr 14, 2023 at 09:23: > I don't remember drinking a beer with grumly. > Maybe it is not his real name? Here he is with his co-worker, le poulpe. He was on a call with a customer: https://diabeteman.com/grumly-et-le-poulpe-de-ntf.jpg > How do you parse the JSON format? > Is there a tool able to use this table and generate the traffic? I guess you can parse it with any JSON parser. Then, you could write a simple python script that would generate a T-Rex traffic profile which is in python as well.
Re: 20.11.8 patches review and test
Hi Luca, RedHat QE does not find new issues about the v20.11.8-rc1 dpdk during the tests. We tested below 18 scenarios and all got PASS on RHEL9: - Guest with device assignment(PF) throughput testing(1G hugepage size): PASS - Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS - Guest with device assignment(VF) throughput testing: PASS - PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS - PVP vhost-user 2Q throughput testing: PASS - PVP vhost-user 1Q - cross numa node throughput testing: PASS - Guest with vhost-user 2 queues throughput testing: PASS - vhost-user reconnect with dpdk-client, qemu-server qemu reconnect: PASS - vhost-user reconnect with dpdk-client, qemu-server ovs reconnect: PASS - PVP reconnect with dpdk-client, qemu-server: PASS - PVP 1Q live migration testing: PASS - PVP 1Q cross numa node live migration testing: PASS - Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS - Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS - Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS - Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS - Host PF + DPDK testing: PASS - Host VF + DPDK testing: PASS Test Versions: - qemu-kvm-6.2.0 - kernel 5.14 - v20.11.8 dpdk # git log commit f18508a65db3305faf335376754d052eb4e640fb (tag: v20.11.8-rc1) Author: Luca Boccassi Date: Fri Mar 31 19:15:02 2023 +0100 version: 20.11.8-rc1 Signed-off-by: Luca Boccassi - Test device : X540-AT2 NIC(ixgbe, 10G) Best Regards, YangHang Liu On Wed, Apr 12, 2023 at 11:15 PM Ali Alnubani wrote: > > -Original Message- > > From: luca.bocca...@gmail.com > > Sent: Friday, March 31, 2023 9:20 PM > > To: sta...@dpdk.org > > Cc: dev@dpdk.org; Abhishek Marathe ; > > Ali Alnubani ; benjamin.wal...@intel.com; David > > Christensen ; Hemant Agrawal > > ; Ian Stokes ; Jerin > > Jacob ; John McNamara ; > > Ju-Hyoung Lee ; Kevin Traynor > > ; Luca Boccassi ; Pei Zhang > > ; qian.q...@intel.com; Raslan Darawsheh > > ; NBU-Contact-Thomas Monjalon (EXTERNAL) > > ; Yanghang Liu ; > > yuan.p...@intel.com; zhaoyan.c...@intel.com > > Subject: 20.11.8 patches review and test > > > > Hi all, > > > > Here is a list of patches targeted for stable release 20.11.8. > > > > The planned date for the final release is April 17th. > > > > Please help with testing and validation of your use cases and report > > any issues/results with reply-all to this mail. For the final release > > the fixes and reported validations will be added to the release notes. > > > > A release candidate tarball can be found at: > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.8-rc1 > > > > These patches are located at branch 20.11 of dpdk-stable repo: > > https://dpdk.org/browse/dpdk-stable/ > > > > Thanks. > > > > Luca Boccassi > > > > --- > > Hello, > > We ran the following functional tests with Nvidia hardware on v20.11.8-rc1: > - Basic functionality: > Send and receive multiple types of traffic. > - testpmd xstats counter test. > - testpmd timestamp test. > - Changing/checking link status through testpmd. > - rte_flow tests. > - Some RSS tests. > - VLAN filtering, stripping and insertion tests. > - Checksum and TSO tests. > - ptype tests. > - link_status_interrupt example application tests. > - l3fwd-power example application tests. > - Multi-process example applications tests. > - Hardware LRO tests. > > Functional tests ran on: > - NIC: ConnectX-6 Dx / OS: Ubuntu 20.04 / Driver: > MLNX_OFED_LINUX-5.9-0.5.6.0 / Firmware: 22.36.1010 > - NIC: ConnectX-7 / OS: Ubuntu 20.04 / Driver: MLNX_OFED_LINUX-5.9-0.5.6.0 > / Firmware: 22.36.1010 > - DPU: BlueField-2 / DOCA SW version: 1.5.1 / Firmware: 24.35.2000 > > Additionally, we ran compilation tests with multiple configurations in the > following OS/driver combinations: > - Ubuntu 20.04.5 with MLNX_OFED_LINUX-5.9-0.5.6.0. > - Ubuntu 20.04.5 with rdma-core master (f0a079f). > - Ubuntu 20.04.5 with rdma-core v28.0. > - Ubuntu 18.04.6 with rdma-core v17.1. > - Ubuntu 18.04.6 with rdma-core master (f0a079f) (i386). > - Fedora 37 with rdma-core v41.0. > - Fedora 39 (Rawhide) with rdma-core v44.0. > - CentOS 7 7.9.2009 with rdma-core master (f0a079f). > - CentOS 7 7.9.2009 with MLNX_OFED_LINUX-5.9-0.5.6.0. > - CentOS 8 8.4.2105 with rdma-core master (f0a079f). > - OpenSUSE Leap 15.4 with rdma-core v38.1. > - Windows Server 2019 with Clang 11.0.0. > > We don't see new issues caused by the changes in this release. > > Please note that not all the functional tests mentioned above fall under > "Basic functionality with testpmd" like reported in the release notes for > previous releases: > > https://git.dpdk.org/dpdk-stable/commit/?h=v20.11.7&id=62865fef48cb93042e8b9f85821eb02e1031e8f0 > Some of them test other applications. > > Thanks, > Ali >
[PATCH] bitmap: add scan init at given position
Currently, in the case when we search for a bit set after a particular
value, the bitmap has to be scanned from the beginning and
rte_bitmap_scan() has to be called multiple times until we hit the value.
Add a new __rte_bitmap_scan_init_at() function to initialize scan state at
the given position, this will allow getting the next bit set after some
value within one rte_bitmap_scan() call.
Signed-off-by: Volodymyr Fialko
---
app/test/test_bitmap.c | 23 +++
lib/eal/include/rte_bitmap.h | 22 ++
2 files changed, 45 insertions(+)
diff --git a/app/test/test_bitmap.c b/app/test/test_bitmap.c
index e9c61590ae..69ff7262f3 100644
--- a/app/test/test_bitmap.c
+++ b/app/test/test_bitmap.c
@@ -71,6 +71,29 @@ test_bitmap_scan_operations(struct rte_bitmap *bmp)
return TEST_FAILED;
}
+ /* Scan reset with count check. */
+ __rte_bitmap_scan_init_at(bmp, pos + RTE_BITMAP_SLAB_BIT_SIZE);
+ if (!rte_bitmap_scan(bmp, &pos, &out_slab)) {
+ printf("Failed to get slab from bitmap.\n");
+ return TEST_FAILED;
+ }
+
+ if (slab2_magic != out_slab) {
+ printf("Scan init at operation failed.\n");
+ return TEST_FAILED;
+ }
+
+ __rte_bitmap_scan_init_at(bmp, pos + 2 * RTE_BITMAP_SLAB_BIT_SIZE);
+ if (!rte_bitmap_scan(bmp, &pos, &out_slab)) {
+ printf("Failed to get slab from bitmap.\n");
+ return TEST_FAILED;
+ }
+
+ if (slab1_magic != out_slab) {
+ printf("Scan init at operation failed.\n");
+ return TEST_FAILED;
+ }
+
/* Test scan when a cline is half full */
rte_bitmap_reset(bmp);
for (i = 0; i < MAX_BITS; i++)
diff --git a/lib/eal/include/rte_bitmap.h b/lib/eal/include/rte_bitmap.h
index 27ee3d18a4..54a986aa8f 100644
--- a/lib/eal/include/rte_bitmap.h
+++ b/lib/eal/include/rte_bitmap.h
@@ -137,6 +137,28 @@ __rte_bitmap_scan_init(struct rte_bitmap *bmp)
bmp->go2 = 0;
}
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Bitmap initialize internal scan pointers at the given position for the scan
function.
+ * @see rte_bitmap_scan()
+ *
+ * @param bmp
+ * Handle to bitmap instance
+ * @param pos
+ * Bit position to start scan
+ */
+__rte_experimental
+static inline void
+__rte_bitmap_scan_init_at(struct rte_bitmap *bmp, uint32_t pos)
+{
+ bmp->index1 = pos >> (RTE_BITMAP_SLAB_BIT_SIZE_LOG2 +
RTE_BITMAP_CL_BIT_SIZE_LOG2);
+ bmp->offset1 = (pos >> RTE_BITMAP_CL_BIT_SIZE_LOG2) &
RTE_BITMAP_SLAB_BIT_MASK;
+ bmp->index2 = pos >> RTE_BITMAP_SLAB_BIT_SIZE_LOG2;
+ bmp->go2 = 1;
+}
+
/**
* Bitmap memory footprint calculation
*
--
2.34.1
[PATCH] reorder: improve buffer structure layout
Rearrange the reorder buffer structure to prevent padding to extra one
cache line.
Current layout:
struct rte_reorder_buffer {
char name[RTE_REORDER_NAMESIZE];
uint32_t min_seqn;
unsigned int memsize;
// -> padding to cache align (cir_buffer is also cache aligned)
struct cir_buffer ready_buf;
struct cir_buffer order_buf;
int is_initialized;
// -> padding to cache align, eat whole line
};
New layout:
struct rte_reorder_buffer {
char name[RTE_REORDER_NAMESIZE];
uint32_t min_seqn;
unsigned int memsize;
int is_initialized;
// -> padding to cache align (cir_buffer is also cache aligned)
struct cir_buffer ready_buf;
struct cir_buffer order_buf;
// -> no padding
};
Signed-off-by: Volodymyr Fialko
---
lib/reorder/rte_reorder.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
index f55f383700..7418202b04 100644
--- a/lib/reorder/rte_reorder.c
+++ b/lib/reorder/rte_reorder.c
@@ -46,9 +46,10 @@ struct rte_reorder_buffer {
char name[RTE_REORDER_NAMESIZE];
uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
unsigned int memsize; /**< memory area size of reorder buffer */
+ int is_initialized; /**< flag indicates that buffer was initialized */
+
struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
struct cir_buffer order_buf; /**< buffer used to reorder entries */
- int is_initialized;
} __rte_cache_aligned;
static void
--
2.34.1
RE: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
[AMD Official Use Only - General]
> -Original Message-
> From: David Marchand
> Sent: Friday, April 14, 2023 12:36 PM
> To: Tummala, Sivaprasad
> Cc: david.h...@intel.com; dev@dpdk.org; Thomas Monjalon
> ; Burakov, Anatoly
> Subject: Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Apr 13, 2023 at 7:51 PM Tummala, Sivaprasad
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Hi David,
> >
> > > -Original Message-
> > > From: David Marchand
> > > Sent: Thursday, April 13, 2023 5:30 PM
> > > To: Tummala, Sivaprasad
> > > Cc: david.h...@intel.com; dev@dpdk.org; Thomas Monjalon
> > > ; Burakov, Anatoly
> > > Subject: Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Thu, Apr 13, 2023 at 1:54 PM Sivaprasad Tummala
> > > wrote:
> > > >
> > > > Add a new CPUID flag to indicate support for monitorx instruction
> > > > on AMD Epyc processors.
> > > >
> > > > Signed-off-by: Sivaprasad Tummala
> > > > ---
> > > > lib/eal/include/generic/rte_cpuflags.h | 2 ++
> > > > lib/eal/x86/include/rte_cpuflags.h | 1 +
> > > > lib/eal/x86/rte_cpuflags.c | 3 +++
> > > > 3 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/lib/eal/include/generic/rte_cpuflags.h
> > > > b/lib/eal/include/generic/rte_cpuflags.h
> > > > index d35551e931..db653a8dd7 100644
> > > > --- a/lib/eal/include/generic/rte_cpuflags.h
> > > > +++ b/lib/eal/include/generic/rte_cpuflags.h
> > > > @@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
> > > > /**< indicates support for rte_power_pause function */
> > > > uint32_t power_monitor_multi : 1;
> > > > /**< indicates support for rte_power_monitor_multi
> > > > function */
> > > > + uint32_t amd_power_monitorx : 1;
> > > > + /**< indicates amd support for rte_power_monitor function
> > > > + */
> > >
> > > I did not look at the patch detail, I just stopped at this part.
> > > What makes the AMD monitorx stuff special that it needs to be
> > > exposed in the generic API?
> >
> > Monitorx is different ISA /opcode (0F 01 FA) as compared to UMonitor
> > (0F 01 C8). This need to be distinguished on specific x86 platforms.
> > Hence in the current power intrinsics, for x86 we require a new flag to
> > distinguish
> MonitorX and UMonitor and invoke the appropriate x86 ISA in the datapath.
>
> Requiring a new x86 cpuflag to identify this ISA presence is ok.
>
>
> But here, I am talking about the generic power instrinsic API.
> Let me phrase my comment differently...
>
> As described in the API:
> uint32_t power_monitor : 1;
> /**< indicates support for rte_power_monitor function */
>
> Does AMD thing behave completely different from the x86?
> Looking at patch 3, I understand this is not the case.
>
> So we don't need a "amd" flag in the generic flags.
> The indirection for calling the right ISA should be hidden in
> rte_power_* helpers implemented for x86.
>
Thanks for your feedback. I will fix this and send an updated patch.
[PATCH] reorder: introduce API to obtain memory footprint
At present, it is not easy to determine the memory requirement for the
reorder buffer without delving into its implementation details.
To facilitate the use of reorder buffer with user allocation, a new API
`rte_reorder_memory_footprint_get()` is introduced.
This API will provide the amount of required memory for reorder buffer.
Signed-off-by: Volodymyr Fialko
---
app/test/test_reorder.c | 8
lib/reorder/rte_reorder.c | 13 +
lib/reorder/rte_reorder.h | 16
lib/reorder/version.map | 2 ++
4 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/app/test/test_reorder.c b/app/test/test_reorder.c
index f391597a78..6daa913ef9 100644
--- a/app/test/test_reorder.c
+++ b/app/test/test_reorder.c
@@ -68,12 +68,12 @@ test_reorder_init(void)
struct rte_reorder_buffer *b = NULL;
unsigned int size;
/*
-* The minimum memory area size that should be passed to library is,
-* sizeof(struct rte_reorder_buffer) + (2 * size * sizeof(struct
rte_mbuf *));
+* The minimum memory area size that should be passed to library
determined
+* by rte_reorder_memory_footprint_get().
* Otherwise error will be thrown
*/
- size = 100;
+ size = rte_reorder_memory_footprint_get(REORDER_BUFFER_SIZE) - 1;
b = rte_reorder_init(b, size, "PKT1", REORDER_BUFFER_SIZE);
TEST_ASSERT((b == NULL) && (rte_errno == EINVAL),
"No error on init with NULL buffer.");
@@ -84,7 +84,7 @@ test_reorder_init(void)
"No error on init with invalid mem zone size.");
rte_free(b);
- size = 262336;
+ size = rte_reorder_memory_footprint_get(REORDER_BUFFER_SIZE);
b = rte_malloc(NULL, size, 0);
b = rte_reorder_init(b, size, "PKT1", REORDER_BUFFER_SIZE_INVALID);
TEST_ASSERT((b == NULL) && (rte_errno == EINVAL),
diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
index 66d2cc07b7..f55f383700 100644
--- a/lib/reorder/rte_reorder.c
+++ b/lib/reorder/rte_reorder.c
@@ -54,12 +54,17 @@ struct rte_reorder_buffer {
static void
rte_reorder_free_mbufs(struct rte_reorder_buffer *b);
+unsigned int
+rte_reorder_memory_footprint_get(unsigned int size)
+{
+ return sizeof(struct rte_reorder_buffer) + (2 * size * sizeof(struct
rte_mbuf *));
+}
+
struct rte_reorder_buffer *
rte_reorder_init(struct rte_reorder_buffer *b, unsigned int bufsize,
const char *name, unsigned int size)
{
- const unsigned int min_bufsize = sizeof(*b) +
- (2 * size * sizeof(struct rte_mbuf *));
+ const unsigned int min_bufsize = rte_reorder_memory_footprint_get(size);
static const struct rte_mbuf_dynfield reorder_seqn_dynfield_desc = {
.name = RTE_REORDER_SEQN_DYNFIELD_NAME,
.size = sizeof(rte_reorder_seqn_t),
@@ -148,8 +153,8 @@ rte_reorder_create(const char *name, unsigned socket_id,
unsigned int size)
{
struct rte_reorder_buffer *b = NULL;
struct rte_tailq_entry *te, *te_inserted;
- const unsigned int bufsize = sizeof(struct rte_reorder_buffer) +
- (2 * size * sizeof(struct rte_mbuf *));
+
+ const unsigned int bufsize = rte_reorder_memory_footprint_get(size);
/* Check user arguments. */
if (!rte_is_power_of_2(size)) {
diff --git a/lib/reorder/rte_reorder.h b/lib/reorder/rte_reorder.h
index 9a5998f2f6..16dc4ee400 100644
--- a/lib/reorder/rte_reorder.h
+++ b/lib/reorder/rte_reorder.h
@@ -212,6 +212,22 @@ __rte_experimental
unsigned int
rte_reorder_min_seqn_set(struct rte_reorder_buffer *b, rte_reorder_seqn_t
min_seqn);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Determine the amount of memory needed by the reorder buffer to accommodate
a given number of
+ * elements. @see rte_reorder_init()
+ *
+ * @param size
+ * Number of elements that can be stored in reorder buffer.
+ * @return
+ * Reorder buffer footprint measured in bytes.
+ */
+__rte_experimental
+unsigned int
+rte_reorder_memory_footprint_get(unsigned int size);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/reorder/version.map b/lib/reorder/version.map
index e21b91f526..7ff6a622f4 100644
--- a/lib/reorder/version.map
+++ b/lib/reorder/version.map
@@ -19,4 +19,6 @@ EXPERIMENTAL {
# added in 23.03
rte_reorder_drain_up_to_seqn;
rte_reorder_min_seqn_set;
+ # added in 23.07
+ rte_reorder_memory_footprint_get;
};
--
2.34.1
Minutes of Technical Board Meeting, 2023-April-22
Minutes of Technical Board Meeting, 2023-March-05 Members Attending - -Bruce -Hemant -Honnappa -Jerin -Kevin -Konstantin (Chair) -Stephen NOTE: The technical board meetings every second Wednesday at https://meet.jit.si/DPDK at 3 pm UTC. Meetings are public, and DPDK community members are welcome to attend. NOTE: Next meeting will be on Wednesday 2023-April-19 @3pm UTC, and will be chaired by Maxime. 1) Marketing update (Nathan) - Welcome to Ben Thomas - new Marketing coordinator for DPDK. - Self-introduction from Ben and brief outline for hist initial plans. 2) Tech writer hiring update (Nathan) - Got GB approval for candidate that seems to fullfill all the major requirements. - Initial contract for 6 months (30 hours per week) with ability to renewal. - First task to concentrate on - GSG re-work (initial estimation ~3/4 weeks). - TB members (Bruce,Aaron, Thomas) will track his work. 3) Event planning (Nathan) - the survey was distributed around to estimate event turnaround. There is a lack of participants so far, ask to the whole community to provide your input as soon as you can. 4) bonding and PTP naming - Stephen expressed his plans to replace all non-inclusive namings in DPDK code-base. For that he is workinng with DPDK maintainers to provider a proper naming replacements. Plus the intention is to sumbit a patches for coding guideness and devtools to help detect/avoid non-inclusive wordings in future updates. No major objections from TB members to this activity. In particular, about new names for bonding PMD - there is no new common naming (nearly every vendor uses its own verion). Current most favourable variant within DPDK community: "bond/members". 5) bnx2x removal - As there is EOL for related devices, Marvell confirmed the plans to remove bnx2x PMDs from DPDK code-base. The intention is to remove it either in 23.07 or 23.11 releases. No final deadline was decided. 6) process for new library approval in principle - Draft documnet was submitted by Jerin more then a month ago. So far only Thomas submitted his comments about the document. Ask for other TB members to participate in review, provide their comments and/or formal ACK. 7) direct-rearm/buffer-recycle patch - in previous mails Ferruh expressed some concerns regarding that feature and requested explicit approval and code review from techboard to proceed. During the discussion, it was pointed that: - this feature can provide a noticable perfomance improvent and is totally optional to use. - it was reworked siginificantly to be generic enough and avoid implicit restrictions to the user. Furhter discussion was postponed due to luck of opinions from TB members and absence of Ferruh. The ask for next meeting: - invite Ferruh to participate the discussion. - Honnappa to prepare brief summary about proposed feature. 8) bugzilla usage - No futher discussion due to absense of main stakeholders.
RE: [PATCH] net/gve: Check whether the driver is compatible with the device presented.
Hi Ferruh,
Here is the summary of the dependency of related patches:
P1: necessary headers update
https://patchwork.dpdk.org/project/dpdk/list/?series=27647&state=*
P2: minor update for base code
https://patchwork.dpdk.org/project/dpdk/list/?series=27653&state=*
P3: gve PMD enhancement
https://patchwork.dpdk.org/project/dpdk/list/?series=27687&state=*
P4: add new AdminQ cmd to verify drv cap
https://patchwork.dpdk.org/project/dpdk/list/?series=27703&state=*
The merging order could be: P1 > P2 > P3 > P4, due to the dependency.
Just to inform you about this here. Thanks for the review!
Regards,
Junfeng
> -Original Message-
> From: Rushil Gupta
> Sent: Friday, April 14, 2023 13:15
> To: ferruh.yi...@amd.com; Zhang, Qi Z ; Wu,
> Jingjing
> Cc: Guo, Junfeng ; joshw...@google.com;
> dev@dpdk.org; Rushil Gupta ; Jeroen de Borst
>
> Subject: [PATCH] net/gve: Check whether the driver is compatible with
> the device presented.
>
> Change gve_driver_info fields to report DPDK as OS type and DPDK RTE
> version as OS version, reserving driver_version fields for GVE driver
> version based on features.
>
> This patch is dependent on
> https://patchwork.dpdk.org/project/dpdk/list/?series=27687&state=*
>
> Signed-off-by: Rushil Gupta
> Signed-off-by: Joshua Washington
> Signed-off-by: Junfeng Guo
> Signed-off-by: Jeroen de Borst
> ---
> drivers/net/gve/base/gve.h| 3 --
> drivers/net/gve/base/gve_adminq.c | 19 +
> drivers/net/gve/base/gve_adminq.h | 49 ++-
> drivers/net/gve/base/gve_osdep.h | 36 +
> drivers/net/gve/gve_ethdev.c | 65 +-
> -
> drivers/net/gve/gve_ethdev.h | 2 +-
> drivers/net/gve/gve_version.c | 14 +++
> drivers/net/gve/gve_version.h | 25
> drivers/net/gve/meson.build | 1 +
> 9 files changed, 198 insertions(+), 16 deletions(-)
> create mode 100644 drivers/net/gve/gve_version.c
> create mode 100644 drivers/net/gve/gve_version.h
>
> diff --git a/drivers/net/gve/base/gve.h b/drivers/net/gve/base/gve.h
> index 2dc4507acb..89f9654a72 100644
> --- a/drivers/net/gve/base/gve.h
> +++ b/drivers/net/gve/base/gve.h
> @@ -8,9 +8,6 @@
>
> #include "gve_desc.h"
>
> -#define GVE_VERSION "1.3.0"
> -#define GVE_VERSION_PREFIX "GVE-"
> -
> #ifndef GOOGLE_VENDOR_ID
> #define GOOGLE_VENDOR_ID 0x1ae0
> #endif
> diff --git a/drivers/net/gve/base/gve_adminq.c
> b/drivers/net/gve/base/gve_adminq.c
> index e745b709b2..2e5099a5b0 100644
> --- a/drivers/net/gve/base/gve_adminq.c
> +++ b/drivers/net/gve/base/gve_adminq.c
> @@ -401,6 +401,9 @@ static int gve_adminq_issue_cmd(struct gve_priv
> *priv,
> case GVE_ADMINQ_GET_PTYPE_MAP:
> priv->adminq_get_ptype_map_cnt++;
> break;
> + case GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY:
> + priv->adminq_verify_driver_compatibility_cnt++;
> + break;
> default:
> PMD_DRV_LOG(ERR, "unknown AQ command
> opcode %d", opcode);
> }
> @@ -465,6 +468,22 @@ int
> gve_adminq_configure_device_resources(struct gve_priv *priv,
> return gve_adminq_execute_cmd(priv, &cmd);
> }
>
> +int gve_adminq_verify_driver_compatibility(struct gve_priv *priv,
> +u64 driver_info_len,
> +dma_addr_t driver_info_addr)
> +{
> + union gve_adminq_command cmd;
> +
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.opcode =
> cpu_to_be32(GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY);
> + cmd.verify_driver_compatibility = (struct
> gve_adminq_verify_driver_compatibility) {
> + .driver_info_len = cpu_to_be64(driver_info_len),
> + .driver_info_addr = cpu_to_be64(driver_info_addr),
> + };
> +
> + return gve_adminq_execute_cmd(priv, &cmd);
> +}
> +
> int gve_adminq_deconfigure_device_resources(struct gve_priv *priv)
> {
> union gve_adminq_command cmd;
> diff --git a/drivers/net/gve/base/gve_adminq.h
> b/drivers/net/gve/base/gve_adminq.h
> index 05550119de..edac32f031 100644
> --- a/drivers/net/gve/base/gve_adminq.h
> +++ b/drivers/net/gve/base/gve_adminq.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: MIT
> * Google Virtual Ethernet (gve) driver
> - * Copyright (C) 2015-2022 Google, Inc.
> + * Copyright (C) 2015-2023 Google, Inc.
> */
>
> #ifndef _GVE_ADMINQ_H
> @@ -23,6 +23,7 @@ enum gve_adminq_opcodes {
> GVE_ADMINQ_REPORT_STATS = 0xC,
> GVE_ADMINQ_REPORT_LINK_SPEED= 0xD,
> GVE_ADMINQ_GET_PTYPE_MAP= 0xE,
> + GVE_ADMINQ_VERIFY_DRIVER_COMPATIBILITY = 0xF,
> };
>
> /* Admin queue status codes */
> @@ -145,6 +146,47 @@ enum gve_sup_feature_mask {
> };
>
> #define GVE_DEV_OPT_LEN_GQI_RAW_ADDRESSING 0x0
> +enum gve_driver_capbility {
> + gve_driver_capability_gqi_qpl = 0,
> + gve_driver_capability_gqi_rda = 1,
> + gve_driver_capability_dqo_qpl = 2,
Re: Regarding DPDK API's like rte_timer_subsystem_init/rte_hash_create etc. in VPP
On Fri, Apr 14, 2023 at 09:55:31AM +0530, Prashant Upadhyaya wrote: > On Fri, Mar 31, 2023 at 4:19 PM Bruce Richardson > wrote: > > > > On Fri, Mar 31, 2023 at 03:11:18PM +0530, Prashant Upadhyaya wrote: > > > On Thu, Mar 30, 2023 at 7:34 PM Bruce Richardson > > > wrote: > > > > > > > > On Thu, Mar 30, 2023 at 07:07:23PM +0530, Prashant Upadhyaya wrote: > > > > > On Thu, Mar 30, 2023 at 6:47 PM Bruce Richardson > > > > > wrote: > > > > > > > > > > > > On Thu, Mar 30, 2023 at 06:42:58PM +0530, Prashant Upadhyaya wrote: > > > > > > > On Thu, Mar 30, 2023 at 2:50 PM Bruce Richardson > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 01:57:52PM +0530, Prashant Upadhyaya > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > FYI, when replying on list, it's best not to top-post, but put > > > > > > > > your replies > > > > > > > > below the email snippet you are replying to. > > > > > > > > > > > > > > > > > The hash creation API throws the following error -- > > > > > > > > > RING: Cannot reserve memory for tailq > > > > > > > > > HASH: memory allocation failed > > > > > > > > > > > > > > > > > > The timer subsystem init api throws this error -- > > > > > > > > > EAL: memzone_reserve_aligned_thread_unsafe(): Number of > > > > > > > > > requested > > > > > > > > > memzone segments exceeds RTE_MAX_MEMZONE > > > > > > > > > > > > > > > > > > > > > > > > > Can you try increasing RTE_MAX_MEMZONE. It' defined in DPDK's > > > > > > > > rte_config.h > > > > > > > > file, so edit that and then rebuild DPDK. [If you are using the > > > > > > > > built-in > > > > > > > > DPDK from VPP, you may need to do a patch for this, add it into > > > > > > > > the VPP > > > > > > > > patches direction and then do a VPP rebuild.] > > > > > > > > > > > > > > > > Let's see if we can get rid of at least one of the error > > > > > > > > messages. :-) > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > > > > > > > > > I did check the code and apparently the memzone and rte > > > > > > > > > zmalloc > > > > > > > > > related api's are not being able to allocate memory. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > -Prashant > > > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 1:30 PM Bruce Richardson > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 10:30:24AM +0530, Prashant > > > > > > > > > > Upadhyaya wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > While trying to port some code to VPP (which uses DPDK as > > > > > > > > > > > the backend > > > > > > > > > > > driver), I am running into a problem that calls to API's > > > > > > > > > > > like > > > > > > > > > > > rte_timer_subsystem_init, rte_hash_create are failing > > > > > > > > > > > while allocation > > > > > > > > > > > of memory. > > > > > > > > > > > > > > > > > > > > > > This is presumably because VPP inits the EAL with the > > > > > > > > > > > following arguments -- > > > > > > > > > > > > > > > > > > > > > > -in-memory --no-telemetry --file-prefix vpp > > > > > > > > > > > > > > > > > > > > > > Is there is something that can be done eg. passing some > > > > > > > > > > > more parms in > > > > > > > > > > > the EAL initialization which hopefully wouldn't break VPP > > > > > > > > > > > but will > > > > > > > > > > > also be friendly to the RTE timer and hash functions too, > > > > > > > > > > > that would > > > > > > > > > > > be great, so requesting some advice here. > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > can you provide some more details on what the errors are > > > > > > > > > > that you are > > > > > > > > > > receiving? Have you been able to dig a little deeper into > > > > > > > > > > what might be > > > > > > > > > > causing the memory failures? The above flags alone are > > > > > > > > > > unlikely to cause > > > > > > > > > > issues with hash or timer libraries, for example. > > > > > > > > > > > > > > > > > > > > /Bruce > > > > > > > > > > > > > > Thanks Bruce, the error comes from the following function in > > > > > > > lib/eal/common/eal_common_memzone.c > > > > > > > memzone_reserve_aligned_thread_unsafe > > > > > > > > > > > > > > The condition which spits out the error is the following > > > > > > > if (arr->count >= arr->len) > > > > > > > So I printed both of the above values inside this function, and > > > > > > > the > > > > > > > following output came > > > > > > > > > > > > > > vpp[14728]: dpdk: EAL init args: --in-memory --no-telemetry > > > > > > > --file-prefix vpp > > > > > > > [New Thread 0x7fffa67b6700 (LWP 14732)] > > > > > > > count: 0 len: 2560 > > > > > > > count: 1 len: 2560 > > > > > > > count: 2 len: 2560 > > > > > > > [New Thread 0x7fffa5fb5700 (LWP 14733)] > > > > > > > [New Thread 0x7fffa5db4700 (LWP 14734)] > > > > > > > count: 3 len: 2560 > > > > > > > count: 4 len: 2560 > > > > > > > ### this is the pl
Re: [PATCH v5 06/14] eal: use prefetch intrinsics
On Thu, Apr 13, 2023 at 02:25:55PM -0700, Tyler Retzlaff wrote: > Inline assembly is not supported for MSVC x64 instead use _mm_prefetch > and _mm_cldemote intrinsics. > > Signed-off-by: Tyler Retzlaff > --- Acked-by: Bruce Richardson
[PATCH v2] dmadev: add tracepoints
Add tracepoints at important APIs for tracing support.
Signed-off-by: Chengwen Feng
---
v2: Address Morten's comment:
Make stats_get as fast-path trace-points.
Place fast-path trace-point functions behind in version.map.
---
lib/dmadev/meson.build | 2 +-
lib/dmadev/rte_dmadev.c | 39 ++--
lib/dmadev/rte_dmadev.h | 56 ---
lib/dmadev/rte_dmadev_trace.h| 136 +++
lib/dmadev/rte_dmadev_trace_fp.h | 113 ++
lib/dmadev/rte_dmadev_trace_points.c | 59
lib/dmadev/version.map | 10 ++
7 files changed, 394 insertions(+), 21 deletions(-)
create mode 100644 lib/dmadev/rte_dmadev_trace.h
create mode 100644 lib/dmadev/rte_dmadev_trace_fp.h
create mode 100644 lib/dmadev/rte_dmadev_trace_points.c
diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
index 2f17587b75..e0d90aea67 100644
--- a/lib/dmadev/meson.build
+++ b/lib/dmadev/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2021 HiSilicon Limited.
-sources = files('rte_dmadev.c')
+sources = files('rte_dmadev.c', 'rte_dmadev_trace_points.c')
headers = files('rte_dmadev.h')
indirect_headers += files('rte_dmadev_core.h')
driver_sdk_headers += files('rte_dmadev_pmd.h')
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 8c095e1f35..25fa78de8f 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -17,6 +17,7 @@
#include "rte_dmadev.h"
#include "rte_dmadev_pmd.h"
+#include "rte_dmadev_trace.h"
static int16_t dma_devices_max;
@@ -434,6 +435,8 @@ rte_dma_info_get(int16_t dev_id, struct rte_dma_info
*dev_info)
dev_info->numa_node = dev->device->numa_node;
dev_info->nb_vchans = dev->data->dev_conf.nb_vchans;
+ rte_dma_trace_info_get(dev_id, dev_info);
+
return 0;
}
@@ -483,6 +486,8 @@ rte_dma_configure(int16_t dev_id, const struct rte_dma_conf
*dev_conf)
memcpy(&dev->data->dev_conf, dev_conf,
sizeof(struct rte_dma_conf));
+ rte_dma_trace_configure(dev_id, dev_conf, ret);
+
return ret;
}
@@ -509,6 +514,7 @@ rte_dma_start(int16_t dev_id)
goto mark_started;
ret = (*dev->dev_ops->dev_start)(dev);
+ rte_dma_trace_start(dev_id, ret);
if (ret != 0)
return ret;
@@ -535,6 +541,7 @@ rte_dma_stop(int16_t dev_id)
goto mark_stopped;
ret = (*dev->dev_ops->dev_stop)(dev);
+ rte_dma_trace_stop(dev_id, ret);
if (ret != 0)
return ret;
@@ -565,6 +572,8 @@ rte_dma_close(int16_t dev_id)
if (ret == 0)
dma_release(dev);
+ rte_dma_trace_close(dev_id, ret);
+
return ret;
}
@@ -655,14 +664,18 @@ rte_dma_vchan_setup(int16_t dev_id, uint16_t vchan,
if (*dev->dev_ops->vchan_setup == NULL)
return -ENOTSUP;
- return (*dev->dev_ops->vchan_setup)(dev, vchan, conf,
+ ret = (*dev->dev_ops->vchan_setup)(dev, vchan, conf,
sizeof(struct rte_dma_vchan_conf));
+ rte_dma_trace_vchan_setup(dev_id, vchan, conf, ret);
+
+ return ret;
}
int
rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct rte_dma_stats *stats)
{
const struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(dev_id) || stats == NULL)
return -EINVAL;
@@ -677,14 +690,18 @@ rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct
rte_dma_stats *stats)
if (*dev->dev_ops->stats_get == NULL)
return -ENOTSUP;
memset(stats, 0, sizeof(struct rte_dma_stats));
- return (*dev->dev_ops->stats_get)(dev, vchan, stats,
- sizeof(struct rte_dma_stats));
+ ret = (*dev->dev_ops->stats_get)(dev, vchan, stats,
+sizeof(struct rte_dma_stats));
+ rte_dma_trace_stats_get(dev_id, vchan, stats, ret);
+
+ return ret;
}
int
rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
{
struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
@@ -698,13 +715,17 @@ rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
if (*dev->dev_ops->stats_reset == NULL)
return -ENOTSUP;
- return (*dev->dev_ops->stats_reset)(dev, vchan);
+ ret = (*dev->dev_ops->stats_reset)(dev, vchan);
+ rte_dma_trace_stats_reset(dev_id, vchan, ret);
+
+ return ret;
}
int
rte_dma_vchan_status(int16_t dev_id, uint16_t vchan, enum rte_dma_vchan_status
*status)
{
struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
@@ -716,7 +737,10 @@ rte_dma_vchan_status(int16_t dev_id, uint16_t vcha
Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC
On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > Sent: Thursday, 13 April 2023 23.26 > > > > For now expand a lot of common rte macros empty. The catch here is we > > need to test that most of the macros do what they should but at the same > > time they are blocking work needed to bootstrap of the unit tests. > > > > Later we will return and provide (where possible) expansions that work > > correctly for msvc and where not possible provide some alternate macros > > to achieve the same outcome. > > > > Signed-off-by: Tyler Retzlaff > > --- > > lib/eal/include/rte_branch_prediction.h | 8 ++ > > lib/eal/include/rte_common.h| 45 > > + > > lib/eal/include/rte_compat.h| 20 +++ > > 3 files changed, 73 insertions(+) > > > > diff --git a/lib/eal/include/rte_branch_prediction.h > > b/lib/eal/include/rte_branch_prediction.h > > index 0256a9d..d9a0224 100644 > > --- a/lib/eal/include/rte_branch_prediction.h > > +++ b/lib/eal/include/rte_branch_prediction.h > > @@ -25,7 +25,11 @@ > > * > > */ > > #ifndef likely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define likely(x) __builtin_expect(!!(x), 1) > > +#else > > +#define likely(x) (x) > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), > and likely() must return Boolean (0 or 1). > Will this really make a difference? Is there somewhere likely/unlikely would be used where we would not get the same conversion to boolean than we get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just wondering if there are actual cases where it affects the output?] > > +#endif > > #endif /* likely */ > > > > /** > > @@ -39,7 +43,11 @@ > > * > > */ > > #ifndef unlikely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define unlikely(x)__builtin_expect(!!(x), 0) > > +#else > > +#define unlikely(x)(x) > > This must also be (!!(x)), for the same reason as above. > > > +#endif > > #endif /* unlikely */ > > > > #ifdef __cplusplus > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h > > index 2f464e3..1bdaa2d 100644 > > --- a/lib/eal/include/rte_common.h > > +++ b/lib/eal/include/rte_common.h > > @@ -65,7 +65,11 @@ > > /** > > * Force alignment > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > +#else > > +#define __rte_aligned(a) > > +#endif > > It should be reviewed that __rte_aligned() is only used for optimization > purposes, and is not required for DPDK to function properly. > Good point. If we look across all of DPDK, things will likely break, as we are relying on alignment in various places to use the aligned versions of instructions. For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86 vectorized driver code. A "git grep _load_si" shows quite a few aligned vector load instructions used in our codebase. These will fault and cause a crash if the data is not properly aligned. [I suspect that there are similar restrictions on other architectures too, just not familiar with their intrinsics to check.] However, it may be that none of the code paths where these are used is in code currently compiled on windows, so this may be safe for now. The occurances are mostly in drivers. $ git grep -l _load_si drivers/common/idpf/idpf_common_rxtx_avx512.c drivers/event/dlb2/dlb2.c drivers/net/bnxt/bnxt_rxtx_vec_avx2.c drivers/net/bnxt/bnxt_rxtx_vec_sse.c drivers/net/enic/enic_rxtx_vec_avx2.c drivers/net/i40e/i40e_rxtx_vec_avx2.c drivers/net/i40e/i40e_rxtx_vec_avx512.c drivers/net/iavf/iavf_rxtx_vec_avx2.c drivers/net/iavf/iavf_rxtx_vec_avx512.c drivers/net/iavf/iavf_rxtx_vec_sse.c drivers/net/ice/ice_rxtx_vec_avx2.c drivers/net/ice/ice_rxtx_vec_avx512.c drivers/net/ice/ice_rxtx_vec_sse.c drivers/net/mlx5/mlx5_rxtx_vec_sse.h lib/acl/acl_bld.c lib/distributor/rte_distributor_match_sse.c lib/efd/rte_efd_x86.h lib/hash/rte_cuckoo_hash.c lib/member/rte_member_x86.h lib/net/net_crc_avx512.c lib/net/net_crc_sse.c > > > > #ifdef RTE_ARCH_STRICT_ALIGN > > typedef uint64_t unaligned_uint64_t __rte_aligned(1); > > @@ -80,16 +84,29 @@ > > /** > > * Force a structure to be packed > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_packed __attribute__((__packed__)) > > +#else > > +#define __rte_packed > > +#endif > > Similar comment as for __rte_aligned(); however, I consider it more likely > that structure packing is a functional requirement, and not just used for > optimization. Based on my experience, it may be used for packing network > structures; perhaps not in DPDK itself but maybe in DPDK applications. > +1 Once libraries such as the net library in DPDK will form part of the windows build this will need to be addressed or things will break. > The same risk applies to __rte_aligned(), but with lower probability. > /Bruce
Re: [PATCH] reorder: improve buffer structure layout
On Fri, Apr 14, 2023 at 10:43:43AM +0200, Volodymyr Fialko wrote:
> Rearrange the reorder buffer structure to prevent padding to extra one
> cache line.
>
> Current layout:
> struct rte_reorder_buffer {
> char name[RTE_REORDER_NAMESIZE];
> uint32_t min_seqn;
> unsigned int memsize;
> // -> padding to cache align (cir_buffer is also cache aligned)
> struct cir_buffer ready_buf;
> struct cir_buffer order_buf;
> int is_initialized;
> // -> padding to cache align, eat whole line
> };
>
> New layout:
> struct rte_reorder_buffer {
> char name[RTE_REORDER_NAMESIZE];
> uint32_t min_seqn;
> unsigned int memsize;
> int is_initialized;
> // -> padding to cache align (cir_buffer is also cache aligned)
> struct cir_buffer ready_buf;
> struct cir_buffer order_buf;
> // -> no padding
> };
>
> Signed-off-by: Volodymyr Fialko
> ---
Acked-by: Bruce Richardson
> lib/reorder/rte_reorder.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
> index f55f383700..7418202b04 100644
> --- a/lib/reorder/rte_reorder.c
> +++ b/lib/reorder/rte_reorder.c
> @@ -46,9 +46,10 @@ struct rte_reorder_buffer {
> char name[RTE_REORDER_NAMESIZE];
> uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
> unsigned int memsize; /**< memory area size of reorder buffer */
> + int is_initialized; /**< flag indicates that buffer was initialized */
> +
Since we are moving it, it might be an opportunity to change it from "int"
to "bool".
> struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
> struct cir_buffer order_buf; /**< buffer used to reorder entries */
> - int is_initialized;
> } __rte_cache_aligned;
>
> static void
> --
> 2.34.1
>
Re: 20.11.8 patches review and test
On Tue, 11 Apr 2023 at 06:17, Xu, HailinX wrote: > > > -Original Message- > > From: Xu, HailinX > > Sent: Thursday, April 6, 2023 3:19 PM > > To: luca.bocca...@gmail.com; sta...@dpdk.org > > Cc: dev@dpdk.org; Abhishek Marathe ; > > Ali Alnubani ; Walker, Benjamin > > ; David Christensen ; > > Hemant Agrawal ; Stokes, Ian > > ; Jerin Jacob ; Mcnamara, John > > ; Ju-Hyoung Lee ; Kevin > > Traynor ; Luca Boccassi ; Pei > > Zhang ; Xu, Qian Q ; Raslan > > Darawsheh ; Thomas Monjalon > > ; Yanghang Liu ; Peng, Yuan > > ; Chen, Zhaoyan > > Subject: RE: 20.11.8 patches review and test > > > > Update the test status for Intel part. Till now dpdk20.11.8-rc1 validation > > test > > rate is 80%. No critical issue is found. > > 2 new bugs are found, These 2 issues are being confirmed by Intel Dev. > > New bugs: > > bug1. softnic and metering_and_policing: create rule failed -- Intel dev > > is > > under investigating. > > bug2. some of the unit tests are failing: -- Intel dev is under > > investigating # > > Basic Intel(R) NIC testing > > * Build & CFLAG compile: cover the build test combination with latest > > GCC/Clang version and the popular OS revision such as Ubuntu20.04, Fedora36, > > RHEL8.4, etc. > > - All test done. No new dpdk issue is found. > > * PF(i40e, ixgbe): test scenarios including > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > - Execution rate is 80%. No new dpdk issue is found. > > * VF(i40e, ixgbe): test scenarios including > > VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > - All test done. No new dpdk issue is found. > > * PF/VF(ice): test scenarios including Switch features/Package > > Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible > > Descriptor, etc. > > - Execution rate is 70%. No new dpdk issue is found. > > * Intel NIC single core/NIC performance: test scenarios including PF/VF > > single > > core performance test, etc. > > - Execution rate is 80%. No new dpdk issue is found. > > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - > > QAT&SW/FIB library, etc. > > - on going. > > > > # Basic cryptodev and virtio testing > > * Virtio: both function and performance test are covered. Such as > > PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf > > testing/VMAWARE ESXI 7.0u3, etc. > > - Execution rate is 95%. No new dpdk issue is found. > > * Cryptodev: > > *Function test: test scenarios including Cryptodev API testing/CompressDev > > ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. > > - Execution rate is 95%. bug2 was found. > > *Performance test: test scenarios including Thoughput > > Performance/Cryptodev Latency, etc. > > - All test done. No new dpdk issue is found. > > > > Regards, > > Xu, Hailin > > > > > -Original Message- > > > From: luca.bocca...@gmail.com > > > Sent: Saturday, April 1, 2023 2:20 AM > > > To: sta...@dpdk.org > > > Cc: dev@dpdk.org; Abhishek Marathe ; > > > Ali Alnubani ; Walker, Benjamin > > > ; David Christensen > > > ; Hemant Agrawal ; > > > Stokes, Ian ; Jerin Jacob ; > > > Mcnamara, John ; Ju-Hyoung Lee > > > ; Kevin Traynor ; Luca > > > Boccassi ; Pei Zhang ; Xu, Qian > > > Q ; Raslan Darawsheh ; > > Thomas > > > Monjalon ; Yanghang Liu ; > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > Subject: 20.11.8 patches review and test > > > > > > Hi all, > > > > > > Here is a list of patches targeted for stable release 20.11.8. > > > > > > The planned date for the final release is April 17th. > > > > > > Please help with testing and validation of your use cases and report > > > any issues/results with reply-all to this mail. For the final release > > > the fixes and reported validations will be added to the release notes. > > > > > > A release candidate tarball can be found at: > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v20.11.8-rc1 > > > > > > These patches are located at branch 20.11 of dpdk-stable repo: > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > Thanks. > > > > > > Luca Boccassi > Update the test status for Intel part. Till now dpdk20.11.8-rc1 validation > test rate is 98%. No critical issue is found. > 4 new bugs are found, These 3 issues are being confirmed by Intel Dev. > New bugs: > 1. softnic and metering_and_policing: create rule failed -- Intel dev is > under investigating. > 2. some of the unit tests are failing: -- Intel dev is under investigating > 3. pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac: > performance drop about 23.5% when send small packets > https://bugs.dpdk.org/show_bug.cgi?id=1212 > 4. large_vf/3_vfs_256_queues："OP_DEL_RSS_INPUT_CFG" error appears when > exiting testpmd -- Intel dev is under investigating > # Basic Intel(R) NIC testing > * Build & CFLAG compile: cover the build test combination with latest > GCC/Clang version and the popular OS revision such as Ubuntu20.04, Fedora36, > RHEL8.4, etc. > - All test done. No new dpdk issue is found. > * PF(i
Re: [RFC 00/27] Add VDUSE support to Vhost library
On 4/13/2023 8:59 AM, Maxime Coquelin wrote: > Hi, > > On 4/13/23 09:08, Xia, Chenbo wrote: >>> -Original Message- >>> From: Morten Brørup >>> Sent: Thursday, April 13, 2023 3:41 AM >>> To: Maxime Coquelin ; Ferruh Yigit >>> ; dev@dpdk.org; david.march...@redhat.com; Xia, >>> Chenbo ; m...@redhat.com; f...@redhat.com; >>> jasow...@redhat.com; Liang, Cunming ; Xie, >>> Yongji >>> ; echau...@redhat.com; epere...@redhat.com; >>> amore...@redhat.com >>> Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library >>> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] Sent: Wednesday, 12 April 2023 17.28 Hi Ferruh, On 4/12/23 13:33, Ferruh Yigit wrote: > On 3/31/2023 4:42 PM, Maxime Coquelin wrote: >> This series introduces a new type of backend, VDUSE, >> to the Vhost library. >> >> VDUSE stands for vDPA device in Userspace, it enables >> implementing a Virtio device in userspace and have it >> attached to the Kernel vDPA bus. >> >> Once attached to the vDPA bus, it can be used either by >> Kernel Virtio drivers, like virtio-net in our case, via >> the virtio-vdpa driver. Doing that, the device is visible >> to the Kernel networking stack and is exposed to userspace >> as a regular netdev. >> >> It can also be exposed to userspace thanks to the >> vhost-vdpa driver, via a vhost-vdpa chardev that can be >> passed to QEMU or Virtio-user PMD. >> >> While VDUSE support is already available in upstream >> Kernel, a couple of patches are required to support >> network device type: >> >> https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc >> >> In order to attach the created VDUSE device to the vDPA >> bus, a recent iproute2 version containing the vdpa tool is >> required. > > Hi Maxime, > > Is this a replacement to the existing DPDK vDPA framework? What is the > plan for long term? > No, this is not a replacement for DPDK vDPA framework. We (Red Hat) don't have plans to support DPDK vDPA framework in our products, but there are still contribution to DPDK vDPA by several vDPA hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is going to be deprecated soon. >>> >>> Ferruh's question made me curious... >>> >>> I don't know anything about VDUSE or vDPA, and don't use any of it, so >>> consider me ignorant in this area. >>> >>> Is VDUSE an alternative to the existing DPDK vDPA framework? What are >>> the >>> differences, e.g. in which cases would an application developer (or >>> user) >>> choose one or the other? >> >> Maxime should give better explanation.. but let me just explain a bit. >> >> Vendors have vDPA HW that support vDPA framework (most likely in their >> DPU/IPU >> products). This work is introducing a way to emulate a SW vDPA device in >> userspace (DPDK), and this SW vDPA device also supports vDPA framework. >> >> So it's not an alternative to existing DPDK vDPA framework :) > > Correct. > > When using DPDK vDPA, the datapath of a Vhost-user port is offloaded to > a compatible physical NIC (i.e. a NIC that implements Virtio rings > support), the control path remains the same as a regular Vhost-user > port, i.e. it provides a Vhost-user unix socket to the application (like > QEMU or DPDK Virtio-user PMD). > > When using Kernel vDPA, the datapath is also offloaded to a vDPA > compatible device, and the control path is managed by the vDPA bus. > It can either be consumed by a Kernel Virtio device (here Virtio-net) > when using Virtio-vDPA. In this case the device is exposed as a regular > netdev and, in the case of Kubernetes, can be used as primary interfaces > for the pods. > Or it can be exposed to user-space via Vhost-vDPA, a chardev that can be > seen as an alternative to Vhost-user sockets. In this case it can for > example be used by QEMU or DPDK Virtio-user PMD. In Kubernetes, it can > be used as a secondary interface. > > Now comes VDUSE. VDUSE is a Kernel vDPA device, but instead of being a > physical device where the Virtio datapath is offloaded, the Virtio > datapath is offloaded to a user-space application. With this series, a > DPDK application, like OVS-DPDK for instance, can create VDUSE device > and expose them either as regular netdev when binding them to Kernel > Virtio-net driver via Virtio-vDPA, or as Vhost-vDPA interface to be > consumed by another userspace appliation like QEMU or DPDK application > using Virtio-user PMD. With this solution, OVS-DPDK could serve both > primary and secondary interfaces of Kubernetes pods. > > I hope it clarifies, I will add these information in the cover-letter > for next revisions. Let me know if anything is still unclear. > > I did a presentation at last DPDK summit [0], maybe the diagrams will > help to clarify furthermore. > Thanks Chenbo, Maxime for clarification. After reading a little more (I think) I got i
Re: [PATCH 1/1] net/gve: update base code for DQO
On 4/14/2023 6:17 AM, Rushil Gupta wrote: > I want to highlight that we wish to keep license changes separate from > this patch (probably for 23.11). This patch is to simply support basic > structures for the DQO data path. > +1 to separate it license patch.
[PATCH v3] net/i40e: support enable/disable source pruning
VRRP advertisement packets are dropped on i40e PF device because
when a MAC address is added to a device, packets originating from
that MAC address are dropped.
This patch adds a PMD specific API to enable/disable source
pruning to fix above issue.
Bugzilla ID: 648
Fixes: 94b3c1a72507 ("net/i40e: move testpmd commands")
Fixes: bce83974ba2c ("net/i40e: set Tx loopback from PF")
Fixes: 96974a6600ec ("net/i40e: move private APIs to a specific file")
Fixes: 689bba33272d ("i40e: add VEB switching support")
Fixes: 440499cf5376 ("net/i40e: support floating VEB")
Fixes: ef4c16fd9148 ("net/i40e: refactor RSS flow")
Cc: sta...@dpdk.org
Signed-off-by: Mingjin Ye
---
v3: The i40e specific commands are moved to
drivers/net/i40e/i40e_testpmd.c.
---
drivers/net/i40e/i40e_ethdev.c | 43
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_testpmd.c | 88 +
drivers/net/i40e/rte_pmd_i40e.c | 20
drivers/net/i40e/rte_pmd_i40e.h | 17 +++
drivers/net/i40e/version.map| 1 +
6 files changed, 170 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index cb0070f94b..90d8e5a8bc 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5647,6 +5647,46 @@ i40e_enable_pf_lb(struct i40e_pf *pf)
hw->aq.asq_last_status);
}
+/* i40e_pf_set_source_prune
+ * @pf: pointer to the pf structure
+ * @on: Enable/disable source prune
+ *
+ * set source prune on pf
+ */
+int
+i40e_pf_set_source_prune(struct i40e_pf *pf, int on)
+{
+ struct i40e_hw *hw = I40E_PF_TO_HW(pf);
+ struct i40e_vsi_context ctxt;
+ int ret;
+
+ memset(&ctxt, 0, sizeof(ctxt));
+ ctxt.seid = pf->main_vsi_seid;
+ ctxt.pf_num = hw->pf_id;
+ ret = i40e_aq_get_vsi_params(hw, &ctxt, NULL);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "cannot get pf vsi config, err %d, aq_err %d",
+ ret, hw->aq.asq_last_status);
+ return ret;
+ }
+ ctxt.flags = I40E_AQ_VSI_TYPE_PF;
+ ctxt.info.valid_sections =
+ rte_cpu_to_le_16(I40E_AQ_VSI_PROP_SWITCH_VALID);
+ if (on)
+ ctxt.info.switch_id &=
+ ~rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
+ else
+ ctxt.info.switch_id |=
+ rte_cpu_to_le_16(I40E_AQ_VSI_SW_ID_FLAG_LOCAL_LB);
+
+ ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
+ if (ret)
+ PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d",
+ hw->aq.asq_last_status);
+
+ return ret;
+}
+
/* Setup a VSI */
struct i40e_vsi *
i40e_vsi_setup(struct i40e_pf *pf,
@@ -5704,6 +5744,9 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
}
+ /* source prune is disabled to support VRRP in default*/
+ i40e_pf_set_source_prune(pf, 0);
+
vsi = rte_zmalloc("i40e_vsi", sizeof(struct i40e_vsi), 0);
if (!vsi) {
PMD_DRV_LOG(ERR, "Failed to allocate memory for vsi");
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 9b806d130e..6f65d5e0ac 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -1430,6 +1430,7 @@ int i40e_pf_calc_configured_queues_num(struct i40e_pf
*pf);
int i40e_pf_reset_rss_reta(struct i40e_pf *pf);
int i40e_pf_reset_rss_key(struct i40e_pf *pf);
int i40e_pf_config_rss(struct i40e_pf *pf);
+int i40e_pf_set_source_prune(struct i40e_pf *pf, int on);
int i40e_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, uint8_t key_len);
int i40e_set_rss_lut(struct i40e_vsi *vsi, uint8_t *lut, uint16_t lut_size);
int i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params);
diff --git a/drivers/net/i40e/i40e_testpmd.c b/drivers/net/i40e/i40e_testpmd.c
index 7be9fea5b0..b6ef5d6e42 100644
--- a/drivers/net/i40e/i40e_testpmd.c
+++ b/drivers/net/i40e/i40e_testpmd.c
@@ -2446,6 +2446,84 @@ static cmdline_parse_inst_t cmd_ptype_mapping_update = {
},
};
+/* *** configure source prune for port *** */
+struct cmd_config_src_prune_result {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t keyword;
+ cmdline_fixed_string_t port_all; /* valid if "allports" argument == 1 */
+ uint16_t port_id;/* valid if "allports" argument == 0 */
+ cmdline_fixed_string_t item;
+ cmdline_fixed_string_t enable;
+};
+
+static void cmd_config_pf_src_prune_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ void *allports)
+{
+ struct cmd_config_src_prune_result *res = parsed_result;
+ uint8_t enable;
+ uint16_t i;
+
+ if (!strcmp(res->enable, "on"))
+ enable = 1;
+ else
+ enable = 0;
+
+ /* all ports */
+ if (allports) {
+ RTE
[PATCH] net/e1000: report VLAN extend capability for 82576
82576 also has exended VLAN support. Signed-off-by: Akihiko Odaki --- drivers/net/e1000/igb_rxtx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index f32dee46df..25ad9eb4e5 100644 --- a/drivers/net/e1000/igb_rxtx.c +++ b/drivers/net/e1000/igb_rxtx.c @@ -1648,7 +1648,8 @@ igb_get_rx_port_offloads_capa(struct rte_eth_dev *dev) RTE_ETH_RX_OFFLOAD_SCATTER | RTE_ETH_RX_OFFLOAD_RSS_HASH; - if (hw->mac.type == e1000_i350 || + if (hw->mac.type == e1000_82576 || + hw->mac.type == e1000_i350 || hw->mac.type == e1000_i210 || hw->mac.type == e1000_i211) rx_offload_capa |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND; -- 2.40.0
Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
On 4/14/2023 8:05 AM, David Marchand wrote:
> On Thu, Apr 13, 2023 at 7:51 PM Tummala, Sivaprasad
> wrote:
>>
>> [AMD Official Use Only - General]
>>
>> Hi David,
>>
>>> -Original Message-
>>> From: David Marchand
>>> Sent: Thursday, April 13, 2023 5:30 PM
>>> To: Tummala, Sivaprasad
>>> Cc: david.h...@intel.com; dev@dpdk.org; Thomas Monjalon
>>> ; Burakov, Anatoly
>>> Subject: Re: [PATCH v2 1/3] eal: add x86 cpuid support for monitorx
>>>
>>> Caution: This message originated from an External Source. Use proper caution
>>> when opening attachments, clicking links, or responding.
>>>
>>>
>>> On Thu, Apr 13, 2023 at 1:54 PM Sivaprasad Tummala
>>> wrote:
Add a new CPUID flag to indicate support for monitorx instruction on
AMD Epyc processors.
Signed-off-by: Sivaprasad Tummala
---
lib/eal/include/generic/rte_cpuflags.h | 2 ++
lib/eal/x86/include/rte_cpuflags.h | 1 +
lib/eal/x86/rte_cpuflags.c | 3 +++
3 files changed, 6 insertions(+)
diff --git a/lib/eal/include/generic/rte_cpuflags.h
b/lib/eal/include/generic/rte_cpuflags.h
index d35551e931..db653a8dd7 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -26,6 +26,8 @@ struct rte_cpu_intrinsics {
/**< indicates support for rte_power_pause function */
uint32_t power_monitor_multi : 1;
/**< indicates support for rte_power_monitor_multi function */
+ uint32_t amd_power_monitorx : 1;
+ /**< indicates amd support for rte_power_monitor function */
>>>
>>> I did not look at the patch detail, I just stopped at this part.
>>> What makes the AMD monitorx stuff special that it needs to be exposed in the
>>> generic API?
>>
>> Monitorx is different ISA /opcode (0F 01 FA) as compared to UMonitor (0F 01
>> C8). This need to be distinguished
>> on specific x86 platforms. Hence in the current power intrinsics, for x86 we
>> require a new flag to
>> distinguish MonitorX and UMonitor and invoke the appropriate x86 ISA in the
>> datapath.
>
> Requiring a new x86 cpuflag to identify this ISA presence is ok.
>
>
> But here, I am talking about the generic power instrinsic API.
> Let me phrase my comment differently...
>
> As described in the API:
> uint32_t power_monitor : 1;
> /**< indicates support for rte_power_monitor function */
>
> Does AMD thing behave completely different from the x86?
> Looking at patch 3, I understand this is not the case.
>
> So we don't need a "amd" flag in the generic flags.
> The indirection for calling the right ISA should be hidden in
> rte_power_* helpers implemented for x86.
>
>
The 'rte_cpu_get_intrinsics_support()' API and "struct
rte_cpu_intrinsics" struct seems intended to get power features in
generic way, agree to keep it generic.
But also there is a need to run architecture specific instructions, so
need to know the architecture within power library, for this what do you
think to check 'MONITORX' support again in 'rte_power_intrinsics_init()'
function?
And most of the 'amd_power_monitorx()' function is duplicate of the
'rte_power_monitor()' API, only difference is the asm calls, what do you
think to extract these calls to function pointers for AMD and Intel, so
that 'rte_power_monitor()' can become a x86 generic function?
As architecture will be known in the 'rte_power_intrinsics_init()', we
can set the function pointers properly for architecture in this init stage.
Only concern is possible performance impact of pointer dereference
instead of direct call, I hope @David Hunt can help us to test the
performance impact of it in Intel platforms if this approach is reasonable.
Re: [RFC 00/27] Add VDUSE support to Vhost library
On 4/14/23 12:48, Ferruh Yigit wrote: On 4/13/2023 8:59 AM, Maxime Coquelin wrote: Hi, On 4/13/23 09:08, Xia, Chenbo wrote: -Original Message- From: Morten Brørup Sent: Thursday, April 13, 2023 3:41 AM To: Maxime Coquelin ; Ferruh Yigit ; dev@dpdk.org; david.march...@redhat.com; Xia, Chenbo ; m...@redhat.com; f...@redhat.com; jasow...@redhat.com; Liang, Cunming ; Xie, Yongji ; echau...@redhat.com; epere...@redhat.com; amore...@redhat.com Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] Sent: Wednesday, 12 April 2023 17.28 Hi Ferruh, On 4/12/23 13:33, Ferruh Yigit wrote: On 3/31/2023 4:42 PM, Maxime Coquelin wrote: This series introduces a new type of backend, VDUSE, to the Vhost library. VDUSE stands for vDPA device in Userspace, it enables implementing a Virtio device in userspace and have it attached to the Kernel vDPA bus. Once attached to the vDPA bus, it can be used either by Kernel Virtio drivers, like virtio-net in our case, via the virtio-vdpa driver. Doing that, the device is visible to the Kernel networking stack and is exposed to userspace as a regular netdev. It can also be exposed to userspace thanks to the vhost-vdpa driver, via a vhost-vdpa chardev that can be passed to QEMU or Virtio-user PMD. While VDUSE support is already available in upstream Kernel, a couple of patches are required to support network device type: https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc In order to attach the created VDUSE device to the vDPA bus, a recent iproute2 version containing the vdpa tool is required. Hi Maxime, Is this a replacement to the existing DPDK vDPA framework? What is the plan for long term? No, this is not a replacement for DPDK vDPA framework. We (Red Hat) don't have plans to support DPDK vDPA framework in our products, but there are still contribution to DPDK vDPA by several vDPA hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is going to be deprecated soon. Ferruh's question made me curious... I don't know anything about VDUSE or vDPA, and don't use any of it, so consider me ignorant in this area. Is VDUSE an alternative to the existing DPDK vDPA framework? What are the differences, e.g. in which cases would an application developer (or user) choose one or the other? Maxime should give better explanation.. but let me just explain a bit. Vendors have vDPA HW that support vDPA framework (most likely in their DPU/IPU products). This work is introducing a way to emulate a SW vDPA device in userspace (DPDK), and this SW vDPA device also supports vDPA framework. So it's not an alternative to existing DPDK vDPA framework :) Correct. When using DPDK vDPA, the datapath of a Vhost-user port is offloaded to a compatible physical NIC (i.e. a NIC that implements Virtio rings support), the control path remains the same as a regular Vhost-user port, i.e. it provides a Vhost-user unix socket to the application (like QEMU or DPDK Virtio-user PMD). When using Kernel vDPA, the datapath is also offloaded to a vDPA compatible device, and the control path is managed by the vDPA bus. It can either be consumed by a Kernel Virtio device (here Virtio-net) when using Virtio-vDPA. In this case the device is exposed as a regular netdev and, in the case of Kubernetes, can be used as primary interfaces for the pods. Or it can be exposed to user-space via Vhost-vDPA, a chardev that can be seen as an alternative to Vhost-user sockets. In this case it can for example be used by QEMU or DPDK Virtio-user PMD. In Kubernetes, it can be used as a secondary interface. Now comes VDUSE. VDUSE is a Kernel vDPA device, but instead of being a physical device where the Virtio datapath is offloaded, the Virtio datapath is offloaded to a user-space application. With this series, a DPDK application, like OVS-DPDK for instance, can create VDUSE device and expose them either as regular netdev when binding them to Kernel Virtio-net driver via Virtio-vDPA, or as Vhost-vDPA interface to be consumed by another userspace appliation like QEMU or DPDK application using Virtio-user PMD. With this solution, OVS-DPDK could serve both primary and secondary interfaces of Kubernetes pods. I hope it clarifies, I will add these information in the cover-letter for next revisions. Let me know if anything is still unclear. I did a presentation at last DPDK summit [0], maybe the diagrams will help to clarify furthermore. Thanks Chenbo, Maxime for clarification. After reading a little more (I think) I got it better, slides [0] were useful. So this is more like a backend/handler, similar to vhost-user, although it is vDPA device emulation. Can you please describe more the benefit of vduse comparing to vhost-user? The main benefit is that VDUSE device can be exposed as a regular netdev, while this is not possible with Vhost-user. Also what is "VDUSE daemon", which is referred a few times in documentation, is
[PATCH] crypto/qat: fix stack buffer overflow in SGL loop
The cvec pointer was incremented incorrectly in the case where the
length of remaining_off equals cvec len, and there is no next cvec.
This led to cvec->iova being invalid memory to access.
Instead, only increment the cvec pointer when we know there is a next
cvec to point to, by checking the i value, which represents the number
of cvecs available.
If i is 0, then no need to increment as the current cvec is the last one.
Fixes: a815a04cea05 ("crypto/qat: support symmetric build op request")
Cc: kai...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
---
drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
index 524c291340..092265631b 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
@@ -682,7 +682,8 @@ enqueue_one_chain_job_gen1(struct qat_sym_session *ctx,
while (remaining_off >= cvec->len && i >= 1) {
i--;
remaining_off -= cvec->len;
- cvec++;
+ if (i)
+ cvec++;
}
auth_iova_end = cvec->iova + remaining_off;
--
2.25.1
[PATCH] crypto/scheduler: fix last element for valid args
The list of valid arguments for Scheduler PMD should be terminated with
a NULL entry, as expected by rte_kvargs_parse.
Without this, if an invalid key name was used, a global buffer overflow
occurred resulting in a segmentation fault.
Fixes: 503e9c5afb38 ("crypto/scheduler: register as vdev driver")
Cc: fanzhang@gmail.com
Cc: sta...@dpdk.org
Signed-off-by: Ciara Power
---
drivers/crypto/scheduler/scheduler_pmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/scheduler/scheduler_pmd.c
b/drivers/crypto/scheduler/scheduler_pmd.c
index 9d1ce46622..4e8bbf0e09 100644
--- a/drivers/crypto/scheduler/scheduler_pmd.c
+++ b/drivers/crypto/scheduler/scheduler_pmd.c
@@ -50,7 +50,8 @@ static const char * const scheduler_valid_params[] = {
RTE_CRYPTODEV_VDEV_MAX_NB_QP_ARG,
RTE_CRYPTODEV_VDEV_SOCKET_ID,
RTE_CRYPTODEV_VDEV_COREMASK,
- RTE_CRYPTODEV_VDEV_CORELIST
+ RTE_CRYPTODEV_VDEV_CORELIST,
+ NULL
};
struct scheduler_parse_map {
--
2.25.1
[PATCH v2] net/e1000: report VLAN extend capability for 82576
82576 also has extended VLAN support. Signed-off-by: Akihiko Odaki --- drivers/net/e1000/igb_rxtx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index f32dee46df..25ad9eb4e5 100644 --- a/drivers/net/e1000/igb_rxtx.c +++ b/drivers/net/e1000/igb_rxtx.c @@ -1648,7 +1648,8 @@ igb_get_rx_port_offloads_capa(struct rte_eth_dev *dev) RTE_ETH_RX_OFFLOAD_SCATTER | RTE_ETH_RX_OFFLOAD_RSS_HASH; - if (hw->mac.type == e1000_i350 || + if (hw->mac.type == e1000_82576 || + hw->mac.type == e1000_i350 || hw->mac.type == e1000_i210 || hw->mac.type == e1000_i211) rx_offload_capa |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND; -- 2.40.0
RE: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC
> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Friday, 14 April 2023 11.22 > > On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote: > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > Sent: Thursday, 13 April 2023 23.26 > > > > > > For now expand a lot of common rte macros empty. The catch here is we > > > need to test that most of the macros do what they should but at the same > > > time they are blocking work needed to bootstrap of the unit tests. > > > > > > Later we will return and provide (where possible) expansions that work > > > correctly for msvc and where not possible provide some alternate macros > > > to achieve the same outcome. > > > > > > Signed-off-by: Tyler Retzlaff > > > --- > > > lib/eal/include/rte_branch_prediction.h | 8 ++ > > > lib/eal/include/rte_common.h| 45 > > > + > > > lib/eal/include/rte_compat.h| 20 +++ > > > 3 files changed, 73 insertions(+) > > > > > > diff --git a/lib/eal/include/rte_branch_prediction.h > > > b/lib/eal/include/rte_branch_prediction.h > > > index 0256a9d..d9a0224 100644 > > > --- a/lib/eal/include/rte_branch_prediction.h > > > +++ b/lib/eal/include/rte_branch_prediction.h > > > @@ -25,7 +25,11 @@ > > > * > > > */ > > > #ifndef likely > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > #define likely(x)__builtin_expect(!!(x), 1) > > > +#else > > > +#define likely(x)(x) > > > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), > and likely() must return Boolean (0 or 1). > > > > Will this really make a difference? Is there somewhere likely/unlikely > would be used where we would not get the same conversion to boolean than we > get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just > wondering if there are actual cases where it affects the output?] I agree that it makes no difference the way it is typically used. But there are creative developers out there, so these macros definitely need the "!!" conversion to Boolean. > > > > +#endif > > > #endif /* likely */ > > > > > > /** > > > @@ -39,7 +43,11 @@ > > > * > > > */ > > > #ifndef unlikely > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > #define unlikely(x) __builtin_expect(!!(x), 0) > > > +#else > > > +#define unlikely(x) (x) > > > > This must also be (!!(x)), for the same reason as above. > > > > > +#endif > > > #endif /* unlikely */ > > > > > > #ifdef __cplusplus > > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h > > > index 2f464e3..1bdaa2d 100644 > > > --- a/lib/eal/include/rte_common.h > > > +++ b/lib/eal/include/rte_common.h > > > @@ -65,7 +65,11 @@ > > > /** > > > * Force alignment > > > */ > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > > +#else > > > +#define __rte_aligned(a) > > > +#endif > > > > It should be reviewed that __rte_aligned() is only used for optimization > purposes, and is not required for DPDK to function properly. > > > > Good point. > > If we look across all of DPDK, things will likely break, as we are relying > on alignment in various places to use the aligned versions of instructions. > For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86 > vectorized driver code. A "git grep _load_si" shows quite a few aligned > vector load instructions used in our codebase. These will fault and cause a > crash if the data is not properly aligned. [I suspect that there are similar > restrictions on other architectures too, just not familiar with their > intrinsics to check.] Another thing that has been annoying me with the use of vector instructions: Vector instructions are often used in a way where they cast away the type they are working on, so if that type is modified (e.g. a field is moved), the code will happily build, but fail at runtime. When casting away the type for vector instructions, _Static_assert or BUILD_BUG_ON should be used to verify the assumptions about the cast away type. Such a practice might catch some of the places where the missing alignment (and missing structure packing) would fail. > > However, it may be that none of the code paths where these are used is > in code currently compiled on windows, so this may be safe for now. The > occurances are mostly in drivers. > > $ git grep -l _load_si > drivers/common/idpf/idpf_common_rxtx_avx512.c > drivers/event/dlb2/dlb2.c > drivers/net/bnxt/bnxt_rxtx_vec_avx2.c > drivers/net/bnxt/bnxt_rxtx_vec_sse.c > drivers/net/enic/enic_rxtx_vec_avx2.c > drivers/net/i40e/i40e_rxtx_vec_avx2.c > drivers/net/i40e/i40e_rxtx_vec_avx512.c > drivers/net/iavf/iavf_rxtx_vec_avx2.c > drivers/net/iavf/iavf_rxtx_vec_avx512.c > drivers/net/iavf/iavf_rxtx_vec_sse.c > drivers/net/ice/ice_rxtx_vec_avx2.c > drivers/net/ice/ice_rxtx_vec_avx512.c > drivers/net/ice/ice_rxtx_vec_sse.c > drivers/net/mlx5/mlx5_rxtx_vec_sse.h > lib/acl/acl_bld.c > lib/di
[PATCH 0/2] Enable generic Arm build
I use Apple Silicon computer as development environment. This allows to run DPDK Test Suite on such Arm devices just as you can run DTS on x86 development machine. Akihiko Odaki (2): config/arm: Do not require processor information config/arm: Enable NUMA for generic Arm build config/arm/meson.build | 42 +++--- 1 file changed, 23 insertions(+), 19 deletions(-) -- 2.40.0
[PATCH 2/2] config/arm: Enable NUMA for generic Arm build
We enable NUMA even if the presence of NUMA is unknown for the other
architectures. Enable NUMA for generic Arm build too.
Signed-off-by: Akihiko Odaki
---
config/arm/meson.build | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 724c00ad7e..f8ee7cdafb 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -271,13 +271,15 @@ implementers = {
soc_generic = {
'description': 'Generic un-optimized build for armv8 aarch64 exec mode',
'implementer': 'generic',
-'part_number': 'generic'
+'part_number': 'generic',
+'numa': true
}
soc_generic_aarch32 = {
'description': 'Generic un-optimized build for armv8 aarch32 exec mode',
'implementer': 'generic',
-'part_number': 'generic_aarch32'
+'part_number': 'generic_aarch32',
+'numa': true
}
soc_armada = {
--
2.40.0
[PATCH 1/2] config/arm: Do not require processor information
DPDK can be built even without exact processor information for x86 and
ppc so allow to build for Arm even if we don't know the targeted
processor is unknown.
Signed-off-by: Akihiko Odaki
---
config/arm/meson.build | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 6442ec9596..724c00ad7e 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -582,29 +582,31 @@ if update_flags
enable_drivers += ',' + soc_config.get('enable_drivers', '')
endif
-if implementers.has_key(implementer_id)
+if not implementers.has_key(implementer_id)
+implementer_id = 'generic'
+endif
+
+implementer_config = implementers[implementer_id]
+part_number_config = implementer_config['part_number_config']
+
+if not part_number_config.has_key(part_number)
+implementer_id = 'generic'
+
+if dpdk_conf.get('RTE_ARCH_32')
+part_number = 'generic_aarch32'
+else
+part_number = 'generic'
+endif
+
implementer_config = implementers[implementer_id]
-else
-error('Unsupported Arm implementer: @0@. '.format(implementer_id) +
- 'Please add support for it or use the generic ' +
- '(-Dplatform=generic) build.')
+part_number_config = implementer_config['part_number_config']
endif
+part_number_config = part_number_config[part_number]
+
message('Arm implementer: ' + implementer_config['description'])
message('Arm part number: ' + part_number)
-part_number_config = implementer_config['part_number_config']
-if part_number_config.has_key(part_number)
-# use the specified part_number machine args if found
-part_number_config = part_number_config[part_number]
-else
-# unknown part number
-error('Unsupported part number @0@ of implementer @1@. '
- .format(part_number, implementer_id) +
- 'Please add support for it or use the generic ' +
- '(-Dplatform=generic) build.')
-endif
-
# add/overwrite flags in the proper order
dpdk_flags = flags_common + implementer_config['flags'] +
part_number_config.get('flags', []) + soc_flags
--
2.40.0
RE: [PATCH v2] dmadev: add tracepoints
> From: Chengwen Feng [mailto:fengcheng...@huawei.com] > Sent: Friday, 14 April 2023 11.09 > > Add tracepoints at important APIs for tracing support. > > Signed-off-by: Chengwen Feng > > --- > v2: Address Morten's comment: > Make stats_get as fast-path trace-points. > Place fast-path trace-point functions behind in version.map. ... > +RTE_TRACE_POINT( > + rte_dma_trace_vchan_status, rte_dma_trace_vchan_status should also be a FP trace point. > + RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan, > + enum rte_dma_vchan_status *status, int ret), > + int vchan_status = *status; > + rte_trace_point_emit_i16(dev_id); > + rte_trace_point_emit_u16(vchan); > + rte_trace_point_emit_int(vchan_status); > + rte_trace_point_emit_int(ret); > +) > + > +RTE_TRACE_POINT( > + rte_dma_trace_dump, > + RTE_TRACE_POINT_ARGS(int16_t dev_id, FILE *f, int ret), > + rte_trace_point_emit_i16(dev_id); > + rte_trace_point_emit_ptr(f); > + rte_trace_point_emit_int(ret); > +) > + > +/* Fast path trace points */ Don't add the fast path trace points here. Add them to the rte_dmadev_trace_fp.h file. > + > +/* Called in loop in examples/dma */ > +RTE_TRACE_POINT_FP( > + rte_dma_trace_stats_get, > + RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan, > + struct rte_dma_stats *stats, int ret), > + rte_trace_point_emit_i16(dev_id); > + rte_trace_point_emit_u16(vchan); > + rte_trace_point_emit_u64(stats->submitted); > + rte_trace_point_emit_u64(stats->completed); > + rte_trace_point_emit_u64(stats->errors); > + rte_trace_point_emit_int(ret); > +) With those two fixes, you may add: Acked-by: Morten Brørup
RE: [PATCH] crypto/scheduler: fix last element for valid args
Acked-by: Kai Ji
> -Original Message-
> From: Power, Ciara
> Sent: Friday, April 14, 2023 1:33 PM
> To: Ji, Kai
> Cc: dev@dpdk.org; Power, Ciara ;
> fanzhang@gmail.com; sta...@dpdk.org
> Subject: [PATCH] crypto/scheduler: fix last element for valid args
>
> The list of valid arguments for Scheduler PMD should be terminated with a
> NULL entry, as expected by rte_kvargs_parse.
>
> Without this, if an invalid key name was used, a global buffer overflow
> occurred resulting in a segmentation fault.
>
> Fixes: 503e9c5afb38 ("crypto/scheduler: register as vdev driver")
> Cc: fanzhang@gmail.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
> ---
> drivers/crypto/scheduler/scheduler_pmd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/scheduler/scheduler_pmd.c
> b/drivers/crypto/scheduler/scheduler_pmd.c
> index 9d1ce46622..4e8bbf0e09 100644
> --- a/drivers/crypto/scheduler/scheduler_pmd.c
> +++ b/drivers/crypto/scheduler/scheduler_pmd.c
> @@ -50,7 +50,8 @@ static const char * const scheduler_valid_params[] = {
> RTE_CRYPTODEV_VDEV_MAX_NB_QP_ARG,
> RTE_CRYPTODEV_VDEV_SOCKET_ID,
> RTE_CRYPTODEV_VDEV_COREMASK,
> - RTE_CRYPTODEV_VDEV_CORELIST
> + RTE_CRYPTODEV_VDEV_CORELIST,
> + NULL
> };
>
> struct scheduler_parse_map {
> --
> 2.25.1
RE: [PATCH] crypto/qat: fix stack buffer overflow in SGL loop
Acked-by: Kai Ji
> -Original Message-
> From: Power, Ciara
> Sent: Friday, April 14, 2023 1:32 PM
> To: Ji, Kai
> Cc: dev@dpdk.org; Power, Ciara ; sta...@dpdk.org
> Subject: [PATCH] crypto/qat: fix stack buffer overflow in SGL loop
>
> The cvec pointer was incremented incorrectly in the case where the length
> of remaining_off equals cvec len, and there is no next cvec.
> This led to cvec->iova being invalid memory to access.
>
> Instead, only increment the cvec pointer when we know there is a next cvec
> to point to, by checking the i value, which represents the number of cvecs
> available.
> If i is 0, then no need to increment as the current cvec is the last one.
>
> Fixes: a815a04cea05 ("crypto/qat: support symmetric build op request")
> Cc: kai...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
> ---
> drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> index 524c291340..092265631b 100644
> --- a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> +++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> @@ -682,7 +682,8 @@ enqueue_one_chain_job_gen1(struct qat_sym_session *ctx,
> while (remaining_off >= cvec->len && i >= 1) {
> i--;
> remaining_off -= cvec->len;
> - cvec++;
> + if (i)
> + cvec++;
> }
>
> auth_iova_end = cvec->iova + remaining_off;
> --
> 2.25.1
Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC
On Fri, Apr 14, 2023 at 02:39:03PM +0200, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Friday, 14 April 2023 11.22 > > > > On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote: > > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > > > Sent: Thursday, 13 April 2023 23.26 > > > > > > > > For now expand a lot of common rte macros empty. The catch here is we > > > > need to test that most of the macros do what they should but at the same > > > > time they are blocking work needed to bootstrap of the unit tests. > > > > > > > > Later we will return and provide (where possible) expansions that work > > > > correctly for msvc and where not possible provide some alternate macros > > > > to achieve the same outcome. > > > > > > > > Signed-off-by: Tyler Retzlaff > > > > --- > > > > lib/eal/include/rte_branch_prediction.h | 8 ++ > > > > lib/eal/include/rte_common.h| 45 > > > > + > > > > lib/eal/include/rte_compat.h| 20 +++ > > > > 3 files changed, 73 insertions(+) > > > > > > > > diff --git a/lib/eal/include/rte_branch_prediction.h > > > > b/lib/eal/include/rte_branch_prediction.h > > > > index 0256a9d..d9a0224 100644 > > > > --- a/lib/eal/include/rte_branch_prediction.h > > > > +++ b/lib/eal/include/rte_branch_prediction.h > > > > @@ -25,7 +25,11 @@ > > > > * > > > > */ > > > > #ifndef likely > > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > > #define likely(x) __builtin_expect(!!(x), 1) > > > > +#else > > > > +#define likely(x) (x) > > > > > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), > > and likely() must return Boolean (0 or 1). > > > > > > > Will this really make a difference? Is there somewhere likely/unlikely > > would be used where we would not get the same conversion to boolean than we > > get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just > > wondering if there are actual cases where it affects the output?] > > I agree that it makes no difference the way it is typically used. > > But there are creative developers out there, so these macros definitely need > the "!!" conversion to Boolean. > Sure. > > > > > > +#endif > > > > #endif /* likely */ > > > > > > > > /** > > > > @@ -39,7 +43,11 @@ > > > > * > > > > */ > > > > #ifndef unlikely > > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > > #define unlikely(x)__builtin_expect(!!(x), 0) > > > > +#else > > > > +#define unlikely(x)(x) > > > > > > This must also be (!!(x)), for the same reason as above. > > > > > > > +#endif > > > > #endif /* unlikely */ > > > > > > > > #ifdef __cplusplus > > > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h > > > > index 2f464e3..1bdaa2d 100644 > > > > --- a/lib/eal/include/rte_common.h > > > > +++ b/lib/eal/include/rte_common.h > > > > @@ -65,7 +65,11 @@ > > > > /** > > > > * Force alignment > > > > */ > > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > > > +#else > > > > +#define __rte_aligned(a) > > > > +#endif > > > > > > It should be reviewed that __rte_aligned() is only used for optimization > > purposes, and is not required for DPDK to function properly. > > > > > > > Good point. > > > > If we look across all of DPDK, things will likely break, as we are relying > > on alignment in various places to use the aligned versions of instructions. > > For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86 > > vectorized driver code. A "git grep _load_si" shows quite a few aligned > > vector load instructions used in our codebase. These will fault and cause a > > crash if the data is not properly aligned. [I suspect that there are similar > > restrictions on other architectures too, just not familiar with their > > intrinsics to check.] > > Another thing that has been annoying me with the use of vector instructions: > > Vector instructions are often used in a way where they cast away the type > they are working on, so if that type is modified (e.g. a field is moved), the > code will happily build, but fail at runtime. > > When casting away the type for vector instructions, _Static_assert or > BUILD_BUG_ON should be used to verify the assumptions about the cast away > type. Such a practice might catch some of the places where the missing > alignment (and missing structure packing) would fail. > Agreed. And, in fairness, this is sometimes done in our code, e.g. [1], but should probably be more widely done. It's something we should try and catch in reviews of vector code, as it also helps document what exactly we are doing and why. /Bruce [1] http://git.dpdk.org/dpdk/tree/drivers/net/i40e/i40e_rxtx_vec_avx2.c#n183
RE: [PATCH] crypto/qat: fix stack buffer overflow in SGL loop
Hi Ciara,
> -Original Message-
> From: Ciara Power
> Sent: Friday 14 April 2023 13:32
> To: Ji, Kai
> Cc: dev@dpdk.org; Power, Ciara ; sta...@dpdk.org
> Subject: [PATCH] crypto/qat: fix stack buffer overflow in SGL loop
>
> The cvec pointer was incremented incorrectly in the case where the length of
> remaining_off equals cvec len, and there is no next cvec.
> This led to cvec->iova being invalid memory to access.
>
> Instead, only increment the cvec pointer when we know there is a next cvec
> to point to, by checking the i value, which represents the number of cvecs
> available.
> If i is 0, then no need to increment as the current cvec is the last one.
>
> Fixes: a815a04cea05 ("crypto/qat: support symmetric build op request")
> Cc: kai...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ciara Power
> ---
> drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> index 524c291340..092265631b 100644
> --- a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> +++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
> @@ -682,7 +682,8 @@ enqueue_one_chain_job_gen1(struct
> qat_sym_session *ctx,
> while (remaining_off >= cvec->len && i >= 1) {
> i--;
> remaining_off -= cvec->len;
> - cvec++;
> + if (i)
> + cvec++;
> }
>
> auth_iova_end = cvec->iova + remaining_off;
> --
> 2.25.1
Acked-by: Brian Dooley
[PATCH] test/crypto: fix return value for snow3g testcase
Unit tests were failing due to the return value of the decryption and
authentication functions not being handled correctly. This has now been
modified to return the expected test status.
Fixes: e23eccfd281e ("test/crypto: fix bitwise operator in a SNOW3G case")
Cc: kai...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Saoirse O'Donovan
---
app/test/test_cryptodev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 9c670e9a35..0713187d14 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -6944,6 +6944,7 @@ snow3g_hash_test_vector_setup(const struct
snow3g_test_data *pattern,
static int
test_snow3g_decryption_with_digest_test_case_1(void)
{
+ int ret;
struct snow3g_hash_test_data snow3g_hash_data;
struct rte_cryptodev_info dev_info;
struct crypto_testsuite_params *ts_params = &testsuite_params;
@@ -6962,8 +6963,9 @@ test_snow3g_decryption_with_digest_test_case_1(void)
*/
snow3g_hash_test_vector_setup(&snow3g_test_case_7, &snow3g_hash_data);
- if (test_snow3g_decryption(&snow3g_test_case_7))
- return TEST_FAILED;
+ ret = test_snow3g_decryption(&snow3g_test_case_7);
+ if (ret != 0)
+ return ret;
return test_snow3g_authentication_verify(&snow3g_hash_data);
}
--
2.25.1
RE: [PATCH] test/crypto: fix return value for snow3g testcase
Hi Saoirse,
> -Original Message-
> From: Saoirse O'Donovan
> Sent: Friday 14 April 2023 14:55
> To: Akhil Goyal ; Fan Zhang
>
> Cc: dev@dpdk.org; O'Donovan, Saoirse ; Ji,
> Kai ; sta...@dpdk.org
> Subject: [PATCH] test/crypto: fix return value for snow3g testcase
>
> Unit tests were failing due to the return value of the decryption and
> authentication functions not being handled correctly. This has now been
> modified to return the expected test status.
>
> Fixes: e23eccfd281e ("test/crypto: fix bitwise operator in a SNOW3G case")
> Cc: kai...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Saoirse O'Donovan
> ---
> app/test/test_cryptodev.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Acked-by: Ciara Power
Re: [RFC 00/27] Add VDUSE support to Vhost library
On 4/14/2023 1:06 PM, Maxime Coquelin wrote: > > > On 4/14/23 12:48, Ferruh Yigit wrote: >> On 4/13/2023 8:59 AM, Maxime Coquelin wrote: >>> Hi, >>> >>> On 4/13/23 09:08, Xia, Chenbo wrote: > -Original Message- > From: Morten Brørup > Sent: Thursday, April 13, 2023 3:41 AM > To: Maxime Coquelin ; Ferruh Yigit > ; dev@dpdk.org; david.march...@redhat.com; Xia, > Chenbo ; m...@redhat.com; f...@redhat.com; > jasow...@redhat.com; Liang, Cunming ; Xie, > Yongji > ; echau...@redhat.com; epere...@redhat.com; > amore...@redhat.com > Subject: RE: [RFC 00/27] Add VDUSE support to Vhost library > >> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] >> Sent: Wednesday, 12 April 2023 17.28 >> >> Hi Ferruh, >> >> On 4/12/23 13:33, Ferruh Yigit wrote: >>> On 3/31/2023 4:42 PM, Maxime Coquelin wrote: This series introduces a new type of backend, VDUSE, to the Vhost library. VDUSE stands for vDPA device in Userspace, it enables implementing a Virtio device in userspace and have it attached to the Kernel vDPA bus. Once attached to the vDPA bus, it can be used either by Kernel Virtio drivers, like virtio-net in our case, via the virtio-vdpa driver. Doing that, the device is visible to the Kernel networking stack and is exposed to userspace as a regular netdev. It can also be exposed to userspace thanks to the vhost-vdpa driver, via a vhost-vdpa chardev that can be passed to QEMU or Virtio-user PMD. While VDUSE support is already available in upstream Kernel, a couple of patches are required to support network device type: https://gitlab.com/mcoquelin/linux/-/tree/vduse_networking_poc In order to attach the created VDUSE device to the vDPA bus, a recent iproute2 version containing the vdpa tool is required. >>> >>> Hi Maxime, >>> >>> Is this a replacement to the existing DPDK vDPA framework? What >>> is the >>> plan for long term? >>> >> >> No, this is not a replacement for DPDK vDPA framework. >> >> We (Red Hat) don't have plans to support DPDK vDPA framework in our >> products, but there are still contribution to DPDK vDPA by several >> vDPA >> hardware vendors (Intel, Nvidia, Xilinx), so I don't think it is >> going >> to be deprecated soon. > > Ferruh's question made me curious... > > I don't know anything about VDUSE or vDPA, and don't use any of it, so > consider me ignorant in this area. > > Is VDUSE an alternative to the existing DPDK vDPA framework? What are > the > differences, e.g. in which cases would an application developer (or > user) > choose one or the other? Maxime should give better explanation.. but let me just explain a bit. Vendors have vDPA HW that support vDPA framework (most likely in their DPU/IPU products). This work is introducing a way to emulate a SW vDPA device in userspace (DPDK), and this SW vDPA device also supports vDPA framework. So it's not an alternative to existing DPDK vDPA framework :) >>> >>> Correct. >>> >>> When using DPDK vDPA, the datapath of a Vhost-user port is offloaded to >>> a compatible physical NIC (i.e. a NIC that implements Virtio rings >>> support), the control path remains the same as a regular Vhost-user >>> port, i.e. it provides a Vhost-user unix socket to the application (like >>> QEMU or DPDK Virtio-user PMD). >>> >>> When using Kernel vDPA, the datapath is also offloaded to a vDPA >>> compatible device, and the control path is managed by the vDPA bus. >>> It can either be consumed by a Kernel Virtio device (here Virtio-net) >>> when using Virtio-vDPA. In this case the device is exposed as a regular >>> netdev and, in the case of Kubernetes, can be used as primary interfaces >>> for the pods. >>> Or it can be exposed to user-space via Vhost-vDPA, a chardev that can be >>> seen as an alternative to Vhost-user sockets. In this case it can for >>> example be used by QEMU or DPDK Virtio-user PMD. In Kubernetes, it can >>> be used as a secondary interface. >>> >>> Now comes VDUSE. VDUSE is a Kernel vDPA device, but instead of being a >>> physical device where the Virtio datapath is offloaded, the Virtio >>> datapath is offloaded to a user-space application. With this series, a >>> DPDK application, like OVS-DPDK for instance, can create VDUSE device >>> and expose them either as regular netdev when binding them to Kernel >>> Virtio-net driver via Virtio-vDPA, or as Vhost-vDPA interface to be >>> consumed by another userspace appliation like QEMU or DPDK application >>> using Virtio-user PMD. With this solution, OVS-DPDK could serve both >>> primary and secondary interfaces of Kubernetes pods.
Re: [PATCH] reorder: improve buffer structure layout
On Fri, 14 Apr 2023 10:43:43 +0200
Volodymyr Fialko wrote:
> diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
> index f55f383700..7418202b04 100644
> --- a/lib/reorder/rte_reorder.c
> +++ b/lib/reorder/rte_reorder.c
> @@ -46,9 +46,10 @@ struct rte_reorder_buffer {
> char name[RTE_REORDER_NAMESIZE];
> uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
> unsigned int memsize; /**< memory area size of reorder buffer */
> + int is_initialized; /**< flag indicates that buffer was initialized */
> +
> struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
> struct cir_buffer order_buf; /**< buffer used to reorder entries */
> - int is_initialized;
> } __rte_cache_aligned;
>
> static void
Since this is ABI change it will have to wait for 23.11 release
Re: [PATCH] reorder: improve buffer structure layout
On Fri, Apr 14, 2023 at 07:52:30AM -0700, Stephen Hemminger wrote:
> On Fri, 14 Apr 2023 10:43:43 +0200
> Volodymyr Fialko wrote:
>
> > diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
> > index f55f383700..7418202b04 100644
> > --- a/lib/reorder/rte_reorder.c
> > +++ b/lib/reorder/rte_reorder.c
> > @@ -46,9 +46,10 @@ struct rte_reorder_buffer {
> > char name[RTE_REORDER_NAMESIZE];
> > uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
> > unsigned int memsize; /**< memory area size of reorder buffer */
> > + int is_initialized; /**< flag indicates that buffer was initialized */
> > +
> > struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
> > struct cir_buffer order_buf; /**< buffer used to reorder entries */
> > - int is_initialized;
> > } __rte_cache_aligned;
> >
> > static void
>
> Since this is ABI change it will have to wait for 23.11 release
It shouldn't be an ABI change. This struct is defined in a C file, rather
than a header, so is not exposed to end applications.
/Bruce
[PATCH v2] kni: fix build with Linux 6.3
KNI calls `get_user_pages_remote()` API which is using `FOLL_TOUCH`
flag, but `FOLL_TOUCH` is no more in public headers since v6.3,
causing a build error.
`FOLL_*` defines in Linux kernel first moved to another header [1],
later some of them moved to memory subsystem internal header [2] for 6.3
`get_user_pages_remote()` already sets `FOLL_TOUCH` internally,
no need to set this flag externally anyway, moving flag from the call
altogether.
[1]
Commit b5054174ac7c ("mm: move FOLL_* defs to mm_types.h")
[2]
Commit 2c2241081f7d ("mm/gup: move private gup FOLL_ flags to internal.h")
Signed-off-by: Ferruh Yigit
---
Cc: David Marchand
Cc: Vamsi Krishna Attunuru
v2:
* Remove 'FOLL_TOUCH' flag from 'get_user_pages_remote()'
---
kernel/linux/kni/kni_dev.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index a2c6d9fc1a53..21bfb6890e30 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -105,11 +105,9 @@ static inline phys_addr_t iova_to_phys(struct task_struct
*tsk,
/* Read one page struct info */
#ifdef HAVE_TSK_IN_GUP
- ret = get_user_pages_remote(tsk, tsk->mm, iova, 1,
- FOLL_TOUCH, &page, NULL, NULL);
+ ret = get_user_pages_remote(tsk, tsk->mm, iova, 1, 0, &page, NULL,
NULL);
#else
- ret = get_user_pages_remote(tsk->mm, iova, 1,
- FOLL_TOUCH, &page, NULL, NULL);
+ ret = get_user_pages_remote(tsk->mm, iova, 1, 0, &page, NULL, NULL);
#endif
if (ret < 0)
return 0;
--
2.34.1
Re: [PATCH] kni: fix build with Linux 6.3
On 3/20/2023 1:01 PM, David Marchand wrote:
> On Mon, Mar 20, 2023 at 1:10 PM David Marchand
> wrote:
>>
>> On Tue, Feb 28, 2023 at 9:45 PM David Marchand
>> wrote:
>>>
>>> On Tue, Feb 28, 2023 at 6:29 PM Ferruh Yigit wrote:
KNI calls `get_user_pages_remote()` API which is using `FOLL_TOUCH`
flag, but `FOLL_TOUCH` is no more in public headers since v6.3,
causing a build error.
>>>
>>> Something looks strange with what kni was doing.
>>>
>>> Looking at get_user_pages_remote implementation, I see it internally
>>> passes FOLL_TOUCH in addition to passed gup_flags.
>>> And looking at FOLL_TOUCH definition, it seems natural (to me) that
>>> this flag would be handled internally.
>>>
>>> Maybe it changed over time... but then the question is when did
>>> passing FOLL_TOUCH become unneeded?
>>
>> Here is some more info.
>>
>> get_user_pages_remote() was added in kernel commit 1e9877902dc7
>> ("mm/gup: Introduce get_user_pages_remote()").
>> At this time, it was passing the FOLL_TOUCH flag internally.
>>
>> +long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
>> + unsigned long start, unsigned long nr_pages,
>> + int write, int force, struct page **pages,
>> + struct vm_area_struct **vmas)
>> {
>> return __get_user_pages_locked(tsk, mm, start, nr_pages, write,
>> force,
>> - pages, vmas, NULL, false, FOLL_TOUCH);
>> + pages, vmas, NULL, false,
>> + FOLL_TOUCH | FOLL_REMOTE);
>> +}
>> +EXPORT_SYMBOL(get_user_pages_remote);
>>
>> get_user_pages_remote() later gained the ability to pass gup flags in
>> kernel commit 9beae1ea8930 ("mm: replace get_user_pages_remote()
>> write/force parameters with gup_flags").
>> But FOLL_TOUCH was still added internally.
>>
>> long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
>> unsigned long start, unsigned long nr_pages,
>> - int write, int force, struct page **pages,
>> + unsigned int gup_flags, struct page **pages,
>> struct vm_area_struct **vmas)
>> {
>> - unsigned int flags = FOLL_TOUCH | FOLL_REMOTE;
>> -
>> - if (write)
>> - flags |= FOLL_WRITE;
>> - if (force)
>> - flags |= FOLL_FORCE;
>> -
>> return __get_user_pages_locked(tsk, mm, start, nr_pages, pages, vmas,
>> - NULL, false, flags);
>> + NULL, false,
>> + gup_flags | FOLL_TOUCH | FOLL_REMOTE);
>> }
>>
>>
>> There were other changes in this area of the kernel code, but I did
>> not notice a change in relation with FOLL_TOUCH.
>>
>> So I think the dpdk commit e73831dc6c26 ("kni: support userspace VA")
>> uselessly introduced call to this flag and we can remove it.
>> Adding author and reviewers of this change.
>
> Alternatively, we could go with passing 0 in flags when FOLL_TOUCH is
> not exported.
> Something like:
>
> diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h
> index 7aa6cd9fca..3164a48971 100644
> --- a/kernel/linux/kni/compat.h
> +++ b/kernel/linux/kni/compat.h
> @@ -129,6 +129,14 @@
> */
> #if KERNEL_VERSION(4, 10, 0) <= LINUX_VERSION_CODE
> #define HAVE_IOVA_TO_KVA_MAPPING_SUPPORT
> +
> +/*
> + * get_user_pages_remote() should not require the flag FOLL_TOUCH to be
> passed.
> + * Simply pass it as 0 when this flag is internal and not exported anymore.
> + */
> +#ifndef FOLL_TOUCH
> +#define FOLL_TOUCH 0
> +#endif
> #endif
>
> #if KERNEL_VERSION(5, 6, 0) <= LINUX_VERSION_CODE || \
>
>
In KNI, 'get_user_pages_remote()' API is called after kernel version
4.10 and after that point 'FOLL_TOUCH' is set internally anyway as you
highlighted.
So I think we can remove setting 'FOLL_TOUCH' for all cases instead of
defining it internally, I have sent v2 according this.
Re: [PATCH] reorder: improve buffer structure layout
On Fri, 14 Apr 2023 15:54:13 +0100
Bruce Richardson wrote:
> On Fri, Apr 14, 2023 at 07:52:30AM -0700, Stephen Hemminger wrote:
> > On Fri, 14 Apr 2023 10:43:43 +0200
> > Volodymyr Fialko wrote:
> >
> > > diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
> > > index f55f383700..7418202b04 100644
> > > --- a/lib/reorder/rte_reorder.c
> > > +++ b/lib/reorder/rte_reorder.c
> > > @@ -46,9 +46,10 @@ struct rte_reorder_buffer {
> > > char name[RTE_REORDER_NAMESIZE];
> > > uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
> > > unsigned int memsize; /**< memory area size of reorder buffer */
> > > + int is_initialized; /**< flag indicates that buffer was initialized */
> > > +
> > > struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
> > > struct cir_buffer order_buf; /**< buffer used to reorder entries */
> > > - int is_initialized;
> > > } __rte_cache_aligned;
> > >
> > > static void
> >
> > Since this is ABI change it will have to wait for 23.11 release
>
> It shouldn't be an ABI change. This struct is defined in a C file, rather
> than a header, so is not exposed to end applications.
>
> /Bruce
Sorry, Bruce is right.
You might want to use uint8_t or bool for a simple flag.
Re: [PATCH] net/gve: Check whether the driver is compatible with the device presented.
On 4/14/2023 10:05 AM, Guo, Junfeng wrote:
> Hi Ferruh,
>
> Here is the summary of the dependency of related patches:
>
> P1: necessary headers update
> https://patchwork.dpdk.org/project/dpdk/list/?series=27647&state=*
> P2: minor update for base code
> https://patchwork.dpdk.org/project/dpdk/list/?series=27653&state=*
> P3: gve PMD enhancement
> https://patchwork.dpdk.org/project/dpdk/list/?series=27687&state=*
> P4: add new AdminQ cmd to verify drv cap
> https://patchwork.dpdk.org/project/dpdk/list/?series=27703&state=*
>
> The merging order could be: P1 > P2 > P3 > P4, due to the dependency.
> Just to inform you about this here. Thanks for the review!
>
Thanks Junfeng, this is useful.
Btw, we have a defined syntax for this [1], having it in commit log may
help automated CI to parse it and apply in correct order (when it is
fully supported in CI :) )
[1]
https://doc.dpdk.org/guides/contributing/patches.html#patch-dependencies
Depends-on: series-N ("Title of the series")
or
Depends-on: patch-N ("Title of the patch")
And I just recognized that syntax is not clear for multiple dependency
case, we should define it better.
Re: [PATCH v2 1/6] bus/cdx: introduce cdx bus
On 4/13/2023 2:26 PM, Nipun Gupta wrote:
> CDX bus supports multiple type of devices, which can be
> exposed to user-space via vfio-cdx.
>
> vfio-cdx provides the MMIO IO_MEMORY regions as well as the
> DMA interface for the device (IOMMU).
>
> This support aims to enable the DPDK to support the cdx
> devices in user-space using VFIO interface.
>
> Signed-off-by: Nipun Gupta
<...>
> +/* map a particular resource from a file */
> +void *
> +cdx_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
> + int additional_flags)
> +{
> + void *mapaddr;
> +
> + /* Map the cdx MMIO memory resource of device */
> + mapaddr = rte_mem_map(requested_addr, size,
> + RTE_PROT_READ | RTE_PROT_WRITE,
> + RTE_MAP_SHARED | additional_flags, fd, offset);
> + if (mapaddr == NULL) {
> + CDX_BUS_ERR("%s(): cannot map resource(%d, %p, 0x%zx, 0x%llx):
> %s (%p)",
> + __func__, fd, requested_addr, size,
> + (unsigned long long)offset,
`checkpatches.sh` complains about '%l' usage, and 'offset' seems defined
as 'off_t' type.
As far as I can see 'off_t' is not part of C standard (but posix
standard), and it is signed, also not clear if 32 bits or 64 bits.
Since caller of this function already passes parameter with 'uint64_t'
type, why not change the 'offset' type of this function to 'uint64_t'
for simplification, and use 'PRIu64' format specifier?
Re: [PATCH v2 3/6] bus/cdx: add support for MSI
On 4/13/2023 2:27 PM, Nipun Gupta wrote: > MSI's are exposed to the devices using VFIO (vfio-cdx). This > patch uses the same to add support for MSI for the devices on > the cdx bus. > > Signed-off-by: Nipun Gupta This commit also adds two new internal eal APIs and extends "struct rte_intr_handle", can you please document this in the commit log?
Re: [PATCH v2 5/6] bus: enable cdx bus
On 4/13/2023 2:27 PM, Nipun Gupta wrote: > enable the compilation of cdx bus > > Signed-off-by: Nipun Gupta > --- > drivers/bus/meson.build | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build > index 6d2520c543..a78b4283bf 100644 > --- a/drivers/bus/meson.build > +++ b/drivers/bus/meson.build > @@ -3,6 +3,7 @@ > > drivers = [ > 'auxiliary', > +'cdx', > 'dpaa', > 'fslmc', > 'ifpga', Why not squash this to the first patch? I think better to enable bus with the first patch and gradually expand the feature, this way each patch is checked that it builds fine. There are cases some interim patches can't be built successfully, which may required enabling after a few patches, but I think this is not the case.
Re: [PATCH v2 0/6] add support for CDX bus
On 4/13/2023 2:26 PM, Nipun Gupta wrote: > Support AMD CDX bus, for FPGA based CDX devices. The CDX > devices are memory mapped on system bus for embedded CPUs. > > It uses sysfs interface and the vfio-cdx driver to discover > and initialize the CDX devices. > > The patches are intended for DPDK 23.07 release, and have been sent > as an RFC as patches are yet to be merged in Linux. > not RFC anymore > The CDX bus and VFIO support is available at Xilinx open source tree: > https://github.com/Xilinx/linux-xlnx (drivers/cdx/ and drivers/vfio/cdx) > > Linux CDX bus patches has been added into linux next: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cdx > > VFIO patches are also submitted in upstream: > https://www.spinics.net/lists/kvm/msg310623.html > > CDX is a Hardware Architecture designed for AMD FPGA devices. It > consists of mechanism for interaction between FPGA, Firmware and > the APUs (Application CPUs). > Firmware resides on RPU (Realtime CPUs) which interacts with > the FPGA program manager and the APUs. The RPU provides memory-mapped > interface (RPU if) which is used to communicate with APUs. > > VFIO CDX driver provides the CDX device resources like MMIO and interrupts > to map to user-space. DPDK CDX bus uses sysfs interface and the vfio-cdx > driver to discover and initialize the CDX devices for user-space > applications. > Overall looks good to me, there are a few warnings by `check-git-log.sh`, can you please check? Also what do you think to add a release notes update for new bus? > Changes v1->v2: > - Moved file rte_cdx_bus.h to internal bus_cdx_driver.h > and added this file to deivce_cdx_headers > - Moved cdx.h to private.h > - Removed rte_ prefix from the static symbols in .c files. > > Changes RFC->v1: > - Marked few API's as internal which were not required > to be provided to user. > > Nipun Gupta (6): > bus/cdx: introduce cdx bus > bus/cdx: add dma map and unmap support > bus/cdx: add support for MSI > bus/cdx: support plug unplug and dev iterator > bus: enable cdx bus > config/arm: add AMD CDX > > MAINTAINERS| 5 + > config/arm/arm64_cdx_linux_gcc | 17 + > config/arm/meson.build | 14 + > drivers/bus/cdx/bus_cdx_driver.h | 227 > drivers/bus/cdx/cdx.c | 694 + > drivers/bus/cdx/cdx_logs.h | 37 ++ > drivers/bus/cdx/cdx_vfio.c | 619 ++ > drivers/bus/cdx/meson.build| 12 + > drivers/bus/cdx/private.h | 49 ++ > drivers/bus/cdx/version.map| 13 + > drivers/bus/meson.build| 1 + > lib/eal/common/eal_common_interrupts.c | 21 + > lib/eal/common/eal_interrupts.h| 1 + > lib/eal/include/rte_interrupts.h | 32 ++ > lib/eal/version.map| 2 + > 15 files changed, 1744 insertions(+) > create mode 100644 config/arm/arm64_cdx_linux_gcc > create mode 100644 drivers/bus/cdx/bus_cdx_driver.h > create mode 100644 drivers/bus/cdx/cdx.c > create mode 100644 drivers/bus/cdx/cdx_logs.h > create mode 100644 drivers/bus/cdx/cdx_vfio.c > create mode 100644 drivers/bus/cdx/meson.build > create mode 100644 drivers/bus/cdx/private.h > create mode 100644 drivers/bus/cdx/version.map >
Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC
On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > Sent: Thursday, 13 April 2023 23.26 > > > > For now expand a lot of common rte macros empty. The catch here is we > > need to test that most of the macros do what they should but at the same > > time they are blocking work needed to bootstrap of the unit tests. > > > > Later we will return and provide (where possible) expansions that work > > correctly for msvc and where not possible provide some alternate macros > > to achieve the same outcome. > > > > Signed-off-by: Tyler Retzlaff > > --- > > lib/eal/include/rte_branch_prediction.h | 8 ++ > > lib/eal/include/rte_common.h| 45 > > + > > lib/eal/include/rte_compat.h| 20 +++ > > 3 files changed, 73 insertions(+) > > > > diff --git a/lib/eal/include/rte_branch_prediction.h > > b/lib/eal/include/rte_branch_prediction.h > > index 0256a9d..d9a0224 100644 > > --- a/lib/eal/include/rte_branch_prediction.h > > +++ b/lib/eal/include/rte_branch_prediction.h > > @@ -25,7 +25,11 @@ > > * > > */ > > #ifndef likely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define likely(x) __builtin_expect(!!(x), 1) > > +#else > > +#define likely(x) (x) > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), > and likely() must return Boolean (0 or 1). yes, you're right. will fix. > > > +#endif > > #endif /* likely */ > > > > /** > > @@ -39,7 +43,11 @@ > > * > > */ > > #ifndef unlikely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define unlikely(x)__builtin_expect(!!(x), 0) > > +#else > > +#define unlikely(x)(x) > > This must also be (!!(x)), for the same reason as above. ack > > > +#endif > > #endif /* unlikely */ > > > > #ifdef __cplusplus > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h > > index 2f464e3..1bdaa2d 100644 > > --- a/lib/eal/include/rte_common.h > > +++ b/lib/eal/include/rte_common.h > > @@ -65,7 +65,11 @@ > > /** > > * Force alignment > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > +#else > > +#define __rte_aligned(a) > > +#endif > > It should be reviewed that __rte_aligned() is only used for optimization > purposes, and is not required for DPDK to function properly. so to expand on what i have in mind (and explain why i leave it expanded empty for now) while msvc has a __declspec for align there is a mismatch between where gcc and msvc want it placed to control alignment of objects. msvc support won't be functional in 23.07 because of atomics. so once we reach the 23.11 cycle (where we can merge c11 changes) it means we can also use standard _Alignas which can accomplish the same thing but portably. full disclosure the catch is i still have to properly locate the that does the alignment and some small questions about the expansion and use of the existing macro. on the subject of DPDK requiring proper alignment, you're right it is generally for performance but also for pre-c11 atomics. one question i have been asking myself is would the community see value in more compile time assertions / testing of the size and alignment of structures and offset of structure fields? we have a few key RTE_BUILD_BUG_ON() assertions but i've discovered they don't offer comprehensive protection. > > > > > #ifdef RTE_ARCH_STRICT_ALIGN > > typedef uint64_t unaligned_uint64_t __rte_aligned(1); > > @@ -80,16 +84,29 @@ > > /** > > * Force a structure to be packed > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_packed __attribute__((__packed__)) > > +#else > > +#define __rte_packed > > +#endif > > Similar comment as for __rte_aligned(); however, I consider it more likely > that structure packing is a functional requirement, and not just used for > optimization. Based on my experience, it may be used for packing network > structures; perhaps not in DPDK itself but maybe in DPDK applications. so interestingly i've discovered this is kind of a mess and as you note some places we can't just "fix" it for abi compatibility reasons. in some instances the packing is being applied to structures where it is essentially a noop. i.e. natural alignment gets you the same thing so it is superfluous. in some instances the packing is being applied to structures that are private and it appears to be completely unnecessary e.g. some structure that isn't nested into something else and sizeof() or offsetof() fields don't matter in the context of their use. in some instances it is completely necessary usually when type punning buffers containing network framing etc... unfortunately the standard doesn't offer me an out here as there is an issue of placement of the pragma/attributes that do the packing. for places it isn't needed it, whatever i just expand empty. for places it is superfluous again because msvc has no stable abi (w
Re: [PATCH] reorder: improve buffer structure layout
On Fri, Apr 14, 2023 at 10:26:26AM +0100, Bruce Richardson wrote:
> On Fri, Apr 14, 2023 at 10:43:43AM +0200, Volodymyr Fialko wrote:
> > Rearrange the reorder buffer structure to prevent padding to extra one
> > cache line.
> >
> > Current layout:
> > struct rte_reorder_buffer {
> > char name[RTE_REORDER_NAMESIZE];
> > uint32_t min_seqn;
> > unsigned int memsize;
> > // -> padding to cache align (cir_buffer is also cache aligned)
> > struct cir_buffer ready_buf;
> > struct cir_buffer order_buf;
> > int is_initialized;
> > // -> padding to cache align, eat whole line
> > };
> >
> > New layout:
> > struct rte_reorder_buffer {
> > char name[RTE_REORDER_NAMESIZE];
> > uint32_t min_seqn;
> > unsigned int memsize;
> > int is_initialized;
> > // -> padding to cache align (cir_buffer is also cache aligned)
> > struct cir_buffer ready_buf;
> > struct cir_buffer order_buf;
> > // -> no padding
> > };
> >
> > Signed-off-by: Volodymyr Fialko
> > ---
>
> Acked-by: Bruce Richardson
>
> > lib/reorder/rte_reorder.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/reorder/rte_reorder.c b/lib/reorder/rte_reorder.c
> > index f55f383700..7418202b04 100644
> > --- a/lib/reorder/rte_reorder.c
> > +++ b/lib/reorder/rte_reorder.c
> > @@ -46,9 +46,10 @@ struct rte_reorder_buffer {
> > char name[RTE_REORDER_NAMESIZE];
> > uint32_t min_seqn; /**< Lowest seq. number that can be in the buffer */
> > unsigned int memsize; /**< memory area size of reorder buffer */
> > + int is_initialized; /**< flag indicates that buffer was initialized */
> > +
>
> Since we are moving it, it might be an opportunity to change it from "int"
> to "bool".
+1
>
> > struct cir_buffer ready_buf; /**< temp buffer for dequeued entries */
> > struct cir_buffer order_buf; /**< buffer used to reorder entries */
> > - int is_initialized;
> > } __rte_cache_aligned;
> >
> > static void
> > --
> > 2.34.1
> >
[PATCH v2 01/22] net: add PDCP header
From: Volodymyr Fialko
Add PDCP protocol header to be used for supporting PDCP protocol
processing.
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
doc/api/doxy-api-index.md | 3 +-
lib/net/meson.build | 1 +
lib/net/rte_pdcp_hdr.h| 140 ++
3 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 lib/net/rte_pdcp_hdr.h
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index c709fd48ad..debbe4134f 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -127,7 +127,8 @@ The public API headers are grouped by topics:
[Geneve](@ref rte_geneve.h),
[eCPRI](@ref rte_ecpri.h),
[L2TPv2](@ref rte_l2tpv2.h),
- [PPP](@ref rte_ppp.h)
+ [PPP](@ref rte_ppp.h),
+ [PDCP hdr](@ref rte_pdcp_hdr.h)
- **QoS**:
[metering](@ref rte_meter.h),
diff --git a/lib/net/meson.build b/lib/net/meson.build
index 379d161ee0..bd56f91c22 100644
--- a/lib/net/meson.build
+++ b/lib/net/meson.build
@@ -22,6 +22,7 @@ headers = files(
'rte_geneve.h',
'rte_l2tpv2.h',
'rte_ppp.h',
+'rte_pdcp_hdr.h',
)
sources = files(
diff --git a/lib/net/rte_pdcp_hdr.h b/lib/net/rte_pdcp_hdr.h
new file mode 100644
index 00..87ecd379c4
--- /dev/null
+++ b/lib/net/rte_pdcp_hdr.h
@@ -0,0 +1,140 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef RTE_PDCP_HDR_H
+#define RTE_PDCP_HDR_H
+
+/**
+ * @file
+ *
+ * PDCP-related defines
+ *
+ * Based on - ETSI TS 138 323 V17.1.0 (2022-08)
+ *
https://www.etsi.org/deliver/etsi_ts/138300_138399/138323/17.01.00_60/ts_138323v170100p.pdf
+ */
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * 4.3.1
+ *
+ * Indicate the maximum supported size of a PDCP Control PDU.
+ */
+#define RTE_PDCP_CTRL_PDU_SIZE_MAX 9000u
+
+/**
+ * Indicate type of control information included in the corresponding PDCP
+ * Control PDU.
+ */
+enum rte_pdcp_ctrl_pdu_type {
+ RTE_PDCP_CTRL_PDU_TYPE_STATUS_REPORT = 0,
+ RTE_PDCP_CTRL_PDU_TYPE_ROHC_FEEDBACK = 1,
+ RTE_PDCP_CTRL_PDU_TYPE_EHC_FEEDBACK = 2,
+ RTE_PDCP_CRTL_PDU_TYPE_UDC_FEEDBACK = 3,
+};
+
+/**
+ * 6.3.7 D/C
+ *
+ * This field indicates whether the corresponding PDCP PDU is a
+ * PDCP Data PDU or a PDCP Control PDU.
+ */
+enum rte_pdcp_pdu_type {
+ RTE_PDCP_PDU_TYPE_CTRL = 0,
+ RTE_PDCP_PDU_TYPE_DATA = 1,
+};
+
+/**
+ * 6.2.2.1 Data PDU for SRBs
+ */
+__extension__
+struct rte_pdcp_cp_data_pdu_sn_12_hdr {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t sn_11_8 : 4;/**< Sequence number bits 8-11 */
+ uint8_t r : 4; /**< Reserved */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t r : 4; /**< Reserved */
+ uint8_t sn_11_8 : 4;/**< Sequence number bits 8-11 */
+#endif
+ uint8_t sn_7_0; /**< Sequence number bits 0-7 */
+};
+
+/**
+ * 6.2.2.2 Data PDU for DRBs and MRBs with 12 bits PDCP SN
+ */
+__extension__
+struct rte_pdcp_up_data_pdu_sn_12_hdr {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t sn_11_8 : 4;/**< Sequence number bits 8-11 */
+ uint8_t r : 3; /**< Reserved */
+ uint8_t d_c : 1;/**< D/C bit */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t d_c : 1;/**< D/C bit */
+ uint8_t r : 3; /**< Reserved */
+ uint8_t sn_11_8 : 4;/**< Sequence number bits 8-11 */
+#endif
+ uint8_t sn_7_0; /**< Sequence number bits 0-7 */
+};
+
+/**
+ * 6.2.2.3 Data PDU for DRBs and MRBs with 18 bits PDCP SN
+ */
+__extension__
+struct rte_pdcp_up_data_pdu_sn_18_hdr {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t sn_17_16 : 2; /**< Sequence number bits 16-17 */
+ uint8_t r : 5; /**< Reserved */
+ uint8_t d_c : 1;/**< D/C bit */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t d_c : 1;/**< D/C bit */
+ uint8_t r : 5; /**< Reserved */
+ uint8_t sn_17_16 : 2; /**< Sequence number bits 16-17 */
+#endif
+ uint8_t sn_15_8;/**< Sequence number bits 8-15 */
+ uint8_t sn_7_0; /**< Sequence number bits 0-7 */
+};
+
+/**
+ * 6.2.3.1 Control PDU for PDCP status report
+ */
+__extension__
+struct rte_pdcp_up_ctrl_pdu_hdr {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t r : 4; /**< Reserved */
+ uint8_t pdu_type : 3; /**< Control PDU type */
+ uint8_t d_c : 1;/**< D/C bit */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t d_c : 1;/**< D/C bit */
+ uint8_t pdu_type : 3; /**< Control PDU type */
+ uint8_t r : 4; /**< Reserved */
+#endif
+ /**
+* 6.3.9 FMC
+*
+* First Missing COUNT. This field indicates the COUNT value of the
+* first missing PDCP SDU within the reordering window, i.e. RX_DELIV.
+*/
+ rte_be32_t fmc;
+ /**
+
[PATCH v2 00/22] lib: add pdcp protocol
Add Packet Data Convergence Protocol (PDCP) processing library.
The library is similar to lib_ipsec which provides IPsec processing
capabilities in DPDK.
PDCP would involve roughly the following operations,
1. Transfer of user plane data
2. Transfer of control plane data
3. Header compression
4. Uplink data compression
5. Ciphering and integrity protection
PDCP library provides following control path APIs that is used to
configure various PDCP entities,
1. rte_pdcp_entity_establish()
2. rte_pdcp_entity_suspend()
3. rte_pdcp_entity_release()
PDCP process is split into 2 parts. One before crypto processing
(rte_pdcp_pkt_pre_process()) and one after crypto processing
(rte_pdcp_pkt_post_process()). Since cryptodev dequeue can return crypto
operations belonging to multiple entities, rte_pdcp_pkt_crypto_group()
is added to help grouping crypto operations belonging to same entity.
Similar to lib IPsec, lib PDCP would allow application to use same API
sequence while leveraging protocol offload features enabled by rte_security
library. Lib PDCP would internally change the handles registered for
*pre_process* and *post_process* based on features enabled in the entity.
Lib PDCP would create the required sessions on the device provided in entity to
minimize the application requirements. Also, the crypto_op allocation and free
would also be done internally by lib PDCP to allow the library to create
crypto ops as required for the input packets. For example, when control PDUs are
received, no cryptodev enqueue-dequeue is expected for the same and lib PDCP
is expected to handle it differently.
Lib PDCP utilizes reorder library for implementing in-order delivery. It
utilizes bitmap library for implementing status reports and track the COUNT
value of the packets received. To allow application to choose timer
implementation of choice, lib PDCP allows application to configure handles that
can be used for starting & stopping timers. Upon expiry, application can call
corresponding PDCP API(``rte_pdcp_t_reordering_expiry_handle``) for handling the
event. Unit tests are added to verify both rte_timer based timers as well as
rte_eventdev based timers.
PDCP tracks the sequence number of the received packets and during events such
as re-establishment, it is required to generate reports and transmit to the
peer. This series introduces ``rte_pdcp_control_pdu_create`` for handling
control PDU generation.
Changes in v2:
- Added control PDU handling
- Added t-Reordering timer
- Added in-order delivery
- Added status PDU generation
- Rebased on top of new features added in reorder library
- Split base patch
- Increased test coverage
- Improved thread safety
Changes from RFC
- Implementation for all APIs covering basic control plane & user plane packets
- Unit test leveraging existing PDCP vectors available in test_cryptodev
- Unit test performing both UL & DL operations to verify various protocol
features
- Updated documentation
Sample application sequence:
struct rte_mbuf **out_mb, *pkts[MAX_BURST_SIZE];
struct rte_crypto_op *cop[MAX_BURST_SIZE];
struct rte_pdcp_group grp[MAX_BURST_SIZE];
struct rte_pdcp_entity *pdcp_entity;
int nb_max_out_mb, ret, nb_grp;
/* Create PDCP entity */
pdcp_entity = rte_pdcp_entity_establish(&conf);
/**
* Allocate buffer for holding mbufs returned during PDCP suspend,
* release & post-process APIs.
*/
/* Max packets that can be cached in entity + burst size */
nb_max_out_mb = pdcp_entity->max_pkt_cache + 1;
out_mb = rte_malloc(NULL, nb_max_out_mb * sizeof(uintptr_t), 0);
if (out_mb == NULL) {
/* Handle error */
}
while (1) {
/* Receive packet and form mbuf */
/**
* Prepare packets for crypto operation. Following operations
* would be done,
*
* Transmitting entity/UL (only data PDUs):
* - Perform compression
* - Assign sequence number
* - Add PDCP header
* - Create & prepare crypto_op
* - Prepare IV for crypto operation (auth_gen, encrypt)
* - Save original PDCP SDU (during PDCP re-establishment,
*unconfirmed PDCP SDUs need to crypto processed again and
*transmitted/re-transmitted)
*
* Receiving entity/DL:
* - Any control PDUs received would be processed and
*appropriate actions taken. If data PDU, continue.
* - Determine sequence number (based on HFN & per packet SN)
* - Prepare crypto_op
* - Prepare IV for crypto operation (decrypt, auth_verify)
*/
nb_success = rte_pdcp_pkt_pre_process(pdcp_entity, pkts, cop,
[PATCH v2 02/22] lib: add pdcp protocol
Add Packet Data Convergence Protocol (PDCP) processing library.
The library is similar to lib_ipsec which provides IPsec processing
capabilities in DPDK.
PDCP would involve roughly the following options,
1. Transfer of user plane data
2. Transfer of control plane data
3. Header compression
4. Uplink data compression
5. Ciphering and integrity protection
PDCP library provides following control path APIs that is used to
configure various PDCP entities,
1. rte_pdcp_entity_establish()
2. rte_pdcp_entity_suspend()
3. rte_pdcp_entity_release()
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
doc/api/doxy-api-index.md | 3 +-
doc/api/doxy-api.conf.in | 1 +
lib/meson.build | 1 +
lib/pdcp/meson.build | 17 +
lib/pdcp/pdcp_crypto.c| 21 +
lib/pdcp/pdcp_crypto.h| 15
lib/pdcp/pdcp_entity.h| 95 +++
lib/pdcp/pdcp_process.c | 138 +
lib/pdcp/pdcp_process.h | 13
lib/pdcp/rte_pdcp.c | 138 +
lib/pdcp/rte_pdcp.h | 157 ++
lib/pdcp/version.map | 10 +++
12 files changed, 608 insertions(+), 1 deletion(-)
create mode 100644 lib/pdcp/meson.build
create mode 100644 lib/pdcp/pdcp_crypto.c
create mode 100644 lib/pdcp/pdcp_crypto.h
create mode 100644 lib/pdcp/pdcp_entity.h
create mode 100644 lib/pdcp/pdcp_process.c
create mode 100644 lib/pdcp/pdcp_process.h
create mode 100644 lib/pdcp/rte_pdcp.c
create mode 100644 lib/pdcp/rte_pdcp.h
create mode 100644 lib/pdcp/version.map
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index debbe4134f..cd7a6cae44 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -128,7 +128,8 @@ The public API headers are grouped by topics:
[eCPRI](@ref rte_ecpri.h),
[L2TPv2](@ref rte_l2tpv2.h),
[PPP](@ref rte_ppp.h),
- [PDCP hdr](@ref rte_pdcp_hdr.h)
+ [PDCP hdr](@ref rte_pdcp_hdr.h),
+ [PDCP](@ref rte_pdcp.h)
- **QoS**:
[metering](@ref rte_meter.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index d230a19e1f..58789308a9 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -62,6 +62,7 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \
@TOPDIR@/lib/net \
@TOPDIR@/lib/pcapng \
@TOPDIR@/lib/pci \
+ @TOPDIR@/lib/pdcp \
@TOPDIR@/lib/pdump \
@TOPDIR@/lib/pipeline \
@TOPDIR@/lib/port \
diff --git a/lib/meson.build b/lib/meson.build
index 0812ce6026..d217c04ea9 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -64,6 +64,7 @@ libraries = [
'flow_classify', # flow_classify lib depends on pkt framework table lib
'graph',
'node',
+'pdcp', # pdcp lib depends on crypto and security
]
optional_libs = [
diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
new file mode 100644
index 00..ccaf426240
--- /dev/null
+++ b/lib/pdcp/meson.build
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(C) 2023 Marvell.
+
+if is_windows
+build = false
+reason = 'not supported on Windows'
+subdir_done()
+endif
+
+sources = files(
+'pdcp_crypto.c',
+'pdcp_process.c',
+'rte_pdcp.c',
+)
+headers = files('rte_pdcp.h')
+
+deps += ['mbuf', 'net', 'cryptodev', 'security']
diff --git a/lib/pdcp/pdcp_crypto.c b/lib/pdcp/pdcp_crypto.c
new file mode 100644
index 00..755e27ec9e
--- /dev/null
+++ b/lib/pdcp/pdcp_crypto.c
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include
+
+#include "pdcp_crypto.h"
+
+int
+pdcp_crypto_sess_create(struct rte_pdcp_entity *entity, const struct
rte_pdcp_entity_conf *conf)
+{
+ RTE_SET_USED(entity);
+ RTE_SET_USED(conf);
+ return 0;
+}
+
+void
+pdcp_crypto_sess_destroy(struct rte_pdcp_entity *entity)
+{
+ RTE_SET_USED(entity);
+}
diff --git a/lib/pdcp/pdcp_crypto.h b/lib/pdcp/pdcp_crypto.h
new file mode 100644
index 00..6563331d37
--- /dev/null
+++ b/lib/pdcp/pdcp_crypto.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef PDCP_CRYPTO_H
+#define PDCP_CRYPTO_H
+
+#include
+
+int pdcp_crypto_sess_create(struct rte_pdcp_entity *entity,
+ const struct rte_pdcp_entity_conf *conf);
+
+void pdcp_crypto_sess_destroy(struct rte_pdcp_entity *entity);
+
+#endif /* PDCP_CRYPTO_H */
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
new file mode 100644
index 00..ca1d56b516
--- /dev/null
+++ b/lib/pdcp/pdcp_entity.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef PDCP_ENTITY_H
+#define PDCP_ENTITY_H
+
+#include
+#i
[PATCH v2 03/22] pdcp: add pre and post-process
PDCP process is split into 2 parts. One before crypto processing
(rte_pdcp_pkt_pre_process()) and one after crypto processing
(rte_pdcp_pkt_post_process()). Functionality of pre-process &
post-process varies based on the type of entity. Registration of entity
specific function pointer allows skipping multiple checks that would
come in datapath otherwise.
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/rte_pdcp.h | 97
lib/pdcp/version.map | 3 ++
2 files changed, 100 insertions(+)
diff --git a/lib/pdcp/rte_pdcp.h b/lib/pdcp/rte_pdcp.h
index 33c355b05a..75dc569f66 100644
--- a/lib/pdcp/rte_pdcp.h
+++ b/lib/pdcp/rte_pdcp.h
@@ -22,10 +22,29 @@
extern "C" {
#endif
+/* Forward declarations */
+struct rte_pdcp_entity;
+
+/* PDCP pre-process function based on entity configuration */
+typedef uint16_t (*rte_pdcp_pre_p_t)(const struct rte_pdcp_entity *entity,
+struct rte_mbuf *mb[],
+struct rte_crypto_op *cop[],
+uint16_t num, uint16_t *nb_err);
+
+/* PDCP post-process function based on entity configuration */
+typedef uint16_t (*rte_pdcp_post_p_t)(const struct rte_pdcp_entity *entity,
+ struct rte_mbuf *in_mb[],
+ struct rte_mbuf *out_mb[],
+ uint16_t num, uint16_t *nb_err);
+
/**
* PDCP entity.
*/
struct rte_pdcp_entity {
+ /** Entity specific pre-process handle. */
+ rte_pdcp_pre_p_t pre_process;
+ /** Entity specific post-process handle. */
+ rte_pdcp_post_p_t post_process;
/**
* PDCP entities may hold packets for purposes of in-order delivery (in
* case of receiving PDCP entity) and re-transmission (in case of
@@ -150,6 +169,84 @@ int
rte_pdcp_entity_suspend(struct rte_pdcp_entity *pdcp_entity,
struct rte_mbuf *out_mb[]);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * For input mbufs and given PDCP entity pre-process the mbufs and prepare
+ * crypto ops that can be enqueued to the cryptodev associated with given
+ * session. Only error packets would be moved returned in the input buffer,
+ * *mb*, and it is the responsibility of the application to free the same.
+ *
+ * @param entity
+ * Pointer to the *rte_pdcp_entity* object the packets belong to.
+ * @param[in, out] mb
+ * The address of an array of *num* pointers to *rte_mbuf* structures
+ * which contain the input packets. Any error packets would be returned in
the
+ * same buffer.
+ * @param[out] cop
+ * The address of an array that can hold up to *num* pointers to
+ * *rte_crypto_op* structures. Crypto ops would be allocated by
+ * ``rte_pdcp_pkt_pre_process`` API.
+ * @param num
+ * The maximum number of packets to process.
+ * @param[out] nb_err
+ * Pointer to return the number of error packets returned in *mb*
+ * @return
+ * Count of crypto_ops prepared
+ */
+__rte_experimental
+static inline uint16_t
+rte_pdcp_pkt_pre_process(const struct rte_pdcp_entity *entity,
+struct rte_mbuf *mb[], struct rte_crypto_op *cop[],
+uint16_t num, uint16_t *nb_err)
+{
+ return entity->pre_process(entity, mb, cop, num, nb_err);
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * For input mbufs and given PDCP entity, perform PDCP post-processing of the
+ * mbufs.
+ *
+ * Input mbufs are the ones retrieved from crypto_ops dequeued from cryptodev
+ * and grouped by *rte_pdcp_pkt_crypto_group()*.
+ *
+ * The post-processed packets would be returned in the *out_mb* buffer.
+ * The resultant mbufs would be grouped into success packets and error packets.
+ * Error packets would be grouped in the end of the array and it is the
+ * responsibility of the application to handle the same.
+ *
+ * When in-order delivery is enabled, PDCP entity may buffer packets and would
+ * deliver packets only when all prior packets have been post-processed. That
+ * would result in returning more/less packets than enqueued.
+ *
+ * @param entity
+ * Pointer to the *rte_pdcp_entity* object the packets belong to.
+ * @param in_mb
+ * The address of an array of *num* pointers to *rte_mbuf* structures.
+ * @param[out] out_mb
+ * The address of an array of *num* pointers to *rte_mbuf* structures
+ * to output packets after PDCP post-processing.
+ * @param num
+ * The maximum number of packets to process.
+ * @param[out] nb_err
+ * The number of error packets returned in *out_mb* buffer.
+ * @return
+ * Count of packets returned in *out_mb* buffer.
+ */
+__rte_experimental
+static inline uint16_t
+rte_pdcp_pkt_post_process(const struct rte_pdcp_entity *entity,
+ struct rte_mbuf *in_mb[],
+
[PATCH v2 04/22] pdcp: add packet group
Crypto processing in PDCP is performed asynchronously by
rte_cryptodev_enqueue_burst() and rte_cryptodev_dequeue_burst(). Since
cryptodev dequeue can return crypto operations belonging to multiple
entities, rte_pdcp_pkt_crypto_group() is added to help grouping crypto
operations belonging to same entity.
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/meson.build | 1 +
lib/pdcp/rte_pdcp.h | 2 +
lib/pdcp/rte_pdcp_group.h | 125 ++
3 files changed, 128 insertions(+)
create mode 100644 lib/pdcp/rte_pdcp_group.h
diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
index ccaf426240..08679b743a 100644
--- a/lib/pdcp/meson.build
+++ b/lib/pdcp/meson.build
@@ -13,5 +13,6 @@ sources = files(
'rte_pdcp.c',
)
headers = files('rte_pdcp.h')
+indirect_headers += files('rte_pdcp_group.h')
deps += ['mbuf', 'net', 'cryptodev', 'security']
diff --git a/lib/pdcp/rte_pdcp.h b/lib/pdcp/rte_pdcp.h
index 75dc569f66..54f88e3fd3 100644
--- a/lib/pdcp/rte_pdcp.h
+++ b/lib/pdcp/rte_pdcp.h
@@ -247,6 +247,8 @@ rte_pdcp_pkt_post_process(const struct rte_pdcp_entity
*entity,
return entity->post_process(entity, in_mb, out_mb, num, nb_err);
}
+#include
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/pdcp/rte_pdcp_group.h b/lib/pdcp/rte_pdcp_group.h
new file mode 100644
index 00..cb322f55c7
--- /dev/null
+++ b/lib/pdcp/rte_pdcp_group.h
@@ -0,0 +1,125 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef RTE_PDCP_GROUP_H
+#define RTE_PDCP_GROUP_H
+
+/**
+ * @file rte_pdcp_group.h
+ *
+ * RTE PDCP grouping support.
+ * It is not recommended to include this file directly, include
+ * instead.
+ * Provides helper functions to process completed crypto-ops and group related
+ * packets by sessions they belong to.
+ */
+
+#include
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * Group packets belonging to same PDCP entity.
+ */
+struct rte_pdcp_group {
+ union {
+ uint64_t val;
+ void *ptr;
+ } id; /**< Grouped by value */
+ struct rte_mbuf **m; /**< Start of the group */
+ uint32_t cnt; /**< Number of entries in the group */
+ int32_t rc; /**< Status code associated with the group */
+};
+
+/**
+ * Take crypto-op as an input and extract pointer to related PDCP entity.
+ * @param cop
+ * The address of an input *rte_crypto_op* structure.
+ * @return
+ * The pointer to the related *rte_pdcp_entity* structure.
+ */
+static inline struct rte_pdcp_entity *
+rte_pdcp_en_from_cop(const struct rte_crypto_op *cop)
+{
+ void *sess = cop->sym[0].session;
+
+ return (struct rte_pdcp_entity *)
+ rte_cryptodev_sym_session_opaque_data_get(sess);
+}
+
+/**
+ * Take as input completed crypto ops, extract related mbufs and group them by
+ * *rte_pdcp_entity* they belong to. Mbuf for which the crypto operation has
+ * failed would be flagged using *RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED* flag
+ * in rte_mbuf.ol_flags. The crypto_ops would be freed after the grouping.
+ *
+ * Note that application must ensure only crypto-ops prepared by lib_pdcp is
+ * provided back to @see rte_pdcp_pkt_crypto_group().
+ *
+ * @param cop
+ * The address of an array of *num* pointers to the input *rte_crypto_op*
+ * structures.
+ * @param[out] mb
+ * The address of an array of *num* pointers to output *rte_mbuf* structures.
+ * @param[out] grp
+ * The address of an array of *num* to output *rte_pdcp_group* structures.
+ * @param num
+ * The maximum number of crypto-ops to process.
+ * @return
+ * Number of filled elements in *grp* array.
+ *
+ */
+static inline uint16_t
+rte_pdcp_pkt_crypto_group(struct rte_crypto_op *cop[], struct rte_mbuf *mb[],
+ struct rte_pdcp_group grp[], uint16_t num)
+{
+ uint32_t i, j = 0, n = 0;
+ void *ns, *ps = NULL;
+ struct rte_mbuf *m;
+
+ for (i = 0; i != num; i++) {
+ m = cop[i]->sym[0].m_src;
+ ns = cop[i]->sym[0].session;
+
+ m->ol_flags |= RTE_MBUF_F_RX_SEC_OFFLOAD;
+ if (cop[i]->status != RTE_CRYPTO_OP_STATUS_SUCCESS)
+ m->ol_flags |= RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED;
+
+ /* Different entity */
+ if (ps != ns) {
+
+ /* Finalize open group and start a new one */
+ if (ps != NULL) {
+ grp[n].cnt = mb + j - grp[n].m;
+ n++;
+ }
+
+ /* Start new group */
+ grp[n].m = mb + j;
+ ps = ns;
+ grp[n].id.ptr = rte_pdcp_en_from_cop(cop[i]);
+ }
+
+ mb[j++] = m;
+ rte_crypto_op_free(cop[i]);
+ }
+
+ /* Final
[PATCH v2 05/22] pdcp: add crypto session create and destroy
Add routines to create & destroy sessions. PDCP lib would take
crypto transforms as input and creates the session on the corresponding
device after verifying capabilities.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_crypto.c | 222 -
lib/pdcp/pdcp_crypto.h | 6 ++
2 files changed, 225 insertions(+), 3 deletions(-)
diff --git a/lib/pdcp/pdcp_crypto.c b/lib/pdcp/pdcp_crypto.c
index 755e27ec9e..0e6e7d99d8 100644
--- a/lib/pdcp/pdcp_crypto.c
+++ b/lib/pdcp/pdcp_crypto.c
@@ -2,20 +2,236 @@
* Copyright(C) 2023 Marvell.
*/
+#include
+#include
+#include
+#include
#include
#include "pdcp_crypto.h"
+#include "pdcp_entity.h"
+
+static int
+pdcp_crypto_caps_cipher_verify(uint8_t dev_id, const struct
rte_crypto_sym_xform *c_xfrm)
+{
+ const struct rte_cryptodev_symmetric_capability *cap;
+ struct rte_cryptodev_sym_capability_idx cap_idx;
+ int ret;
+
+ cap_idx.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+ cap_idx.algo.cipher = c_xfrm->cipher.algo;
+
+ cap = rte_cryptodev_sym_capability_get(dev_id, &cap_idx);
+ if (cap == NULL)
+ return -1;
+
+ ret = rte_cryptodev_sym_capability_check_cipher(cap,
c_xfrm->cipher.key.length,
+
c_xfrm->cipher.iv.length);
+
+ return ret;
+}
+
+static int
+pdcp_crypto_caps_auth_verify(uint8_t dev_id, const struct rte_crypto_sym_xform
*a_xfrm)
+{
+ const struct rte_cryptodev_symmetric_capability *cap;
+ struct rte_cryptodev_sym_capability_idx cap_idx;
+ int ret;
+
+ cap_idx.type = RTE_CRYPTO_SYM_XFORM_AUTH;
+ cap_idx.algo.auth = a_xfrm->auth.algo;
+
+ cap = rte_cryptodev_sym_capability_get(dev_id, &cap_idx);
+ if (cap == NULL)
+ return -1;
+
+ ret = rte_cryptodev_sym_capability_check_auth(cap,
a_xfrm->auth.key.length,
+
a_xfrm->auth.digest_length,
+ a_xfrm->auth.iv.length);
+
+ return ret;
+}
+
+static int
+pdcp_crypto_xfrm_validate(const struct rte_pdcp_entity_conf *conf,
+const struct rte_crypto_sym_xform *c_xfrm,
+const struct rte_crypto_sym_xform *a_xfrm,
+bool is_auth_then_cipher)
+{
+ uint16_t ciph_iv_len, auth_digest_len, auth_iv_len;
+ int ret;
+
+ /*
+* Uplink means PDCP entity is configured for transmit. Downlink means
PDCP entity is
+* configured for receive. When integrity protection is enabled, PDCP
always performs
+* digest-encrypted or auth-gen-encrypt for uplink (and
decrypt-auth-verify for downlink).
+* So for uplink, crypto chain would be auth-cipher while for downlink
it would be
+* cipher-auth.
+*
+* When integrity protection is not required, xform would be cipher
only.
+*/
+
+ if (c_xfrm == NULL)
+ return -EINVAL;
+
+ if (conf->pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_UPLINK) {
+
+ /* With UPLINK, if auth is enabled, it should be before cipher
*/
+ if (a_xfrm != NULL && !is_auth_then_cipher)
+ return -EINVAL;
+
+ /* With UPLINK, cipher operation must be encrypt */
+ if (c_xfrm->cipher.op != RTE_CRYPTO_CIPHER_OP_ENCRYPT)
+ return -EINVAL;
+
+ /* With UPLINK, auth operation (if present) must be generate */
+ if (a_xfrm != NULL && a_xfrm->auth.op !=
RTE_CRYPTO_AUTH_OP_GENERATE)
+ return -EINVAL;
+
+ } else if (conf->pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_DOWNLINK) {
+
+ /* With DOWNLINK, if auth is enabled, it should be after cipher
*/
+ if (a_xfrm != NULL && is_auth_then_cipher)
+ return -EINVAL;
+
+ /* With DOWNLINK, cipher operation must be decrypt */
+ if (c_xfrm->cipher.op != RTE_CRYPTO_CIPHER_OP_DECRYPT)
+ return -EINVAL;
+
+ /* With DOWNLINK, auth operation (if present) must be verify */
+ if (a_xfrm != NULL && a_xfrm->auth.op !=
RTE_CRYPTO_AUTH_OP_VERIFY)
+ return -EINVAL;
+
+ } else {
+ return -EINVAL;
+ }
+
+ if ((c_xfrm->cipher.algo != RTE_CRYPTO_CIPHER_NULL) &&
+ (c_xfrm->cipher.algo != RTE_CRYPTO_CIPHER_AES_CTR) &&
+ (c_xfrm->cipher.algo != RTE_CRYPTO_CIPHER_ZUC_EEA3) &&
+ (c_xfrm->cipher.algo != RTE_CRYPTO_CIPHER_SNOW3G_UEA2))
+ return -EINVAL;
+
+ if (c_xfrm->cipher.algo == RTE_CRYPTO_CIPHER_NULL)
+ ciph_iv_len = 0;
+ else
+ ciph_iv_len = PDCP_IV_LEN;
+
+ if (ciph_iv_len != c_xfrm->cipher.iv.length)
+ return -EINVAL;
+
+ if (a_xfrm !
[PATCH v2 06/22] pdcp: add pre and post process for UL
Add routines to perform pre & post processing based on the type of
entity. To avoid checks in datapath, there are different function
pointers registered based on the following,
1. Control plane v/s user plane
2. 12 bit v/s 18 bit SN
For control plane only 12 bit SN need to be supported (as per PDCP
specification).
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_entity.h | 42 +
lib/pdcp/pdcp_process.c | 330
2 files changed, 372 insertions(+)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index ca1d56b516..46cdaead09 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -92,4 +92,46 @@ pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
return RTE_ALIGN_MUL_CEIL(sn_size, 8) / 8;
}
+static inline uint32_t
+pdcp_window_size_get(enum rte_security_pdcp_sn_size sn_size)
+{
+ return 1 << (sn_size - 1);
+}
+
+static inline uint32_t
+pdcp_sn_mask_get(enum rte_security_pdcp_sn_size sn_size)
+{
+ return (1 << sn_size) - 1;
+}
+
+static inline uint32_t
+pdcp_sn_from_count_get(uint32_t count, enum rte_security_pdcp_sn_size sn_size)
+{
+ return (count & pdcp_sn_mask_get(sn_size));
+}
+
+static inline uint32_t
+pdcp_hfn_mask_get(enum rte_security_pdcp_sn_size sn_size)
+{
+ return ~pdcp_sn_mask_get(sn_size);
+}
+
+static inline uint32_t
+pdcp_hfn_from_count_get(uint32_t count, enum rte_security_pdcp_sn_size sn_size)
+{
+ return (count & pdcp_hfn_mask_get(sn_size)) >> sn_size;
+}
+
+static inline uint32_t
+pdcp_count_from_hfn_sn_get(uint32_t hfn, uint32_t sn, enum
rte_security_pdcp_sn_size sn_size)
+{
+ return (((hfn << sn_size) & pdcp_hfn_mask_get(sn_size)) | (sn &
pdcp_sn_mask_get(sn_size)));
+}
+
+static inline uint32_t
+pdcp_hfn_max(enum rte_security_pdcp_sn_size sn_size)
+{
+ return (1 << (32 - sn_size)) - 1;
+}
+
#endif /* PDCP_ENTITY_H */
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index d4b158536d..7c1fc85fcb 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -36,6 +36,332 @@ pdcp_crypto_xfrm_get(const struct rte_pdcp_entity_conf
*conf, struct rte_crypto_
return 0;
}
+static inline void
+cop_prepare(const struct entity_priv *en_priv, struct rte_mbuf *mb, struct
rte_crypto_op *cop,
+ uint8_t data_offset, uint32_t count, const bool is_auth)
+{
+ const struct rte_crypto_op cop_init = {
+ .type = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ .status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED,
+ .sess_type = RTE_CRYPTO_OP_WITH_SESSION,
+ };
+ struct rte_crypto_sym_op *op;
+ uint32_t pkt_len;
+
+ const uint8_t ciph_shift = 3 * en_priv->flags.is_ciph_in_bits;
+ const uint8_t auth_shift = 3 * en_priv->flags.is_auth_in_bits;
+
+ op = cop->sym;
+ cop->raw = cop_init.raw;
+ op->m_src = mb;
+ op->m_dst = mb;
+
+ /* Set IV */
+ en_priv->iv_gen(cop, en_priv, count);
+
+ /* Prepare op */
+ pkt_len = rte_pktmbuf_pkt_len(mb);
+ op->cipher.data.offset = data_offset << ciph_shift;
+ op->cipher.data.length = (pkt_len - data_offset) << ciph_shift;
+
+ if (is_auth) {
+ op->auth.data.offset = 0;
+ op->auth.data.length = (pkt_len - PDCP_MAC_I_LEN) << auth_shift;
+ op->auth.digest.data = rte_pktmbuf_mtod_offset(mb, uint8_t *,
+ (pkt_len -
PDCP_MAC_I_LEN));
+ }
+
+ __rte_crypto_sym_op_attach_sym_session(op, en_priv->crypto_sess);
+}
+
+static inline bool
+pdcp_pre_process_uplane_sn_12_ul_set_sn(struct entity_priv *en_priv, struct
rte_mbuf *mb,
+ uint32_t *count)
+{
+ struct rte_pdcp_up_data_pdu_sn_12_hdr *pdu_hdr;
+ const uint8_t hdr_sz = en_priv->hdr_sz;
+ uint32_t sn;
+
+ /* Prepend PDU header */
+ pdu_hdr = (struct rte_pdcp_up_data_pdu_sn_12_hdr
*)rte_pktmbuf_prepend(mb, hdr_sz);
+ if (unlikely(pdu_hdr == NULL))
+ return false;
+
+ /* Update sequence num in the PDU header */
+ *count = en_priv->state.tx_next++;
+ sn = pdcp_sn_from_count_get(*count, RTE_SECURITY_PDCP_SN_SIZE_12);
+
+ pdu_hdr->d_c = RTE_PDCP_PDU_TYPE_DATA;
+ pdu_hdr->sn_11_8 = ((sn & 0xf00) >> 8);
+ pdu_hdr->sn_7_0 = (sn & 0xff);
+ pdu_hdr->r = 0;
+ return true;
+}
+
+static uint16_t
+pdcp_pre_process_uplane_sn_12_ul(const struct rte_pdcp_entity *entity, struct
rte_mbuf *in_mb[],
+struct rte_crypto_op *cop[], uint16_t num,
uint16_t *nb_err_ret)
+{
+ struct entity_priv *en_priv = entity_priv_get(entity);
+ uint16_t nb_cop, nb_prep = 0, nb_err = 0;
+ struct rte_mbuf *mb;
+ uint32_t count;
+ uint8_t *mac_i;
+ int i;
+
+ const uint8_t data_offset = en_priv->hdr_sz + en_pr
[PATCH v2 07/22] pdcp: add pre and post process for DL
Add routines to perform pre & post processing for down link entities.
Signed-off-by: Anoob Joseph
Signed-off-by: Kiran Kumar K
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_entity.h | 2 +
lib/pdcp/pdcp_process.c | 453
2 files changed, 455 insertions(+)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 46cdaead09..d2d9bbe149 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -13,6 +13,8 @@
struct entity_priv;
+#define PDCP_HFN_MIN 0
+
/* IV generation function based on the entity configuration */
typedef void (*iv_gen_t)(struct rte_crypto_op *cop, const struct entity_priv
*en_priv,
uint32_t count);
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index 7c1fc85fcb..79d6ca352a 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -329,9 +329,423 @@ pdcp_post_process_ul(const struct rte_pdcp_entity *entity,
return nb_success;
}
+static inline int
+pdcp_sn_count_get(const uint32_t rx_deliv, int32_t rsn, uint32_t *count,
+ const enum rte_security_pdcp_sn_size sn_size)
+{
+ const uint32_t rx_deliv_sn = pdcp_sn_from_count_get(rx_deliv, sn_size);
+ const uint32_t window_sz = pdcp_window_size_get(sn_size);
+ uint32_t rhfn;
+
+ rhfn = pdcp_hfn_from_count_get(rx_deliv, sn_size);
+
+ if (rsn < (int32_t)(rx_deliv_sn - window_sz)) {
+ if (unlikely(rhfn == pdcp_hfn_max(sn_size)))
+ return -ERANGE;
+ rhfn += 1;
+ } else if ((uint32_t)rsn >= (rx_deliv_sn + window_sz)) {
+ if (unlikely(rhfn == PDCP_HFN_MIN))
+ return -ERANGE;
+ rhfn -= 1;
+ }
+
+ *count = pdcp_count_from_hfn_sn_get(rhfn, rsn, sn_size);
+
+ return 0;
+}
+
+static inline uint16_t
+pdcp_pre_process_uplane_sn_12_dl_flags(const struct rte_pdcp_entity *entity,
+ struct rte_mbuf *in_mb[], struct
rte_crypto_op *cop[],
+ uint16_t num, uint16_t *nb_err_ret,
+ const bool is_integ_protected)
+{
+ struct entity_priv *en_priv = entity_priv_get(entity);
+ struct rte_pdcp_up_data_pdu_sn_12_hdr *pdu_hdr;
+ uint16_t nb_cop, nb_prep = 0, nb_err = 0;
+ struct rte_mbuf *mb;
+ int32_t rsn = 0;
+ uint32_t count;
+ int i;
+
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+
+ nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
+ num);
+
+ const uint32_t rx_deliv = en_priv->state.rx_deliv;
+
+ for (i = 0; i < nb_cop; i++) {
+ mb = in_mb[i];
+ pdu_hdr = rte_pktmbuf_mtod(mb, struct
rte_pdcp_up_data_pdu_sn_12_hdr *);
+
+ /* Check for PDU type */
+ if (likely(pdu_hdr->d_c == RTE_PDCP_PDU_TYPE_DATA))
+ rsn = ((pdu_hdr->sn_11_8 << 8) | (pdu_hdr->sn_7_0));
+ else
+ rte_panic("TODO: Control PDU not handled");
+
+ if (unlikely(pdcp_sn_count_get(rx_deliv, rsn, &count,
+ RTE_SECURITY_PDCP_SN_SIZE_12))) {
+ in_mb[nb_err++] = mb;
+ continue;
+ }
+ cop_prepare(en_priv, mb, cop[nb_prep++], data_offset, count,
is_integ_protected);
+ }
+
+ if (unlikely(nb_err))
+ rte_mempool_put_bulk(en_priv->cop_pool, (void *)&cop[nb_prep],
nb_cop - nb_prep);
+
+ *nb_err_ret = num - nb_prep;
+
+ return nb_prep;
+}
+
+static uint16_t
+pdcp_pre_process_uplane_sn_12_dl_ip(const struct rte_pdcp_entity *entity,
struct rte_mbuf *mb[],
+ struct rte_crypto_op *cop[], uint16_t num,
uint16_t *nb_err)
+{
+ return pdcp_pre_process_uplane_sn_12_dl_flags(entity, mb, cop, num,
nb_err, true);
+}
+
+static uint16_t
+pdcp_pre_process_uplane_sn_12_dl(const struct rte_pdcp_entity *entity, struct
rte_mbuf *mb[],
+struct rte_crypto_op *cop[], uint16_t num,
uint16_t *nb_err)
+{
+ return pdcp_pre_process_uplane_sn_12_dl_flags(entity, mb, cop, num,
nb_err, false);
+}
+
+static inline uint16_t
+pdcp_pre_process_uplane_sn_18_dl_flags(const struct rte_pdcp_entity *entity,
+ struct rte_mbuf *in_mb[], struct
rte_crypto_op *cop[],
+ uint16_t num, uint16_t *nb_err_ret,
+ const bool is_integ_protected)
+{
+ struct entity_priv *en_priv = entity_priv_get(entity);
+ struct rte_pdcp_up_data_pdu_sn_18_hdr *pdu_hdr;
+ uint16_t nb_cop, nb_prep = 0, nb_err = 0;
+ struct rte_mbuf *mb;
+ int32_t rsn = 0;
+ uint32_t count;
+ int i;
+
+ const uin
[PATCH v2 08/22] pdcp: add IV generation routines
For PDCP, IV generated has varying formats depending on the ciphering and
authentication algorithm used. Add routines to populate IV accordingly.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_entity.h | 87
lib/pdcp/pdcp_process.c | 284
2 files changed, 371 insertions(+)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index d2d9bbe149..3108795977 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -26,6 +26,89 @@ struct entity_state {
uint32_t rx_reord;
};
+union auth_iv_partial {
+ /* For AES-CMAC, there is no IV, but message gets prepended */
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint64_t count : 32;
+ uint64_t zero_38_39 : 2;
+ uint64_t direction : 1;
+ uint64_t bearer : 5;
+ uint64_t zero_40_63 : 24;
+#else
+ uint64_t count : 32;
+ uint64_t bearer : 5;
+ uint64_t direction : 1;
+ uint64_t zero_38_39 : 2;
+ uint64_t zero_40_63 : 24;
+#endif
+ } aes_cmac;
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint64_t count : 32;
+ uint64_t zero_37_39 : 3;
+ uint64_t bearer : 5;
+ uint64_t zero_40_63 : 24;
+
+ uint64_t rsvd_65_71 : 7;
+ uint64_t direction_64 : 1;
+ uint64_t rsvd_72_111 : 40;
+ uint64_t rsvd_113_119 : 7;
+ uint64_t direction_112 : 1;
+ uint64_t rsvd_120_127 : 8;
+#else
+ uint64_t count : 32;
+ uint64_t bearer : 5;
+ uint64_t zero_37_39 : 3;
+ uint64_t zero_40_63 : 24;
+
+ uint64_t direction_64 : 1;
+ uint64_t rsvd_65_71 : 7;
+ uint64_t rsvd_72_111 : 40;
+ uint64_t direction_112 : 1;
+ uint64_t rsvd_113_119 : 7;
+ uint64_t rsvd_120_127 : 8;
+#endif
+ } zs;
+ uint64_t u64[2];
+};
+
+union cipher_iv_partial {
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint64_t count : 32;
+ uint64_t zero_38_39 : 2;
+ uint64_t direction : 1;
+ uint64_t bearer : 5;
+ uint64_t zero_40_63 : 24;
+#else
+ uint64_t count : 32;
+ uint64_t bearer : 5;
+ uint64_t direction : 1;
+ uint64_t zero_38_39 : 2;
+ uint64_t zero_40_63 : 24;
+#endif
+ uint64_t zero_64_127;
+ } aes_ctr;
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint64_t count : 32;
+ uint64_t zero_38_39 : 2;
+ uint64_t direction : 1;
+ uint64_t bearer : 5;
+ uint64_t zero_40_63 : 24;
+#else
+ uint64_t count : 32;
+ uint64_t bearer : 5;
+ uint64_t direction : 1;
+ uint64_t zero_38_39 : 2;
+ uint64_t zero_40_63 : 24;
+#endif
+ uint64_t rsvd_64_127;
+ } zs;
+ uint64_t u64[2];
+};
+
/*
* Layout of PDCP entity: [rte_pdcp_entity] [entity_priv] [entity_dl/ul]
*/
@@ -35,6 +118,10 @@ struct entity_priv {
struct rte_cryptodev_sym_session *crypto_sess;
/** Entity specific IV generation function. */
iv_gen_t iv_gen;
+ /** Pre-prepared auth IV. */
+ union auth_iv_partial auth_iv_part;
+ /** Pre-prepared cipher IV. */
+ union cipher_iv_partial cipher_iv_part;
/** Entity state variables. */
struct entity_state state;
/** Flags. */
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index 79d6ca352a..9c1a5e0669 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -13,6 +13,181 @@
#include "pdcp_entity.h"
#include "pdcp_process.h"
+/* Enum of supported algorithms for ciphering */
+enum pdcp_cipher_algo {
+ PDCP_CIPHER_ALGO_NULL,
+ PDCP_CIPHER_ALGO_AES,
+ PDCP_CIPHER_ALGO_ZUC,
+ PDCP_CIPHER_ALGO_SNOW3G,
+ PDCP_CIPHER_ALGO_MAX
+};
+
+/* Enum of supported algorithms for integrity */
+enum pdcp_auth_algo {
+ PDCP_AUTH_ALGO_NULL,
+ PDCP_AUTH_ALGO_AES,
+ PDCP_AUTH_ALGO_ZUC,
+ PDCP_AUTH_ALGO_SNOW3G,
+ PDCP_AUTH_ALGO_MAX
+};
+
+/* IV generation functions based on type of operation (cipher - auth) */
+
+static void
+pdcp_iv_gen_null_null(struct rte_crypto_op *cop, const struct entity_priv
*en_priv, uint32_t count)
+{
+ /* No IV required for NULL cipher + NULL auth */
+ RTE_SET_USED(cop);
+ RTE_SET_USED(en_priv);
+ RTE_SET_USED(count);
+}
+
+static void
+pdcp_iv_gen_null_aes_cmac(struct rte_crypto_op *cop, const struct entity_priv
*en_priv,
+ uint32_t count)
+{
+ struct rte_crypto_sym_op *op = cop->sym;
+ struct rt
[PATCH v2 09/22] app/test: add lib pdcp tests
Add tests to verify lib PDCP operations. Tests leverage existing PDCP
test vectors.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/meson.build | 1 +
app/test/test_cryptodev.h | 3 +
app/test/test_pdcp.c | 729 ++
3 files changed, 733 insertions(+)
create mode 100644 app/test/test_pdcp.c
diff --git a/app/test/meson.build b/app/test/meson.build
index 52d9088578..0f658aa2ab 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -96,6 +96,7 @@ test_sources = files(
'test_meter.c',
'test_mcslock.c',
'test_mp_secondary.c',
+'test_pdcp.c',
'test_per_lcore.c',
'test_pflock.c',
'test_pmd_perf.c',
diff --git a/app/test/test_cryptodev.h b/app/test/test_cryptodev.h
index abd795f54a..89057dba22 100644
--- a/app/test/test_cryptodev.h
+++ b/app/test/test_cryptodev.h
@@ -4,6 +4,9 @@
#ifndef TEST_CRYPTODEV_H_
#define TEST_CRYPTODEV_H_
+#include
+#include
+
#define HEX_DUMP 0
#define FALSE 0
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
new file mode 100644
index 00..cb88817004
--- /dev/null
+++ b/app/test/test_pdcp.c
@@ -0,0 +1,729 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "test.h"
+#include "test_cryptodev.h"
+#include "test_cryptodev_security_pdcp_test_vectors.h"
+
+#define NB_DESC 1024
+#define CDEV_INVALID_ID UINT8_MAX
+#define NB_TESTS RTE_DIM(pdcp_test_params)
+
+struct pdcp_testsuite_params {
+ struct rte_mempool *mbuf_pool;
+ struct rte_mempool *cop_pool;
+ struct rte_mempool *sess_pool;
+ bool cdevs_used[RTE_CRYPTO_MAX_DEVS];
+};
+
+static struct pdcp_testsuite_params testsuite_params;
+
+struct pdcp_test_conf {
+ struct rte_pdcp_entity_conf entity;
+ struct rte_crypto_sym_xform c_xfrm;
+ struct rte_crypto_sym_xform a_xfrm;
+ bool is_integrity_protected;
+ uint8_t input[RTE_PDCP_CTRL_PDU_SIZE_MAX];
+ uint32_t input_len;
+ uint8_t output[RTE_PDCP_CTRL_PDU_SIZE_MAX];
+ uint32_t output_len;
+};
+
+static inline int
+pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
+{
+ return RTE_ALIGN_MUL_CEIL(sn_size, 8) / 8;
+}
+
+static int
+cryptodev_init(int dev_id)
+{
+ struct pdcp_testsuite_params *ts_params = &testsuite_params;
+ struct rte_cryptodev_qp_conf qp_conf;
+ struct rte_cryptodev_info dev_info;
+ struct rte_cryptodev_config config;
+ int ret, socket_id;
+
+ /* Check if device was already initialized */
+ if (ts_params->cdevs_used[dev_id])
+ return 0;
+
+ rte_cryptodev_info_get(dev_id, &dev_info);
+
+ if (dev_info.max_nb_queue_pairs < 1) {
+ RTE_LOG(ERR, USER1, "Cryptodev doesn't have sufficient queue
pairs available\n");
+ return -ENODEV;
+ }
+
+ socket_id = rte_socket_id();
+
+ memset(&config, 0, sizeof(config));
+ config.nb_queue_pairs = 1;
+ config.socket_id = socket_id;
+
+ ret = rte_cryptodev_configure(dev_id, &config);
+ if (ret < 0) {
+ RTE_LOG(ERR, USER1, "Could not configure cryptodev - %d\n",
dev_id);
+ return -ENODEV;
+ }
+
+ memset(&qp_conf, 0, sizeof(qp_conf));
+ qp_conf.nb_descriptors = NB_DESC;
+
+ ret = rte_cryptodev_queue_pair_setup(dev_id, 0, &qp_conf, socket_id);
+ if (ret < 0) {
+ RTE_LOG(ERR, USER1, "Could not configure queue pair\n");
+ return -ENODEV;
+ }
+
+ ret = rte_cryptodev_start(dev_id);
+ if (ret < 0) {
+ RTE_LOG(ERR, USER1, "Could not start cryptodev\n");
+ return -ENODEV;
+ }
+
+ /* Mark device as initialized */
+ ts_params->cdevs_used[dev_id] = true;
+
+ return 0;
+}
+
+static void
+cryptodev_fini(int dev_id)
+{
+ rte_cryptodev_stop(dev_id);
+}
+
+static unsigned int
+cryptodev_sess_priv_max_req_get(void)
+{
+ struct rte_cryptodev_info info;
+ unsigned int sess_priv_sz;
+ int i, nb_dev;
+ void *sec_ctx;
+
+ nb_dev = rte_cryptodev_count();
+
+ sess_priv_sz = 0;
+
+ for (i = 0; i < nb_dev; i++) {
+ rte_cryptodev_info_get(i, &info);
+ sess_priv_sz = RTE_MAX(sess_priv_sz,
rte_cryptodev_sym_get_private_session_size(i));
+ if (info.feature_flags & RTE_CRYPTODEV_FF_SECURITY) {
+ sec_ctx = rte_cryptodev_get_sec_ctx(i);
+ sess_priv_sz = RTE_MAX(sess_priv_sz,
+
rte_security_session_get_size(sec_ctx));
+ }
+ }
+
+ return sess_priv_sz;
+}
+
+static int
+testsuite_setup(void)
+{
+ struct pdcp_testsuite_params *ts_params = &testsuite_params;
+ int nb_cdev, sess_priv_size, nb_sess = 1024;
+
+ RTE_SET_
[PATCH v2 10/22] test/pdcp: pdcp HFN tests in combined mode
From: Volodymyr Fialko
Add tests to verify HFN/SN behaviour.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 302 ++-
1 file changed, 299 insertions(+), 3 deletions(-)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index cb88817004..fc49947ba2 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -15,6 +15,9 @@
#define CDEV_INVALID_ID UINT8_MAX
#define NB_TESTS RTE_DIM(pdcp_test_params)
+/* According to formula(7.2.a Window_Size) */
+#define PDCP_WINDOW_SIZE(sn_size) (1 << (sn_size - 1))
+
struct pdcp_testsuite_params {
struct rte_mempool *mbuf_pool;
struct rte_mempool *cop_pool;
@@ -35,12 +38,69 @@ struct pdcp_test_conf {
uint32_t output_len;
};
+static int create_test_conf_from_index(const int index, struct pdcp_test_conf
*conf);
+
+typedef int (*test_with_conf_t)(struct pdcp_test_conf *conf);
+
+static int
+run_test_foreach_known_vec(test_with_conf_t test, bool stop_on_first_pass)
+{
+ struct pdcp_test_conf test_conf;
+ bool all_tests_skipped = true;
+ uint32_t i;
+ int ret;
+
+ for (i = 0; i < NB_TESTS; i++) {
+ create_test_conf_from_index(i, &test_conf);
+ ret = test(&test_conf);
+
+ if (ret == TEST_FAILED) {
+ printf("[%03i] - %s - failed\n", i,
pdcp_test_params[i].name);
+ return TEST_FAILED;
+ }
+
+ if ((ret == TEST_SKIPPED) || (ret == -ENOTSUP))
+ continue;
+
+ if (stop_on_first_pass)
+ return TEST_SUCCESS;
+
+ all_tests_skipped = false;
+ }
+
+ if (all_tests_skipped)
+ return TEST_SKIPPED;
+
+ return TEST_SUCCESS;
+}
+
+static int
+run_test_with_all_known_vec(const void *args)
+{
+ test_with_conf_t test = args;
+
+ return run_test_foreach_known_vec(test, false);
+}
+
static inline int
pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
{
return RTE_ALIGN_MUL_CEIL(sn_size, 8) / 8;
}
+static int
+pktmbuf_read_into(const struct rte_mbuf *m, void *buf, size_t buf_len)
+{
+ if (m->pkt_len > buf_len)
+ return -ENOMEM;
+
+ const void *read = rte_pktmbuf_read(m, 0, m->pkt_len, buf);
+ if (read != NULL && read != buf)
+ memcpy(buf, read, m->pkt_len);
+
+ return 0;
+}
+
static int
cryptodev_init(int dev_id)
{
@@ -325,6 +385,21 @@ pdcp_sn_from_raw_get(const void *data, enum
rte_security_pdcp_sn_size size)
return sn;
}
+static void
+pdcp_sn_to_raw_set(void *data, uint32_t sn, int size)
+{
+ if (size == RTE_SECURITY_PDCP_SN_SIZE_12) {
+ struct rte_pdcp_up_data_pdu_sn_12_hdr *pdu_hdr = data;
+ pdu_hdr->sn_11_8 = ((sn & 0xf00) >> 8);
+ pdu_hdr->sn_7_0 = (sn & 0xff);
+ } else if (size == RTE_SECURITY_PDCP_SN_SIZE_18) {
+ struct rte_pdcp_up_data_pdu_sn_18_hdr *pdu_hdr = data;
+ pdu_hdr->sn_17_16 = ((sn & 0x3) >> 16);
+ pdu_hdr->sn_15_8 = ((sn & 0xff00) >> 8);
+ pdu_hdr->sn_7_0 = (sn & 0xff);
+ }
+}
+
static int
create_test_conf_from_index(const int index, struct pdcp_test_conf *conf)
{
@@ -645,9 +720,17 @@ test_attempt_single(struct pdcp_test_conf *t_conf)
goto mbuf_free;
}
- ret = pdcp_known_vec_verify(mbuf, t_conf->output, t_conf->output_len);
- if (ret)
- goto mbuf_free;
+ /* If expected output provided - verify, else - store for future use */
+ if (t_conf->output_len) {
+ ret = pdcp_known_vec_verify(mbuf, t_conf->output,
t_conf->output_len);
+ if (ret)
+ goto mbuf_free;
+ } else {
+ ret = pktmbuf_read_into(mbuf, t_conf->output,
RTE_PDCP_CTRL_PDU_SIZE_MAX);
+ if (ret)
+ goto mbuf_free;
+ t_conf->output_len = mbuf->pkt_len;
+ }
ret = rte_pdcp_entity_suspend(pdcp_entity, out_mb);
if (ret) {
@@ -664,6 +747,193 @@ test_attempt_single(struct pdcp_test_conf *t_conf)
return ret;
}
+static void
+uplink_to_downlink_convert(const struct pdcp_test_conf *ul_cfg,
+ struct pdcp_test_conf *dl_cfg)
+{
+ assert(ul_cfg->entity.pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_UPLINK);
+
+ memcpy(dl_cfg, ul_cfg, sizeof(*dl_cfg));
+ dl_cfg->entity.pdcp_xfrm.pkt_dir = RTE_SECURITY_PDCP_DOWNLINK;
+ dl_cfg->entity.reverse_iv_direction = false;
+
+ if (dl_cfg->is_integrity_protected) {
+ dl_cfg->entity.crypto_xfrm = &dl_cfg->c_xfrm;
+
+ dl_cfg->c_xfrm.cipher.op = RTE_CRYPTO_CIPHER_OP_DECRYPT;
+ dl_cfg->c_xfrm.next = &dl_cfg->a_xfrm;
+
+ dl_cfg->a_xfrm.auth.op = RTE_CRYPTO_AUTH_OP_VERIFY;
+ dl_cfg->a_xfrm.ne
[PATCH v2 11/22] doc: add PDCP library guide
Add guide for PDCP library. Signed-off-by: Anoob Joseph Signed-off-by: Kiran Kumar K Signed-off-by: Volodymyr Fialko --- .../img/pdcp_functional_overview.svg | 1 + doc/guides/prog_guide/index.rst | 1 + doc/guides/prog_guide/pdcp_lib.rst| 246 ++ 3 files changed, 248 insertions(+) create mode 100644 doc/guides/prog_guide/img/pdcp_functional_overview.svg create mode 100644 doc/guides/prog_guide/pdcp_lib.rst diff --git a/doc/guides/prog_guide/img/pdcp_functional_overview.svg b/doc/guides/prog_guide/img/pdcp_functional_overview.svg new file mode 100644 index 00..287daafc21 --- /dev/null +++ b/doc/guides/prog_guide/img/pdcp_functional_overview.svg @@ -0,0 +1 @@ +http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; overflow="hidden">Radio Interface (Uu/PC5)UE/NG-RAN/UE ANG-RAN/UE/UE BTransmitting PDCP entityReceiving PDCP entityTransmission buffer:SequencenumberingHeader or uplink dataCompressionHeader or uplink dataDecompressionRouting / DuplicationAdd PDCP headerCipheringIntegrity protectionPackets associated to a PDCP SDUPackets not associated to a PDCP SDURemove PDCP HeaderDecipheringIntegrity VerificationReception buffer:ReorderingDuplicate discardingPackets associated to a PDCP SDUPackets not associated to a PDCP SDU \ No newline at end of file diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst index 87333ee84a..6099ff63cd 100644 --- a/doc/guides/prog_guide/index.rst +++ b/doc/guides/prog_guide/index.rst @@ -77,4 +77,5 @@ Programmer's Guide lto profile_app asan +pdcp_lib glossary diff --git a/doc/guides/prog_guide/pdcp_lib.rst b/doc/guides/prog_guide/pdcp_lib.rst new file mode 100644 index 00..abd874f2cc --- /dev/null +++ b/doc/guides/prog_guide/pdcp_lib.rst @@ -0,0 +1,246 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(C) 2023 Marvell. + +PDCP Protocol Processing Library + + +DPDK provides a library for PDCP protocol processing. The library utilizes +other DPDK libraries such as cryptodev, reorder, etc., to provide the +application with a transparent and high performant PDCP protocol processing +library. + +The library abstracts complete PDCP protocol processing conforming to +``ETSI TS 138 323 V17.1.0 (2022-08)``. +https://www.etsi.org/deliver/etsi_ts/138300_138399/138323/17.01.00_60/ts_138323v170100p.pdf + +PDCP would involve the following operations, + +1. Transfer of user plane data +2. Transfer of control plane data +3. Header compression +4. Uplink data compression +5. Ciphering and integrity protection + +.. _figure_pdcp_functional_overview: + +.. figure:: img/pdcp_functional_overview.* + + PDCP functional overview new + +PDCP library would abstract the protocol offload features of the cryptodev and +would provide a uniform interface and consistent API usage to work with +cryptodev irrespective of the protocol offload features supported. + +PDCP entity API +--- + +PDCP library provides following control path APIs that is used to +configure various PDCP entities, + +1. ``rte_pdcp_entity_establish()`` +2. ``rte_pdcp_entity_suspend()`` +3. ``rte_pdcp_entity_release()`` + +A PDCP entity would translate to one ``rte_cryptodev_sym_session`` or +``rte_security_session`` based on the config. The sessions would be created/ +destroyed while corresponding PDCP entity operations are performed. + +PDCP PDU (Protocol Data Unit) +- + +PDCP PDUs can be categorized as, + +1. Control PDU +2. Data PDU + +Control PDUs are used for signalling between entities on either end and can be +one of the following, + +1. PDCP status report +2. ROHC feedback +3. EHC feedback + +Control PDUs are not ciphered or authenticated, and so such packets are not +submitted to cryptodev for processing. + +Data PDUs are regular packets submitted by upper layers for transmission to +other end. Such packets would need to be ciphered and authenticated based on +the entity configuration. + +PDCP packet processing API for data PDU +~~~ + +PDCP processing is split into 2 parts. One before cryptodev processing +(``rte_pdcp_pkt_pre_process()``) and one after cryptodev processing +(``rte_pdcp_pkt_post_process()``). Since cryptodev dequeue can return crypto +operations belonging to multiple entities, ``rte_pdcp_pkt_crypto_group()`` +is added to help grouping crypto operations belonging to same PDCP entity. + +Lib PDCP would allow application to use same API sequence while leveraging +protocol offload features enabled by ``rte_security`` library. Lib PDCP would +internally change the handles registered for ``pre_process`` and +``post_process`` based on features enabled in the entity. + +Lib PDCP would create the required sessions on the device provided in entity to +minimize the application requirements. Also, the crypto_op allocation and free +would also be done
[PATCH v2 12/22] pdcp: add control PDU handling
Add control PDU handling and implement status report generation. Status
report generation works only when RX_DELIV = RX_NEXT.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 1 +
doc/guides/prog_guide/pdcp_lib.rst | 10 +++
lib/pdcp/meson.build | 2 ++
lib/pdcp/pdcp_cnt.c| 29 ++
lib/pdcp/pdcp_cnt.h| 14 +
lib/pdcp/pdcp_ctrl_pdu.c | 46 +
lib/pdcp/pdcp_ctrl_pdu.h | 15 ++
lib/pdcp/pdcp_entity.h | 15 --
lib/pdcp/pdcp_process.c| 13 +
lib/pdcp/rte_pdcp.c| 47 +-
lib/pdcp/rte_pdcp.h| 31
lib/pdcp/version.map | 2 ++
12 files changed, 222 insertions(+), 3 deletions(-)
create mode 100644 lib/pdcp/pdcp_cnt.c
create mode 100644 lib/pdcp/pdcp_cnt.h
create mode 100644 lib/pdcp/pdcp_ctrl_pdu.c
create mode 100644 lib/pdcp/pdcp_ctrl_pdu.h
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index fc49947ba2..4ecb4d9572 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -415,6 +415,7 @@ create_test_conf_from_index(const int index, struct
pdcp_test_conf *conf)
conf->entity.sess_mpool = ts_params->sess_pool;
conf->entity.cop_pool = ts_params->cop_pool;
+ conf->entity.ctr_pdu_pool = ts_params->mbuf_pool;
conf->entity.pdcp_xfrm.bearer = pdcp_test_bearer[index];
conf->entity.pdcp_xfrm.en_ordering = 0;
conf->entity.pdcp_xfrm.remove_duplicates = 0;
diff --git a/doc/guides/prog_guide/pdcp_lib.rst
b/doc/guides/prog_guide/pdcp_lib.rst
index abd874f2cc..f23360dfc3 100644
--- a/doc/guides/prog_guide/pdcp_lib.rst
+++ b/doc/guides/prog_guide/pdcp_lib.rst
@@ -67,6 +67,15 @@ Data PDUs are regular packets submitted by upper layers for
transmission to
other end. Such packets would need to be ciphered and authenticated based on
the entity configuration.
+PDCP packet processing API for control PDU
+~~
+
+Control PDUs are used in PDCP as a communication channel between transmitting
+and receiving entities. When upper layer request for operations such
+re-establishment, receiving PDCP entity need to prepare a status report and
+send it to the other end. The API ``pdcp_ctrl_pdu_status_gen`` allows
+application to request the same.
+
PDCP packet processing API for data PDU
~~~
@@ -228,6 +237,7 @@ Supported features
- Uplink & downlink traffic
- HFN increment
- IV generation as required per algorithm
+- Control PDU generation
Supported ciphering algorithms
~~
diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
index 08679b743a..75d476bf6d 100644
--- a/lib/pdcp/meson.build
+++ b/lib/pdcp/meson.build
@@ -8,7 +8,9 @@ if is_windows
endif
sources = files(
+'pdcp_cnt.c',
'pdcp_crypto.c',
+'pdcp_ctrl_pdu.c',
'pdcp_process.c',
'rte_pdcp.c',
)
diff --git a/lib/pdcp/pdcp_cnt.c b/lib/pdcp/pdcp_cnt.c
new file mode 100644
index 00..c9b952184b
--- /dev/null
+++ b/lib/pdcp/pdcp_cnt.c
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include
+
+#include "pdcp_cnt.h"
+#include "pdcp_entity.h"
+
+int
+pdcp_cnt_ring_create(struct rte_pdcp_entity *en, const struct
rte_pdcp_entity_conf *conf)
+{
+ struct entity_priv_dl_part *en_priv_dl;
+ uint32_t window_sz;
+
+ if (en == NULL || conf == NULL)
+ return -EINVAL;
+
+ if (conf->pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_UPLINK)
+ return 0;
+
+ en_priv_dl = entity_dl_part_get(en);
+ window_sz = pdcp_window_size_get(conf->pdcp_xfrm.sn_size);
+
+ RTE_SET_USED(window_sz);
+ RTE_SET_USED(en_priv_dl);
+
+ return 0;
+}
diff --git a/lib/pdcp/pdcp_cnt.h b/lib/pdcp/pdcp_cnt.h
new file mode 100644
index 00..bbda478b55
--- /dev/null
+++ b/lib/pdcp/pdcp_cnt.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef PDCP_CNT_H
+#define PDCP_CNT_H
+
+#include
+
+#include "pdcp_entity.h"
+
+int pdcp_cnt_ring_create(struct rte_pdcp_entity *en, const struct
rte_pdcp_entity_conf *conf);
+
+#endif /* PDCP_CNT_H */
diff --git a/lib/pdcp/pdcp_ctrl_pdu.c b/lib/pdcp/pdcp_ctrl_pdu.c
new file mode 100644
index 00..feb05fd863
--- /dev/null
+++ b/lib/pdcp/pdcp_ctrl_pdu.c
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include
+#include
+#include
+
+#include "pdcp_ctrl_pdu.h"
+#include "pdcp_entity.h"
+
+static __rte_always_inline void
+pdcp_hdr_fill(struct rte_pdcp_up_ctrl_pdu_hdr *pdu_hdr, uint32_t rx_deliv)
+{
+ pdu_hdr->d_c = RTE_PDCP_PDU_TYPE_CTRL;
+ pdu_hdr->pdu_type = RTE_PDCP_CTRL_PDU_TYPE_STATUS_REPORT;
[PATCH v2 13/22] pdcp: implement t-Reordering and packet buffering
From: Volodymyr Fialko
Add in-order delivery of packets in PDCP. Delivery of packets in-order
relies on t-Reordering timer.
When 'out-of-order delivery' is disabled, PDCP will buffer all received
packets that are out of order. The t-Reordering timer determines the
time period these packets would be held in the buffer, waiting for any
missing packets to arrive.
Introduce packet buffering and state variables which indicate status of
the timer.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/meson.build| 3 +-
lib/pdcp/pdcp_entity.h | 19 +++
lib/pdcp/pdcp_process.c | 123 +++-
lib/pdcp/pdcp_reorder.c | 27 +
lib/pdcp/pdcp_reorder.h | 62
lib/pdcp/rte_pdcp.c | 53 +++--
lib/pdcp/rte_pdcp.h | 6 +-
7 files changed, 257 insertions(+), 36 deletions(-)
create mode 100644 lib/pdcp/pdcp_reorder.c
create mode 100644 lib/pdcp/pdcp_reorder.h
diff --git a/lib/pdcp/meson.build b/lib/pdcp/meson.build
index 75d476bf6d..f4f9246bcb 100644
--- a/lib/pdcp/meson.build
+++ b/lib/pdcp/meson.build
@@ -12,9 +12,10 @@ sources = files(
'pdcp_crypto.c',
'pdcp_ctrl_pdu.c',
'pdcp_process.c',
+'pdcp_reorder.c',
'rte_pdcp.c',
)
headers = files('rte_pdcp.h')
indirect_headers += files('rte_pdcp_group.h')
-deps += ['mbuf', 'net', 'cryptodev', 'security']
+deps += ['mbuf', 'net', 'cryptodev', 'security', 'reorder']
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 7b7e7f69dd..71962d7279 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -11,6 +11,8 @@
#include
#include
+#include "pdcp_reorder.h"
+
struct entity_priv;
#define PDCP_HFN_MIN 0
@@ -109,6 +111,17 @@ union cipher_iv_partial {
uint64_t u64[2];
};
+enum timer_state {
+ TIMER_STOP,
+ TIMER_RUNNING,
+ TIMER_EXPIRED,
+};
+
+struct pdcp_t_reordering {
+ /** Represent timer state */
+ enum timer_state state;
+};
+
struct pdcp_cnt_bitmap {
/** Number of entries that can be stored. */
uint32_t size;
@@ -145,6 +158,8 @@ struct entity_priv {
uint64_t is_null_auth : 1;
/** Is status report required.*/
uint64_t is_status_report_required : 1;
+ /** Is out-of-order delivery enabled */
+ uint64_t is_out_of_order_delivery : 1;
} flags;
/** Crypto op pool. */
struct rte_mempool *cop_pool;
@@ -161,6 +176,10 @@ struct entity_priv {
struct entity_priv_dl_part {
/** PDCP would need to track the count values that are already
received.*/
struct pdcp_cnt_bitmap bitmap;
+ /** t-Reordering handles */
+ struct pdcp_t_reordering t_reorder;
+ /** Reorder packet buffer */
+ struct pdcp_reorder reorder;
};
struct entity_priv_ul_part {
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index 267b3b7723..16d22cbe14 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -809,25 +809,88 @@ pdcp_packet_strip(struct rte_mbuf *mb, const uint32_t
hdr_trim_sz, const bool tr
}
}
-static inline bool
+static inline int
pdcp_post_process_update_entity_state(const struct rte_pdcp_entity *entity,
- const uint32_t count)
+ const uint32_t count, struct rte_mbuf *mb,
+ struct rte_mbuf *out_mb[],
+ const bool trim_mac)
{
struct entity_priv *en_priv = entity_priv_get(entity);
+ struct pdcp_t_reordering *t_reorder;
+ struct pdcp_reorder *reorder;
+ uint16_t processed = 0;
- if (count < en_priv->state.rx_deliv)
- return false;
+ struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
+ const uint32_t hdr_trim_sz = en_priv->hdr_sz + en_priv->aad_sz;
- /* t-Reordering timer is not supported - SDU will be delivered
immediately.
-* Update RX_DELIV to the COUNT value of the first PDCP SDU which has
not
-* been delivered to upper layers
-*/
- en_priv->state.rx_next = count + 1;
+ if (count < en_priv->state.rx_deliv)
+ return -EINVAL;
if (count >= en_priv->state.rx_next)
en_priv->state.rx_next = count + 1;
- return true;
+ pdcp_packet_strip(mb, hdr_trim_sz, trim_mac);
+
+ if (en_priv->flags.is_out_of_order_delivery) {
+ out_mb[0] = mb;
+ en_priv->state.rx_deliv = count + 1;
+
+ return 1;
+ }
+
+ reorder = &dl->reorder;
+ t_reorder = &dl->t_reorder;
+
+ if (count == en_priv->state.rx_deliv) {
+ if (reorder->is_active) {
+ /*
+* This insert used only to increment reorder->min_seqn
+* To remove it - min_seqn_set()
[PATCH v2 14/22] test/pdcp: add in-order delivery cases
From: Volodymyr Fialko
Add test cases to verify behaviour when in-order delivery is enabled and
packets arrive in out-of-order. PDCP library is expected to buffer the
packets and return packets in-order when the missing packet arrives.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 195 +++
1 file changed, 195 insertions(+)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index 4ecb4d9572..c96ddc4f53 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -15,6 +15,15 @@
#define CDEV_INVALID_ID UINT8_MAX
#define NB_TESTS RTE_DIM(pdcp_test_params)
+/* Assert that condition is true, or goto the mark */
+#define ASSERT_TRUE_OR_GOTO(cond, mark, ...) do {\
+ if (!(cond)) { \
+ RTE_LOG(ERR, USER1, "Error at: %s:%d\n", __func__, __LINE__); \
+ RTE_LOG(ERR, USER1, __VA_ARGS__); \
+ goto mark; \
+ } \
+} while (0)
+
/* According to formula(7.2.a Window_Size) */
#define PDCP_WINDOW_SIZE(sn_size) (1 << (sn_size - 1))
@@ -82,6 +91,14 @@ run_test_with_all_known_vec(const void *args)
return run_test_foreach_known_vec(test, false);
}
+static int
+run_test_with_all_known_vec_until_first_pass(const void *args)
+{
+ test_with_conf_t test = args;
+
+ return run_test_foreach_known_vec(test, true);
+}
+
static inline int
pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
{
@@ -868,6 +885,7 @@ test_sn_range_type(enum sn_range_type type, struct
pdcp_test_conf *conf)
/* Configure Uplink to generate expected, encrypted packet */
pdcp_sn_to_raw_set(conf->input, new_sn, conf->entity.pdcp_xfrm.sn_size);
+ conf->entity.out_of_order_delivery = true;
conf->entity.reverse_iv_direction = true;
conf->entity.count = PDCP_SET_COUNT(new_hfn, new_sn, sn_size);
conf->output_len = 0;
@@ -913,6 +931,168 @@ test_sn_minus_outside(struct pdcp_test_conf *t_conf)
return test_sn_range_type(SN_RANGE_MINUS_OUTSIDE, t_conf);
}
+static struct rte_mbuf *
+generate_packet_for_dl_with_sn(struct pdcp_test_conf ul_conf, uint32_t sn)
+{
+ int ret;
+
+ ul_conf.entity.count = sn;
+ ul_conf.entity.out_of_order_delivery = true;
+ ul_conf.entity.reverse_iv_direction = true;
+ ul_conf.output_len = 0;
+
+ ret = test_attempt_single(&ul_conf);
+ if (ret != TEST_SUCCESS)
+ return NULL;
+
+ return mbuf_from_data_create(ul_conf.output, ul_conf.output_len);
+}
+
+static bool
+array_asc_sorted_check(struct rte_mbuf *m[], uint32_t len, enum
rte_security_pdcp_sn_size sn_size)
+{
+ uint32_t i;
+
+ if (len < 2)
+ return true;
+
+ for (i = 0; i < (len - 1); i++) {
+ if (pdcp_sn_from_raw_get(rte_pktmbuf_mtod(m[i], void *),
sn_size) >
+ pdcp_sn_from_raw_get(rte_pktmbuf_mtod(m[i + 1], void *),
sn_size))
+ return false;
+ }
+
+ return true;
+}
+
+static int
+test_reorder_gap_fill(struct pdcp_test_conf *ul_conf)
+{
+ struct rte_mbuf *m0 = NULL, *m1 = NULL, *out_mb[2] = {0};
+ uint16_t nb_success = 0, nb_err = 0;
+ struct rte_pdcp_entity *pdcp_entity;
+ struct pdcp_test_conf dl_conf;
+ int ret = TEST_FAILED, nb_out;
+ uint8_t cdev_id;
+
+ const int start_count = 0;
+
+ if (ul_conf->entity.pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_DOWNLINK)
+ return TEST_SKIPPED;
+
+ /* Create configuration for actual testing */
+ uplink_to_downlink_convert(ul_conf, &dl_conf);
+ dl_conf.entity.count = start_count;
+
+ pdcp_entity = test_entity_create(&dl_conf, &ret);
+ if (pdcp_entity == NULL)
+ return ret;
+
+ const uint32_t sn_size = dl_conf.entity.pdcp_xfrm.sn_size;
+ cdev_id = dl_conf.entity.dev_id;
+
+ /* Send packet with SN > RX_DELIV to create a gap */
+ m1 = generate_packet_for_dl_with_sn(*ul_conf, start_count + 1);
+ ASSERT_TRUE_OR_GOTO(m1 != NULL, exit, "Could not allocate buffer for
packet\n");
+
+ /* Buffered packets after insert [NULL, m1] */
+ nb_success = test_process_packets(pdcp_entity, cdev_id, &m1, 1, out_mb,
&nb_err);
+ ASSERT_TRUE_OR_GOTO(nb_err == 0, exit, "Error occurred during packet
process\n");
+ ASSERT_TRUE_OR_GOTO(nb_success == 0, exit, "Packet was not buffered as
expected\n");
+ m1 = NULL; /* Packet was moved to PDCP lib */
+
+ /* Generate packet to fill the existing gap */
+ m0 = generate_packet_for_dl_with_sn(*ul_conf, start_count);
+ ASSERT_TRUE_OR_GOTO(m0 != NULL, exit, "Could not allocate buffer for
packet\n");
+
+ /*
+* Buffered packets after insert [m0, m1]
+* Gap filled, all packets should be returned
+*/
+ nb_success = test_process_packets(pdcp_entity, cdev_id, &m0, 1, out_mb,
&nb_err);
+ ASSERT_TRUE_OR_GOTO(nb_err == 0, exit, "E
[PATCH v2 15/22] pdcp: add timer callback handlers
From: Volodymyr Fialko
PDCP has a windowing mechanism which allows only packets that fall in a
reception window. The pivot point for this window is RX_REORD which
happens to be the first missing or next expected packet. If the missing
packet is not received after a specified time, then the RX_REORD state
variable needs to be moved up to slide the reception window. PDCP relies
on timers for such operations.
The timer needs to be armed when PDCP library doesn't receive all
packets in-order and starts buffering packets that arrived after a
missing packet. The timer needs to be cancelled when a missing packet
is received.
To avoid dependency on particular timer implementation, PDCP library
allows application to register two callbacks, timer_start() and
timer_stop() that will be called later by library.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_entity.h | 2 ++
lib/pdcp/pdcp_process.c | 2 ++
lib/pdcp/rte_pdcp.c | 1 +
lib/pdcp/rte_pdcp.h | 47 +
4 files changed, 52 insertions(+)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 71962d7279..ca98a1d0f7 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -120,6 +120,8 @@ enum timer_state {
struct pdcp_t_reordering {
/** Represent timer state */
enum timer_state state;
+ /** User defined callback handles */
+ struct rte_pdcp_t_reordering handle;
};
struct pdcp_cnt_bitmap {
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index 16d22cbe14..9ba07d5255 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -874,6 +874,7 @@ pdcp_post_process_update_entity_state(const struct
rte_pdcp_entity *entity,
if (t_reorder->state == TIMER_RUNNING &&
en_priv->state.rx_deliv >= en_priv->state.rx_reord) {
t_reorder->state = TIMER_STOP;
+ t_reorder->handle.stop(t_reorder->handle.timer,
t_reorder->handle.args);
/* Stop reorder buffer, only if it's empty */
if (en_priv->state.rx_deliv == en_priv->state.rx_next)
pdcp_reorder_stop(reorder);
@@ -888,6 +889,7 @@ pdcp_post_process_update_entity_state(const struct
rte_pdcp_entity *entity,
en_priv->state.rx_reord = en_priv->state.rx_next;
/* Start t-Reordering */
t_reorder->state = TIMER_RUNNING;
+ t_reorder->handle.start(t_reorder->handle.timer,
t_reorder->handle.args);
}
return processed;
diff --git a/lib/pdcp/rte_pdcp.c b/lib/pdcp/rte_pdcp.c
index c9d44ca539..755d592578 100644
--- a/lib/pdcp/rte_pdcp.c
+++ b/lib/pdcp/rte_pdcp.c
@@ -36,6 +36,7 @@ pdcp_dl_establish(struct rte_pdcp_entity *entity, const
struct rte_pdcp_entity_c
struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
entity->max_pkt_cache = RTE_MAX(entity->max_pkt_cache, window_size);
+ dl->t_reorder.handle = conf->t_reordering;
return pdcp_reorder_create(&dl->reorder, window_size);
}
diff --git a/lib/pdcp/rte_pdcp.h b/lib/pdcp/rte_pdcp.h
index 0d2f4fe7c1..55e57c3b9b 100644
--- a/lib/pdcp/rte_pdcp.h
+++ b/lib/pdcp/rte_pdcp.h
@@ -66,6 +66,51 @@ struct rte_pdcp_entity {
uint64_t user_area[2];
} __rte_cache_aligned;
+/**
+ * Callback function type for t-Reordering timer start, set during PDCP entity
establish.
+ * This callback is invoked by PDCP library, during t-Reordering timer start
event.
+ * Only one t-Reordering per receiving PDCP entity would be running at a given
time.
+ *
+ * @see struct rte_pdcp_timer
+ * @see rte_pdcp_entity_establish()
+ *
+ * @param timer
+ * Pointer to timer.
+ * @param args
+ * Pointer to timer arguments.
+ */
+typedef void (*rte_pdcp_t_reordering_start_cb_t)(void *timer, void *args);
+
+/**
+ * Callback function type for t-Reordering timer stop, set during PDCP entity
establish.
+ * This callback will be invoked by PDCP library, during t-Reordering timer
stop event.
+ *
+ * @see struct rte_pdcp_timer
+ * @see rte_pdcp_entity_establish()
+ *
+ * @param timer
+ * Pointer to timer.
+ * @param args
+ * Pointer to timer arguments.
+ */
+typedef void (*rte_pdcp_t_reordering_stop_cb_t)(void *timer, void *args);
+
+/**
+ * PDCP t-Reordering timer interface
+ *
+ * Configuration provided by user, that PDCP library will invoke according to
timer behaviour.
+ */
+struct rte_pdcp_t_reordering {
+ /** Timer pointer, stored for later use in callback functions */
+ void *timer;
+ /** Timer arguments, stored for later use in callback functions */
+ void *args;
+ /** Timer start callback handle */
+ rte_pdcp_t_reordering_start_cb_t start;
+ /** Timer start callback handle */
+ rte_pdcp_t_reordering_stop_cb_t stop;
+};
+
/**
* PDCP entity configuration to be used for establishing an entity.
*/
@@ -105,6 +150,8 @@ struct rte_pdcp_entity_conf {
bool stat
[PATCH v2 16/22] pdcp: add timer expiry handle
From: Volodymyr Fialko
The PDCP protocol requires usage of timers to keep track of how long
an out-of-order packet should be buffered while waiting for missing
packets. Applications can register a desired timer implementation with the
PDCP library. Once the timer expires, the application will be notified, and
further handling of the event will be performed in the PDCP library.
When the timer expires, the PDCP library will return the cached packets,
and PDCP internal state variables (like RX_REORD, RX_DELIV etc) will be
updated accordingly.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
doc/guides/prog_guide/pdcp_lib.rst | 29 ++
lib/pdcp/pdcp_process.c| 49 ++
lib/pdcp/rte_pdcp.h| 31 +++
lib/pdcp/version.map | 2 ++
4 files changed, 111 insertions(+)
diff --git a/doc/guides/prog_guide/pdcp_lib.rst
b/doc/guides/prog_guide/pdcp_lib.rst
index f23360dfc3..32370633e5 100644
--- a/doc/guides/prog_guide/pdcp_lib.rst
+++ b/doc/guides/prog_guide/pdcp_lib.rst
@@ -229,6 +229,35 @@ parameters for entity creation.
}
}
+Timers
+--
+
+PDCP utilizes a reception window mechanism to limit the bits of COUNT value
+transmitted in the packet. It utilizes state variables such as RX_REORD,
+RX_DELIV to define the window and uses RX_DELIV as the lower pivot point of the
+window.
+
+RX_DELIV would be updated only when packets are received in-order. Any missing
+packet would mean RX_DELIV won't be updated. A timer, t-Reordering, helps PDCP
+to slide the window if the missing packet is not received in a specified time
+duration.
+
+While starting and stopping the timer need to be done by lib PDCP, application
+could register its own timer implementation. This is to make sure application
+can choose between timers such as rte_timer and rte_event based timers.
Starting
+and stopping of timer would happen during pre & post process API.
+
+When the t-Reordering timer expires, application would receive the expiry
event.
+To perform the PDCP handling of the expiry event,
+``rte_pdcp_t_reordering_expiry_handle`` can be used. Expiry handling would
+involve sliding the window by updating state variables and passing the expired
+packets to the application.
+
+.. literalinclude:: ../../../lib/pdcp/rte_pdcp.h
+ :language: c
+ :start-after: Structure rte_pdcp_t_reordering 8<
+ :end-before: >8 End of structure rte_pdcp_t_reordering.
+
Supported features
--
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index 9ba07d5255..91b87a2a81 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -1285,3 +1285,52 @@ pdcp_process_func_set(struct rte_pdcp_entity *entity,
const struct rte_pdcp_enti
return 0;
}
+
+uint16_t
+rte_pdcp_t_reordering_expiry_handle(const struct rte_pdcp_entity *entity,
struct rte_mbuf *out_mb[])
+{
+ struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
+ struct entity_priv *en_priv = entity_priv_get(entity);
+ uint16_t capacity = entity->max_pkt_cache;
+ uint16_t nb_out, nb_seq;
+
+ /* 5.2.2.2 Actions when a t-Reordering expires */
+
+ /*
+* - deliver to upper layers in ascending order of the associated COUNT
value after
+* performing header decompression, if not decompressed before:
+*/
+
+ /* - all stored PDCP SDU(s) with associated COUNT value(s) <
RX_REORD; */
+ nb_out = pdcp_reorder_up_to_get(&dl->reorder, out_mb, capacity,
en_priv->state.rx_reord);
+ capacity -= nb_out;
+ out_mb = &out_mb[nb_out];
+
+ /*
+* - all stored PDCP SDU(s) with consecutively associated COUNT
value(s) starting from
+* RX_REORD;
+*/
+ nb_seq = pdcp_reorder_get_sequential(&dl->reorder, out_mb, capacity);
+ nb_out += nb_seq;
+
+ /*
+* - update RX_DELIV to the COUNT value of the first PDCP SDU which has
not been delivered
+* to upper layers, with COUNT value >= RX_REORD;
+*/
+ en_priv->state.rx_deliv = en_priv->state.rx_reord + nb_seq;
+
+ /*
+* - if RX_DELIV < RX_NEXT:
+* - update RX_REORD to RX_NEXT;
+* - start t-Reordering.
+*/
+ if (en_priv->state.rx_deliv < en_priv->state.rx_next) {
+ en_priv->state.rx_reord = en_priv->state.rx_next;
+ dl->t_reorder.state = TIMER_RUNNING;
+ dl->t_reorder.handle.start(dl->t_reorder.handle.timer,
dl->t_reorder.handle.args);
+ } else {
+ dl->t_reorder.state = TIMER_EXPIRED;
+ }
+
+ return nb_out;
+}
diff --git a/lib/pdcp/rte_pdcp.h b/lib/pdcp/rte_pdcp.h
index 55e57c3b9b..c077acce63 100644
--- a/lib/pdcp/rte_pdcp.h
+++ b/lib/pdcp/rte_pdcp.h
@@ -100,6 +100,7 @@ typedef void (*rte_pdcp_t_reordering_stop_cb_t)(void
*timer, void *args);
*
* Configuration provided by user, that PDCP library w
[PATCH v2 17/22] test/pdcp: add timer expiry cases
From: Volodymyr Fialko
Add test cases for handling the expiry with rte_timer and rte_event_timer.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 325 +++
1 file changed, 325 insertions(+)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index c96ddc4f53..a0e982777d 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -3,15 +3,22 @@
*/
#include
+#include
+#include
#include
#include
#include
+#include
#include "test.h"
#include "test_cryptodev.h"
#include "test_cryptodev_security_pdcp_test_vectors.h"
+#define NSECPERSEC 1E9
#define NB_DESC 1024
+#define TIMER_ADAPTER_ID 0
+#define TEST_EV_QUEUE_ID 0
+#define TEST_EV_PORT_ID 0
#define CDEV_INVALID_ID UINT8_MAX
#define NB_TESTS RTE_DIM(pdcp_test_params)
@@ -32,10 +39,19 @@ struct pdcp_testsuite_params {
struct rte_mempool *cop_pool;
struct rte_mempool *sess_pool;
bool cdevs_used[RTE_CRYPTO_MAX_DEVS];
+ int evdev;
+ struct rte_event_timer_adapter *timdev;
+ bool timer_is_running;
+ uint64_t min_resolution_ns;
};
static struct pdcp_testsuite_params testsuite_params;
+struct test_rte_timer_args {
+ int status;
+ struct rte_pdcp_entity *pdcp_entity;
+};
+
struct pdcp_test_conf {
struct rte_pdcp_entity_conf entity;
struct rte_crypto_sym_xform c_xfrm;
@@ -99,6 +115,30 @@ run_test_with_all_known_vec_until_first_pass(const void
*args)
return run_test_foreach_known_vec(test, true);
}
+static void
+pdcp_timer_start_cb(void *timer, void *args)
+{
+ bool *is_timer_running = timer;
+
+ RTE_SET_USED(args);
+ *is_timer_running = true;
+}
+
+static void
+pdcp_timer_stop_cb(void *timer, void *args)
+{
+ bool *is_timer_running = timer;
+
+ RTE_SET_USED(args);
+ *is_timer_running = false;
+}
+
+static struct rte_pdcp_t_reordering t_reorder_timer = {
+ .timer = &testsuite_params.timer_is_running,
+ .start = pdcp_timer_start_cb,
+ .stop = pdcp_timer_stop_cb,
+};
+
static inline int
pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
{
@@ -437,6 +477,7 @@ create_test_conf_from_index(const int index, struct
pdcp_test_conf *conf)
conf->entity.pdcp_xfrm.en_ordering = 0;
conf->entity.pdcp_xfrm.remove_duplicates = 0;
conf->entity.pdcp_xfrm.domain = pdcp_test_params[index].domain;
+ conf->entity.t_reordering = t_reorder_timer;
if (pdcp_test_packet_direction[index] == PDCP_DIR_UPLINK)
conf->entity.pdcp_xfrm.pkt_dir = RTE_SECURITY_PDCP_UPLINK;
@@ -1018,6 +1059,8 @@ test_reorder_gap_fill(struct pdcp_test_conf *ul_conf)
/* Check that packets in correct order */
ASSERT_TRUE_OR_GOTO(array_asc_sorted_check(out_mb, nb_success,
sn_size), exit,
"Error occurred during packet drain\n");
+ ASSERT_TRUE_OR_GOTO(testsuite_params.timer_is_running == false, exit,
+ "Timer should be stopped after full drain\n");
ret = TEST_SUCCESS;
exit:
@@ -1093,6 +1136,170 @@ test_reorder_buffer_full_window_size_sn_12(const struct
pdcp_test_conf *ul_conf)
return ret;
}
+static void
+event_timer_start_cb(void *timer, void *args)
+{
+ struct rte_event_timer *evtims = args;
+ int ret = 0;
+
+ ret = rte_event_timer_arm_burst(timer, &evtims, 1);
+ assert(ret == 1);
+}
+
+static int
+test_expiry_with_event_timer(const struct pdcp_test_conf *ul_conf)
+{
+ struct rte_mbuf *m1 = NULL, *out_mb[1] = {0};
+ uint16_t n = 0, nb_err = 0, nb_try = 5;
+ struct rte_pdcp_entity *pdcp_entity;
+ struct pdcp_test_conf dl_conf;
+ int ret = TEST_FAILED, nb_out;
+ struct rte_event event;
+
+ const int start_count = 0;
+ struct rte_event_timer evtim = {
+ .ev.op = RTE_EVENT_OP_NEW,
+ .ev.queue_id = TEST_EV_QUEUE_ID,
+ .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
+ .ev.priority = RTE_EVENT_DEV_PRIORITY_NORMAL,
+ .ev.event_type = RTE_EVENT_TYPE_TIMER,
+ .state = RTE_EVENT_TIMER_NOT_ARMED,
+ .timeout_ticks = 1,
+ };
+
+ if (ul_conf->entity.pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_DOWNLINK)
+ return TEST_SKIPPED;
+
+ /* Create configuration for actual testing */
+ uplink_to_downlink_convert(ul_conf, &dl_conf);
+ dl_conf.entity.count = start_count;
+ dl_conf.entity.t_reordering.args = &evtim;
+ dl_conf.entity.t_reordering.timer = testsuite_params.timdev;
+ dl_conf.entity.t_reordering.start = event_timer_start_cb;
+
+ pdcp_entity = test_entity_create(&dl_conf, &ret);
+ if (pdcp_entity == NULL)
+ return ret;
+
+ evtim.ev.event_ptr = pdcp_entity;
+
+ /* Send packet with SN > RX_DELIV to create a gap */
+ m1 = generate_packet_for_dl_with_sn(*ul_conf, start_co
[PATCH v2 18/22] test/pdcp: add timer restart case
From: Volodymyr Fialko
Add test to cover the case when t-reordering timer should be restarted on
the same packet.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 67
1 file changed, 67 insertions(+)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index a0e982777d..de3375bb22 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -1072,6 +1072,70 @@ test_reorder_gap_fill(struct pdcp_test_conf *ul_conf)
return ret;
}
+static int
+test_reorder_gap_in_reorder_buffer(const struct pdcp_test_conf *ul_conf)
+{
+ struct rte_mbuf *m = NULL, *out_mb[2] = {0};
+ uint16_t nb_success = 0, nb_err = 0;
+ struct rte_pdcp_entity *pdcp_entity;
+ int ret = TEST_FAILED, nb_out, i;
+ struct pdcp_test_conf dl_conf;
+ uint8_t cdev_id;
+
+ const int start_count = 0;
+
+ if (ul_conf->entity.pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_DOWNLINK)
+ return TEST_SKIPPED;
+
+ /* Create configuration for actual testing */
+ uplink_to_downlink_convert(ul_conf, &dl_conf);
+ dl_conf.entity.count = start_count;
+ pdcp_entity = test_entity_create(&dl_conf, &ret);
+ if (pdcp_entity == NULL)
+ return ret;
+
+ const uint32_t sn_size = dl_conf.entity.pdcp_xfrm.sn_size;
+ cdev_id = dl_conf.entity.dev_id;
+
+ /* Create two gaps [NULL, m1, NULL, m3]*/
+ for (i = 0; i < 2; i++) {
+ m = generate_packet_for_dl_with_sn(*ul_conf, start_count + 2 *
i + 1);
+ ASSERT_TRUE_OR_GOTO(m != NULL, exit, "Could not allocate buffer
for packet\n");
+ nb_success = test_process_packets(pdcp_entity, cdev_id, &m, 1,
out_mb, &nb_err);
+ ASSERT_TRUE_OR_GOTO(nb_err == 0, exit, "Error occurred during
packet process\n");
+ ASSERT_TRUE_OR_GOTO(nb_success == 0, exit, "Packet was not
buffered as expected\n");
+ m = NULL; /* Packet was moved to PDCP lib */
+ }
+
+ /* Generate packet to fill the first gap */
+ m = generate_packet_for_dl_with_sn(*ul_conf, start_count);
+ ASSERT_TRUE_OR_GOTO(m != NULL, exit, "Could not allocate buffer for
packet\n");
+
+ /*
+* Buffered packets after insert [m0, m1, NULL, m3]
+* Only first gap should be filled, timer should be restarted for
second gap
+*/
+ nb_success = test_process_packets(pdcp_entity, cdev_id, &m, 1, out_mb,
&nb_err);
+ ASSERT_TRUE_OR_GOTO(nb_err == 0, exit, "Error occurred during packet
process\n");
+ ASSERT_TRUE_OR_GOTO(nb_success == 2, exit,
+ "Packet count mismatch (received: %i, expected: 2)\n",
nb_success);
+ m = NULL;
+ /* Check that packets in correct order */
+ ASSERT_TRUE_OR_GOTO(array_asc_sorted_check(out_mb, nb_success, sn_size),
+ exit, "Error occurred during packet drain\n");
+ ASSERT_TRUE_OR_GOTO(testsuite_params.timer_is_running == true, exit,
+ "Timer should be restarted after partial drain");
+
+
+ ret = TEST_SUCCESS;
+exit:
+ rte_pktmbuf_free(m);
+ rte_pktmbuf_free_bulk(out_mb, nb_success);
+ nb_out = rte_pdcp_entity_release(pdcp_entity, out_mb);
+ rte_pktmbuf_free_bulk(out_mb, nb_out);
+ return ret;
+}
+
static int
test_reorder_buffer_full_window_size_sn_12(const struct pdcp_test_conf
*ul_conf)
{
@@ -1472,6 +1536,9 @@ static struct unit_test_suite reorder_test_cases = {
TEST_CASE_NAMED_WITH_DATA("test_reorder_gap_fill",
ut_setup_pdcp, ut_teardown_pdcp,
run_test_with_all_known_vec, test_reorder_gap_fill),
+ TEST_CASE_NAMED_WITH_DATA("test_reorder_gap_in_reorder_buffer",
+ ut_setup_pdcp, ut_teardown_pdcp,
+ run_test_with_all_known_vec,
test_reorder_gap_in_reorder_buffer),
TEST_CASE_NAMED_WITH_DATA("test_reorder_buffer_full_window_size_sn_12",
ut_setup_pdcp, ut_teardown_pdcp,
run_test_with_all_known_vec_until_first_pass,
--
2.25.1
[PATCH v2 19/22] pdcp: add support for status report
From: Volodymyr Fialko
Implement status report generation for PDCP entity.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_cnt.c | 158 ---
lib/pdcp/pdcp_cnt.h | 11 ++-
lib/pdcp/pdcp_ctrl_pdu.c | 34 -
lib/pdcp/pdcp_ctrl_pdu.h | 3 +-
lib/pdcp/pdcp_entity.h | 2 +
lib/pdcp/pdcp_process.c | 21 +-
lib/pdcp/rte_pdcp.c | 32 ++--
7 files changed, 233 insertions(+), 28 deletions(-)
diff --git a/lib/pdcp/pdcp_cnt.c b/lib/pdcp/pdcp_cnt.c
index c9b952184b..af027b00d3 100644
--- a/lib/pdcp/pdcp_cnt.c
+++ b/lib/pdcp/pdcp_cnt.c
@@ -2,28 +2,164 @@
* Copyright(C) 2023 Marvell.
*/
+#include
#include
#include "pdcp_cnt.h"
+#include "pdcp_ctrl_pdu.h"
#include "pdcp_entity.h"
+#define SLAB_BYTE_SIZE (RTE_BITMAP_SLAB_BIT_SIZE / 8)
+
+uint32_t
+pdcp_cnt_bitmap_get_memory_footprint(const struct rte_pdcp_entity_conf *conf)
+{
+ uint32_t n_bits = pdcp_window_size_get(conf->pdcp_xfrm.sn_size);
+
+ return rte_bitmap_get_memory_footprint(n_bits);
+}
+
int
-pdcp_cnt_ring_create(struct rte_pdcp_entity *en, const struct
rte_pdcp_entity_conf *conf)
+pdcp_cnt_bitmap_create(struct entity_priv_dl_part *dl, void *bitmap_mem,
uint32_t window_size)
{
- struct entity_priv_dl_part *en_priv_dl;
- uint32_t window_sz;
+ uint32_t mem_size = rte_bitmap_get_memory_footprint(window_size);
- if (en == NULL || conf == NULL)
+ dl->bitmap.bmp = rte_bitmap_init(window_size, bitmap_mem, mem_size);
+ if (dl->bitmap.bmp == NULL)
return -EINVAL;
- if (conf->pdcp_xfrm.pkt_dir == RTE_SECURITY_PDCP_UPLINK)
- return 0;
+ dl->bitmap.size = window_size;
- en_priv_dl = entity_dl_part_get(en);
- window_sz = pdcp_window_size_get(conf->pdcp_xfrm.sn_size);
+ return 0;
+}
- RTE_SET_USED(window_sz);
- RTE_SET_USED(en_priv_dl);
+void
+pdcp_cnt_bitmap_set(struct pdcp_cnt_bitmap bitmap, uint32_t count)
+{
+ rte_bitmap_set(bitmap.bmp, count % bitmap.size);
+}
- return 0;
+bool
+pdcp_cnt_bitmap_is_set(struct pdcp_cnt_bitmap bitmap, uint32_t count)
+{
+ return rte_bitmap_get(bitmap.bmp, count % bitmap.size);
+}
+
+void
+pdcp_cnt_bitmap_range_clear(struct pdcp_cnt_bitmap bitmap, uint32_t start,
uint32_t stop)
+{
+ uint32_t i;
+
+ for (i = start; i < stop; i++)
+ rte_bitmap_clear(bitmap.bmp, i % bitmap.size);
+}
+
+uint16_t
+pdcp_cnt_get_bitmap_size(uint32_t pending_bytes)
+{
+ /*
+* Round up bitmap size to slab size to operate only on slabs sizes,
instead of individual
+* bytes
+*/
+ return RTE_ALIGN_MUL_CEIL(pending_bytes, SLAB_BYTE_SIZE);
+}
+
+static __rte_always_inline uint64_t
+leftover_get(uint64_t slab, uint32_t shift, uint64_t mask)
+{
+ return (slab & mask) << shift;
+}
+
+void
+pdcp_cnt_report_fill(struct pdcp_cnt_bitmap bitmap, struct entity_state state,
+uint8_t *data, uint16_t data_len)
+{
+ uint64_t slab = 0, next_slab = 0, leftover;
+ uint32_t zeros, report_len, diff;
+ uint32_t slab_id, next_slab_id;
+ uint32_t pos = 0, next_pos = 0;
+
+ const uint32_t start_count = state.rx_deliv + 1;
+ const uint32_t nb_slabs = bitmap.size / RTE_BITMAP_SLAB_BIT_SIZE;
+ const uint32_t nb_data_slabs = data_len / SLAB_BYTE_SIZE;
+ const uint32_t start_slab_id = start_count / RTE_BITMAP_SLAB_BIT_SIZE;
+ const uint32_t stop_slab_id = (start_slab_id + nb_data_slabs) %
nb_slabs;
+ const uint32_t shift = start_count % RTE_BITMAP_SLAB_BIT_SIZE;
+ const uint32_t leftover_shift = shift ? RTE_BITMAP_SLAB_BIT_SIZE -
shift : 0;
+ const uint8_t *data_end = RTE_PTR_ADD(data, data_len + SLAB_BYTE_SIZE);
+
+ /* NOTE: Mask required to workaround case - when shift is not needed */
+ const uint64_t leftover_mask = shift ? ~0 : 0;
+
+ /* NOTE: implement scan init at to set custom position */
+ __rte_bitmap_scan_init(bitmap.bmp);
+ while (true) {
+ assert(rte_bitmap_scan(bitmap.bmp, &pos, &slab) == 1);
+ slab_id = pos / RTE_BITMAP_SLAB_BIT_SIZE;
+ if (slab_id >= start_slab_id)
+ break;
+ }
+
+ report_len = nb_data_slabs;
+
+ if (slab_id > start_slab_id) {
+ /* Zero slabs at beginning */
+ zeros = (slab_id - start_slab_id - 1) * SLAB_BYTE_SIZE;
+ memset(data, 0, zeros);
+ data = RTE_PTR_ADD(data, zeros);
+ leftover = leftover_get(slab, leftover_shift, leftover_mask);
+ memcpy(data, &leftover, SLAB_BYTE_SIZE);
+ data = RTE_PTR_ADD(data, SLAB_BYTE_SIZE);
+ report_len -= (slab_id - start_slab_id);
+ }
+
+ while (report_len) {
+ rte_bitmap_scan(bitmap.bmp, &next_pos, &next_slab);
+ next_slab_id = next_pos
[PATCH v2 20/22] pdcp: allocate reorder buffer alongside with entity
From: Volodymyr Fialko
Instead of allocating reorder buffer separately on heap, allocate memory
for it together with rest of entity, and then only initialize buffer via
`rte_reorder_init()`.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_cnt.c | 9 +++
lib/pdcp/pdcp_cnt.h | 3 ++-
lib/pdcp/pdcp_entity.h | 2 +-
lib/pdcp/pdcp_reorder.c | 11 ++--
lib/pdcp/pdcp_reorder.h | 12 ++---
lib/pdcp/rte_pdcp.c | 58 ++---
6 files changed, 55 insertions(+), 40 deletions(-)
diff --git a/lib/pdcp/pdcp_cnt.c b/lib/pdcp/pdcp_cnt.c
index af027b00d3..e1d0634b4d 100644
--- a/lib/pdcp/pdcp_cnt.c
+++ b/lib/pdcp/pdcp_cnt.c
@@ -20,15 +20,14 @@ pdcp_cnt_bitmap_get_memory_footprint(const struct
rte_pdcp_entity_conf *conf)
}
int
-pdcp_cnt_bitmap_create(struct entity_priv_dl_part *dl, void *bitmap_mem,
uint32_t window_size)
+pdcp_cnt_bitmap_create(struct entity_priv_dl_part *dl, uint32_t nb_elem,
+ void *bitmap_mem, uint32_t mem_size)
{
- uint32_t mem_size = rte_bitmap_get_memory_footprint(window_size);
-
- dl->bitmap.bmp = rte_bitmap_init(window_size, bitmap_mem, mem_size);
+ dl->bitmap.bmp = rte_bitmap_init(nb_elem, bitmap_mem, mem_size);
if (dl->bitmap.bmp == NULL)
return -EINVAL;
- dl->bitmap.size = window_size;
+ dl->bitmap.size = nb_elem;
return 0;
}
diff --git a/lib/pdcp/pdcp_cnt.h b/lib/pdcp/pdcp_cnt.h
index 5941b7a406..87b011f9dc 100644
--- a/lib/pdcp/pdcp_cnt.h
+++ b/lib/pdcp/pdcp_cnt.h
@@ -10,7 +10,8 @@
#include "pdcp_entity.h"
uint32_t pdcp_cnt_bitmap_get_memory_footprint(const struct
rte_pdcp_entity_conf *conf);
-int pdcp_cnt_bitmap_create(struct entity_priv_dl_part *dl, void *bitmap_mem,
uint32_t window_size);
+int pdcp_cnt_bitmap_create(struct entity_priv_dl_part *dl, uint32_t nb_elem,
+ void *bitmap_mem, uint32_t mem_size);
void pdcp_cnt_bitmap_set(struct pdcp_cnt_bitmap bitmap, uint32_t count);
bool pdcp_cnt_bitmap_is_set(struct pdcp_cnt_bitmap bitmap, uint32_t count);
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 8e1d6254dd..38fa71acef 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -132,7 +132,7 @@ struct pdcp_cnt_bitmap {
};
/*
- * Layout of PDCP entity: [rte_pdcp_entity] [entity_priv] [entity_dl/ul]
+ * Layout of PDCP entity: [rte_pdcp_entity] [entity_priv] [entity_dl/ul]
[reorder/bitmap]
*/
struct entity_priv {
diff --git a/lib/pdcp/pdcp_reorder.c b/lib/pdcp/pdcp_reorder.c
index 5399f0dc28..bc45f2e19b 100644
--- a/lib/pdcp/pdcp_reorder.c
+++ b/lib/pdcp/pdcp_reorder.c
@@ -8,20 +8,13 @@
#include "pdcp_reorder.h"
int
-pdcp_reorder_create(struct pdcp_reorder *reorder, uint32_t window_size)
+pdcp_reorder_create(struct pdcp_reorder *reorder, size_t nb_elem, void *mem,
size_t mem_size)
{
- reorder->buf = rte_reorder_create("reorder_buffer", SOCKET_ID_ANY,
window_size);
+ reorder->buf = rte_reorder_init(mem, mem_size, "reorder_buffer",
nb_elem);
if (reorder->buf == NULL)
return -rte_errno;
- reorder->window_size = window_size;
reorder->is_active = false;
return 0;
}
-
-void
-pdcp_reorder_destroy(const struct pdcp_reorder *reorder)
-{
- rte_reorder_free(reorder->buf);
-}
diff --git a/lib/pdcp/pdcp_reorder.h b/lib/pdcp/pdcp_reorder.h
index 6a2f61d6ae..7e4f079d4b 100644
--- a/lib/pdcp/pdcp_reorder.h
+++ b/lib/pdcp/pdcp_reorder.h
@@ -9,12 +9,18 @@
struct pdcp_reorder {
struct rte_reorder_buffer *buf;
- uint32_t window_size;
bool is_active;
};
-int pdcp_reorder_create(struct pdcp_reorder *reorder, uint32_t window_size);
-void pdcp_reorder_destroy(const struct pdcp_reorder *reorder);
+int pdcp_reorder_create(struct pdcp_reorder *reorder, size_t nb_elem, void
*mem, size_t mem_size);
+
+/* NOTE: replace with `rte_reorder_memory_footprint_get` after DPDK 23.07 */
+#define SIZE_OF_REORDER_BUFFER (4 * RTE_CACHE_LINE_SIZE)
+static inline size_t
+pdcp_reorder_memory_footprint_get(size_t nb_elem)
+{
+ return SIZE_OF_REORDER_BUFFER + (2 * nb_elem * sizeof(struct rte_mbuf
*));
+}
static inline uint32_t
pdcp_reorder_get_sequential(struct pdcp_reorder *reorder, struct rte_mbuf
**mbufs,
diff --git a/lib/pdcp/rte_pdcp.c b/lib/pdcp/rte_pdcp.c
index ce846d687e..95d2283cef 100644
--- a/lib/pdcp/rte_pdcp.c
+++ b/lib/pdcp/rte_pdcp.c
@@ -12,49 +12,65 @@
#include "pdcp_entity.h"
#include "pdcp_process.h"
-static int bitmap_mem_offset;
+struct entity_layout {
+ size_t bitmap_offset;
+ size_t bitmap_size;
+
+ size_t reorder_buf_offset;
+ size_t reorder_buf_size;
+
+ size_t total_size;
+};
static int
-pdcp_entity_size_get(const struct rte_pdcp_entity_conf *conf)
+pdcp_entity_layout_get(const struct rte_pdcp_entity_conf *conf, struct
entity_layout *layout)
{
- int size;
+ size_t size;
+ const uint32
[PATCH v2 21/22] pdcp: add thread safe processing
From: Volodymyr Fialko
PDCP state has to be guarded for:
- Uplink pre_process:
- tx_next atomic increment
- Downlink pre_process:
- rx_deliv - read
- Downlink post_process:
- rx_deliv, rx_reorder, rx_next - read/write
- bitmask/reorder buffer - read/write
When application requires thread safe processing, the state variables
need to be updated atomically. Add config option to select this option
per entity.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
lib/pdcp/pdcp_entity.h | 46 +
lib/pdcp/pdcp_process.c | 34 +++---
lib/pdcp/rte_pdcp.c | 2 ++
lib/pdcp/rte_pdcp.h | 2 ++
4 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 38fa71acef..2dd6d2417d 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "pdcp_reorder.h"
@@ -162,6 +163,8 @@ struct entity_priv {
uint64_t is_status_report_required : 1;
/** Is out-of-order delivery enabled */
uint64_t is_out_of_order_delivery : 1;
+ /** Is thread safety disabled */
+ uint64_t is_thread_safety_disabled : 1;
} flags;
/** Crypto op pool. */
struct rte_mempool *cop_pool;
@@ -175,6 +178,8 @@ struct entity_priv {
uint8_t dev_id;
};
+typedef rte_spinlock_t pdcp_lock_t;
+
struct entity_priv_dl_part {
/** PDCP would need to track the count values that are already
received.*/
struct pdcp_cnt_bitmap bitmap;
@@ -182,6 +187,8 @@ struct entity_priv_dl_part {
struct pdcp_t_reordering t_reorder;
/** Reorder packet buffer */
struct pdcp_reorder reorder;
+ /* Lock to protect concurrent updates */
+ pdcp_lock_t lock;
/** Bitmap memory region */
uint8_t bitmap_mem[0];
};
@@ -257,4 +264,43 @@ pdcp_hfn_max(enum rte_security_pdcp_sn_size sn_size)
return (1 << (32 - sn_size)) - 1;
}
+static inline uint32_t
+pdcp_atomic_inc(const struct entity_priv *en_priv, uint32_t *val)
+{
+ if (en_priv->flags.is_thread_safety_disabled)
+ return (*val)++;
+ else
+ return __atomic_fetch_add(val, 1, __ATOMIC_RELAXED);
+}
+
+static inline void
+pdcp_lock_init(const struct rte_pdcp_entity *entity)
+{
+ struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
+ struct entity_priv *en_priv = entity_priv_get(entity);
+
+ if (!en_priv->flags.is_thread_safety_disabled)
+ rte_spinlock_init(&dl->lock);
+}
+
+static inline void
+pdcp_lock_lock(const struct rte_pdcp_entity *entity)
+{
+ struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
+ struct entity_priv *en_priv = entity_priv_get(entity);
+
+ if (!en_priv->flags.is_thread_safety_disabled)
+ rte_spinlock_lock(&dl->lock);
+}
+
+static inline void
+pdcp_lock_unlock(const struct rte_pdcp_entity *entity)
+{
+ struct entity_priv_dl_part *dl = entity_dl_part_get(entity);
+ struct entity_priv *en_priv = entity_priv_get(entity);
+
+ if (!en_priv->flags.is_thread_safety_disabled)
+ rte_spinlock_unlock(&dl->lock);
+}
+
#endif /* PDCP_ENTITY_H */
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index cdadc9b6b8..0bafa3447a 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -369,7 +369,7 @@ pdcp_pre_process_uplane_sn_12_ul_set_sn(struct entity_priv
*en_priv, struct rte_
return false;
/* Update sequence num in the PDU header */
- *count = en_priv->state.tx_next++;
+ *count = pdcp_atomic_inc(en_priv, &en_priv->state.tx_next);
sn = pdcp_sn_from_count_get(*count, RTE_SECURITY_PDCP_SN_SIZE_12);
pdu_hdr->d_c = RTE_PDCP_PDU_TYPE_DATA;
@@ -451,7 +451,7 @@ pdcp_pre_process_uplane_sn_18_ul_set_sn(struct entity_priv
*en_priv, struct rte_
return false;
/* Update sequence num in the PDU header */
- *count = en_priv->state.tx_next++;
+ *count = pdcp_atomic_inc(en_priv, &en_priv->state.tx_next);
sn = pdcp_sn_from_count_get(*count, RTE_SECURITY_PDCP_SN_SIZE_18);
pdu_hdr->d_c = RTE_PDCP_PDU_TYPE_DATA;
@@ -561,7 +561,7 @@ pdcp_pre_process_cplane_sn_12_ul(const struct
rte_pdcp_entity *entity, struct rt
memset(mac_i, 0, PDCP_MAC_I_LEN);
/* Update sequence number in the PDU header */
- count = en_priv->state.tx_next++;
+ count = pdcp_atomic_inc(en_priv, &en_priv->state.tx_next);
sn = pdcp_sn_from_count_get(count,
RTE_SECURITY_PDCP_SN_SIZE_12);
pdu_hdr->sn_11_8 = ((sn & 0xf00) >> 8);
@@ -654,7 +654,9 @@ pdcp_pre_process_uplane_sn_12_dl_flags(const struct
rte_pdcp_entity *entity,
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE
[PATCH v2 22/22] test/pdcp: add PDCP status report cases
From: Volodymyr Fialko
Test PDCP status report generation.
Signed-off-by: Anoob Joseph
Signed-off-by: Volodymyr Fialko
---
app/test/test_pdcp.c | 310 +++
1 file changed, 310 insertions(+)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index de3375bb22..c9e4b894ac 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -2,6 +2,7 @@
* Copyright(C) 2023 Marvell.
*/
+#include
#include
#include
#include
@@ -43,6 +44,9 @@ struct pdcp_testsuite_params {
struct rte_event_timer_adapter *timdev;
bool timer_is_running;
uint64_t min_resolution_ns;
+ struct rte_pdcp_up_ctrl_pdu_hdr *status_report;
+ uint32_t status_report_bitmask_capacity;
+ uint8_t *ctrl_pdu_buf;
};
static struct pdcp_testsuite_params testsuite_params;
@@ -139,6 +143,18 @@ static struct rte_pdcp_t_reordering t_reorder_timer = {
.stop = pdcp_timer_stop_cb,
};
+static inline void
+bitmask_set_bit(uint8_t *mask, uint32_t bit)
+{
+ mask[bit / 8] |= (1 << bit % 8);
+}
+
+static inline bool
+bitmask_is_bit_set(const uint8_t *mask, uint32_t bit)
+{
+ return mask[bit / 8] & (1 << (bit % 8));
+}
+
static inline int
pdcp_hdr_size_get(enum rte_security_pdcp_sn_size sn_size)
{
@@ -285,6 +301,21 @@ testsuite_setup(void)
goto cop_pool_free;
}
+ /* Allocate memory for longest possible status report */
+ ts_params->status_report_bitmask_capacity = RTE_PDCP_CTRL_PDU_SIZE_MAX -
+ sizeof(struct rte_pdcp_up_ctrl_pdu_hdr);
+ ts_params->status_report = rte_zmalloc(NULL,
RTE_PDCP_CTRL_PDU_SIZE_MAX, 0);
+ if (ts_params->status_report == NULL) {
+ RTE_LOG(ERR, USER1, "Could not allocate status report\n");
+ goto cop_pool_free;
+ }
+
+ ts_params->ctrl_pdu_buf = rte_zmalloc(NULL, RTE_PDCP_CTRL_PDU_SIZE_MAX,
0);
+ if (ts_params->ctrl_pdu_buf == NULL) {
+ RTE_LOG(ERR, USER1, "Could not allocate status report data\n");
+ goto cop_pool_free;
+ }
+
return 0;
cop_pool_free:
@@ -293,6 +324,8 @@ testsuite_setup(void)
mbuf_pool_free:
rte_mempool_free(ts_params->mbuf_pool);
ts_params->mbuf_pool = NULL;
+ rte_free(ts_params->status_report);
+ rte_free(ts_params->ctrl_pdu_buf);
return TEST_FAILED;
}
@@ -315,6 +348,9 @@ testsuite_teardown(void)
rte_mempool_free(ts_params->mbuf_pool);
ts_params->mbuf_pool = NULL;
+
+ rte_free(ts_params->status_report);
+ rte_free(ts_params->ctrl_pdu_buf);
}
static int
@@ -1364,6 +1400,244 @@ test_expiry_with_rte_timer(const struct pdcp_test_conf
*ul_conf)
return ret;
}
+static struct rte_pdcp_up_ctrl_pdu_hdr *
+pdcp_status_report_init(uint32_t fmc)
+{
+ struct rte_pdcp_up_ctrl_pdu_hdr *hdr = testsuite_params.status_report;
+
+ hdr->d_c = RTE_PDCP_PDU_TYPE_CTRL;
+ hdr->pdu_type = RTE_PDCP_CTRL_PDU_TYPE_STATUS_REPORT;
+ hdr->fmc = rte_cpu_to_be_32(fmc);
+ hdr->r = 0;
+ memset(hdr->bitmap, 0, testsuite_params.status_report_bitmask_capacity);
+
+ return hdr;
+}
+
+static uint32_t
+pdcp_status_report_len(void)
+{
+ struct rte_pdcp_up_ctrl_pdu_hdr *hdr = testsuite_params.status_report;
+ uint32_t i;
+
+ for (i = testsuite_params.status_report_bitmask_capacity; i != 0; i--) {
+ if (hdr->bitmap[i - 1])
+ return i;
+ }
+
+ return 0;
+}
+
+static int
+pdcp_status_report_verify(struct rte_mbuf *status_report,
+const struct rte_pdcp_up_ctrl_pdu_hdr *expected_hdr,
uint32_t expected_len)
+{
+ uint32_t received_len = rte_pktmbuf_pkt_len(status_report);
+ uint8_t *received_buf = testsuite_params.ctrl_pdu_buf;
+ int ret;
+
+ ret = pktmbuf_read_into(status_report, received_buf,
RTE_PDCP_CTRL_PDU_SIZE_MAX);
+ TEST_ASSERT_SUCCESS(ret, "Failed to copy status report pkt into
continuous buffer");
+
+ debug_hexdump(stdout, "Received:", received_buf, received_len);
+ debug_hexdump(stdout, "Expected:", expected_hdr, expected_len);
+
+ TEST_ASSERT_EQUAL(expected_len, received_len,
+ "Mismatch in packet lengths [expected: %d, received:
%d]",
+ expected_len, received_len);
+
+ TEST_ASSERT_BUFFERS_ARE_EQUAL(received_buf, expected_hdr, expected_len,
+"Generated packet not as expected");
+
+ return 0;
+}
+
+static int
+test_status_report_gen(const struct pdcp_test_conf *ul_conf,
+ const struct rte_pdcp_up_ctrl_pdu_hdr *hdr,
+ uint32_t bitmap_len)
+{
+ struct rte_mbuf *status_report = NULL, **out_mb, *m;
+ uint16_t nb_success = 0, nb_err = 0;
+ struct rte_pdcp_entity *pdcp_entity;
+ struct pdcp_test_conf dl_conf;
+ int ret = TEST_FAILED, nb_out;
+ uint3
[PATCH v3] dmadev: add tracepoints
Add tracepoints at important APIs for tracing support.
Signed-off-by: Chengwen Feng
Acked-by: Morten Brørup
---
v3: Address Morten's comment:
Move stats_get and vchan_status and to trace_fp.h.
v2: Address Morten's comment:
Make stats_get as fast-path trace-points.
Place fast-path trace-point functions behind in version.map.
---
lib/dmadev/meson.build | 2 +-
lib/dmadev/rte_dmadev.c | 39 ++--
lib/dmadev/rte_dmadev.h | 56 ---
lib/dmadev/rte_dmadev_trace.h| 110 ++
lib/dmadev/rte_dmadev_trace_fp.h | 136 +++
lib/dmadev/rte_dmadev_trace_points.c | 59
lib/dmadev/version.map | 10 ++
7 files changed, 391 insertions(+), 21 deletions(-)
create mode 100644 lib/dmadev/rte_dmadev_trace.h
create mode 100644 lib/dmadev/rte_dmadev_trace_fp.h
create mode 100644 lib/dmadev/rte_dmadev_trace_points.c
diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
index 2f17587b75..e0d90aea67 100644
--- a/lib/dmadev/meson.build
+++ b/lib/dmadev/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2021 HiSilicon Limited.
-sources = files('rte_dmadev.c')
+sources = files('rte_dmadev.c', 'rte_dmadev_trace_points.c')
headers = files('rte_dmadev.h')
indirect_headers += files('rte_dmadev_core.h')
driver_sdk_headers += files('rte_dmadev_pmd.h')
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 8c095e1f35..25fa78de8f 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -17,6 +17,7 @@
#include "rte_dmadev.h"
#include "rte_dmadev_pmd.h"
+#include "rte_dmadev_trace.h"
static int16_t dma_devices_max;
@@ -434,6 +435,8 @@ rte_dma_info_get(int16_t dev_id, struct rte_dma_info
*dev_info)
dev_info->numa_node = dev->device->numa_node;
dev_info->nb_vchans = dev->data->dev_conf.nb_vchans;
+ rte_dma_trace_info_get(dev_id, dev_info);
+
return 0;
}
@@ -483,6 +486,8 @@ rte_dma_configure(int16_t dev_id, const struct rte_dma_conf
*dev_conf)
memcpy(&dev->data->dev_conf, dev_conf,
sizeof(struct rte_dma_conf));
+ rte_dma_trace_configure(dev_id, dev_conf, ret);
+
return ret;
}
@@ -509,6 +514,7 @@ rte_dma_start(int16_t dev_id)
goto mark_started;
ret = (*dev->dev_ops->dev_start)(dev);
+ rte_dma_trace_start(dev_id, ret);
if (ret != 0)
return ret;
@@ -535,6 +541,7 @@ rte_dma_stop(int16_t dev_id)
goto mark_stopped;
ret = (*dev->dev_ops->dev_stop)(dev);
+ rte_dma_trace_stop(dev_id, ret);
if (ret != 0)
return ret;
@@ -565,6 +572,8 @@ rte_dma_close(int16_t dev_id)
if (ret == 0)
dma_release(dev);
+ rte_dma_trace_close(dev_id, ret);
+
return ret;
}
@@ -655,14 +664,18 @@ rte_dma_vchan_setup(int16_t dev_id, uint16_t vchan,
if (*dev->dev_ops->vchan_setup == NULL)
return -ENOTSUP;
- return (*dev->dev_ops->vchan_setup)(dev, vchan, conf,
+ ret = (*dev->dev_ops->vchan_setup)(dev, vchan, conf,
sizeof(struct rte_dma_vchan_conf));
+ rte_dma_trace_vchan_setup(dev_id, vchan, conf, ret);
+
+ return ret;
}
int
rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct rte_dma_stats *stats)
{
const struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(dev_id) || stats == NULL)
return -EINVAL;
@@ -677,14 +690,18 @@ rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct
rte_dma_stats *stats)
if (*dev->dev_ops->stats_get == NULL)
return -ENOTSUP;
memset(stats, 0, sizeof(struct rte_dma_stats));
- return (*dev->dev_ops->stats_get)(dev, vchan, stats,
- sizeof(struct rte_dma_stats));
+ ret = (*dev->dev_ops->stats_get)(dev, vchan, stats,
+sizeof(struct rte_dma_stats));
+ rte_dma_trace_stats_get(dev_id, vchan, stats, ret);
+
+ return ret;
}
int
rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
{
struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
@@ -698,13 +715,17 @@ rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
if (*dev->dev_ops->stats_reset == NULL)
return -ENOTSUP;
- return (*dev->dev_ops->stats_reset)(dev, vchan);
+ ret = (*dev->dev_ops->stats_reset)(dev, vchan);
+ rte_dma_trace_stats_reset(dev_id, vchan, ret);
+
+ return ret;
}
int
rte_dma_vchan_status(int16_t dev_id, uint16_t vchan, enum rte_dma_vchan_status
*status)
{
struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+ int ret;
if (!rte_dma_is_valid(de
Re: [PATCH v2] dmadev: add tracepoints
Hi Morten, Both fix in v3, thanks. On 2023/4/14 20:46, Morten Brørup wrote: >> From: Chengwen Feng [mailto:fengcheng...@huawei.com] >> Sent: Friday, 14 April 2023 11.09 >> >> Add tracepoints at important APIs for tracing support. >> >> Signed-off-by: Chengwen Feng >> >> --- >> v2: Address Morten's comment: >> Make stats_get as fast-path trace-points. >> Place fast-path trace-point functions behind in version.map. > > ... > >> +RTE_TRACE_POINT( >> +rte_dma_trace_vchan_status, > > rte_dma_trace_vchan_status should also be a FP trace point. > >> +RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan, >> + enum rte_dma_vchan_status *status, int ret), >> +int vchan_status = *status; >> +rte_trace_point_emit_i16(dev_id); >> +rte_trace_point_emit_u16(vchan); >> +rte_trace_point_emit_int(vchan_status); >> +rte_trace_point_emit_int(ret); >> +) >> + >> +RTE_TRACE_POINT( >> +rte_dma_trace_dump, >> +RTE_TRACE_POINT_ARGS(int16_t dev_id, FILE *f, int ret), >> +rte_trace_point_emit_i16(dev_id); >> +rte_trace_point_emit_ptr(f); >> +rte_trace_point_emit_int(ret); >> +) >> + >> +/* Fast path trace points */ > > Don't add the fast path trace points here. Add them to the > rte_dmadev_trace_fp.h file. > >> + >> +/* Called in loop in examples/dma */ >> +RTE_TRACE_POINT_FP( >> +rte_dma_trace_stats_get, >> +RTE_TRACE_POINT_ARGS(int16_t dev_id, uint16_t vchan, >> + struct rte_dma_stats *stats, int ret), >> +rte_trace_point_emit_i16(dev_id); >> +rte_trace_point_emit_u16(vchan); >> +rte_trace_point_emit_u64(stats->submitted); >> +rte_trace_point_emit_u64(stats->completed); >> +rte_trace_point_emit_u64(stats->errors); >> +rte_trace_point_emit_int(ret); >> +) > > With those two fixes, you may add: > > Acked-by: Morten Brørup > > > . >
[PATCH v6 03/15] eal: use barrier intrinsics
Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.
Signed-off-by: Tyler Retzlaff
Acked-by: Bruce Richardson
Acked-by: Konstantin Ananyev
---
lib/eal/include/generic/rte_atomic.h | 4
lib/eal/x86/include/rte_atomic.h | 4
2 files changed, 8 insertions(+)
diff --git a/lib/eal/include/generic/rte_atomic.h
b/lib/eal/include/generic/rte_atomic.h
index 234b268..e973184 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -116,9 +116,13 @@
* Guarantees that operation reordering does not occur at compile time
* for operations directly before and after the barrier.
*/
+#ifndef RTE_TOOLCHAIN_MSVC
#definerte_compiler_barrier() do { \
asm volatile ("" : : : "memory"); \
} while(0)
+#else
+#define rte_compiler_barrier() _ReadWriteBarrier()
+#endif
/**
* Synchronization fence between threads based on the specified memory order.
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index f2ee1a9..569d3ab 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -66,11 +66,15 @@
static __rte_always_inline void
rte_smp_mb(void)
{
+#ifndef RTE_TOOLCHAIN_MSVC
#ifdef RTE_ARCH_I686
asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
#else
asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
#endif
+#else
+ _mm_mfence();
+#endif
}
#define rte_io_mb() rte_mb()
--
1.8.3.1
[PATCH v6 01/15] eal: use rdtsc intrinsic
Inline assembly is not supported for MSVC x64. Convert code to use
__rdtsc intrinsic.
Signed-off-by: Tyler Retzlaff
Acked-by: Konstantin Ananyev
---
lib/eal/x86/include/rte_cycles.h | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/eal/x86/include/rte_cycles.h b/lib/eal/x86/include/rte_cycles.h
index a461a4d..cca5122 100644
--- a/lib/eal/x86/include/rte_cycles.h
+++ b/lib/eal/x86/include/rte_cycles.h
@@ -6,6 +6,12 @@
#ifndef _RTE_CYCLES_X86_64_H_
#define _RTE_CYCLES_X86_64_H_
+#ifndef RTE_TOOLCHAIN_MSVC
+#include
+#else
+#include
+#endif
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -23,6 +29,7 @@
static inline uint64_t
rte_rdtsc(void)
{
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
union {
uint64_t tsc_64;
RTE_STD_C11
@@ -32,7 +39,6 @@
};
} tsc;
-#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
if (unlikely(rte_cycles_vmware_tsc_map)) {
/* ecx = 0x1 corresponds to the physical TSC for VMware */
asm volatile("rdpmc" :
@@ -42,11 +48,7 @@
return tsc.tsc_64;
}
#endif
-
- asm volatile("rdtsc" :
-"=a" (tsc.lo_32),
-"=d" (tsc.hi_32));
- return tsc.tsc_64;
+ return __rdtsc();
}
static inline uint64_t
--
1.8.3.1
[PATCH v6 00/15] msvc integration changes
In accordance with draft plan
http://mails.dpdk.org/archives/web/2023-February/002023.html
introduces conditionally compiled code to enable building with MSVC that
_does not_ require C99/C11 meaning it can be integrated now.
This series covers minimal changes for item #2 in draft plan for EAL
dependencies kvargs, telemetry and consumed EAL public headers.
Note if any patch in the series requires in-depth discussion I'll
detach it from this series for separate submission & more focused
discussion so it doesn't block the entire series.
Note other "common" intrinsics were investigated for viability but
were not adopted either because they were not available on older
versions of gcc or because they generate different code for msvc
vs gcc.
v6:
* convert / expand likely/unlikely macros to _Bool type
* expand __extension__ empty it's cleaner to do this for now
instead of modifying the whole tree
* provide msvc container_of not based on gcc expression
statement extension
* add patch that stops defining typeof (C23 keyword) when
building with msvc
v5:
* remove accidental line removal in barrier patch
* update prefetch patch to use intrinsics for all toolchains
* remove x86 specific changes for byte swap patch since
msvc intrinsics are processor agnostic always use
intrinsics from generic include
* expand __rte_packed empty for msvc packing will be addressed
in a separate series
v4:
* update rdtsc patch to use gcc intrinsics
* update rtm patch to use gcc intrinsics
* drop patch disable json print formatting, we will utilize
series removing VLAs from Bruce
* added patch using prefetch intrinsics for msvc
* added patch using byte swap intrinsics for msvc
* added patch hiding typdefs for msvc using gcc vector
extension
* added patch defining MSVC as little endian always
v3:
* v3 does not group together conditional blocks when experimented
with it didn't reduce conditionals enough to make it worth
while. once msvc tests are at a running point i suggest
a narrow targeted discussion about code organization without
blocking this series
* v3 does not attempt to refactor to use intrinsics for non-msvc
compilers. again this should be done as a separate follow-up
series later if desired
* fix expansion of likely and unlikely macros
* remove unnecessary define for rte_smp_{r,w}mb it is sufficient
for these to be compiler barriers on x86
* add a new patch to use __cpuid and __cpuidex intrinsics when
building with msvc
* add a new patch to use _umonitor, _umwait and _tpause intrinsics
when building with msvc
v2:
* use _mm_{l,s,m}fence intrinsics for rte_smp_{r,w,}mb macros
are intended to be memory barriers not compiler barriers on
x86_64
Tyler Retzlaff (15):
eal: use rdtsc intrinsic
eal: use rtm and xtest intrinsics
eal: use barrier intrinsics
eal: use cpuid and cpuidex intrinsics
eal: use umonitor umwait and tpause intrinsics
eal: use prefetch intrinsics
eal: use byte swap intrinsics
eal: typedef cpu flag enum as int
eal: hide GCC extension based alignment markers
eal: hide typedefs based on GCC vector extensions
eal: expand most macros to empty when using MSVC
eal: exclude exposure of rte atomic APIs for MSVC builds
telemetry: avoid expanding versioned symbol macros on MSVC
eal: always define MSVC as little endian
eal: do not define typeof macro when building with MSVC
config/x86/meson.build | 6
lib/eal/include/generic/rte_atomic.h| 11 ++
lib/eal/include/generic/rte_byteorder.h | 13 +++
lib/eal/include/generic/rte_cpuflags.h | 12 ---
lib/eal/include/generic/rte_vect.h | 4 +++
lib/eal/include/rte_branch_prediction.h | 8 +
lib/eal/include/rte_common.h| 60 +
lib/eal/include/rte_compat.h| 20 +++
lib/eal/x86/include/rte_atomic.h| 8 +
lib/eal/x86/include/rte_byteorder.h | 4 +++
lib/eal/x86/include/rte_cycles.h| 14
lib/eal/x86/include/rte_prefetch.h | 25 +++---
lib/eal/x86/include/rte_rtm.h | 18 +++---
lib/eal/x86/rte_cpuflags.c | 4 +++
lib/eal/x86/rte_cpuid.h | 7
lib/eal/x86/rte_cycles.c| 36
lib/eal/x86/rte_hypervisor.c| 4 +++
lib/eal/x86/rte_power_intrinsics.c | 12 +++
lib/telemetry/telemetry_data.c | 16 +
19 files changed, 254 insertions(+), 28 deletions(-)
--
1.8.3.1
[PATCH v6 02/15] eal: use rtm and xtest intrinsics
Inline assembly is not supported for MSVC x64. Convert code to use
_xend, _xabort and _xtest intrinsics.
Signed-off-by: Tyler Retzlaff
Acked-by: Bruce Richardson
Acked-by: Konstantin Ananyev
---
config/x86/meson.build| 6 ++
lib/eal/x86/include/rte_rtm.h | 18 +-
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..4c0b06c 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -30,6 +30,12 @@ if cc.get_define('__SSE4_2__', args: machine_args) == ''
machine_args += '-msse4'
endif
+# enable restricted transactional memory intrinsics
+# https://gcc.gnu.org/onlinedocs/gcc/x86-transactional-memory-intrinsics.html
+if cc.get_id() != 'msvc'
+machine_args += '-mrtm'
+endif
+
base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
foreach f:base_flags
compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
diff --git a/lib/eal/x86/include/rte_rtm.h b/lib/eal/x86/include/rte_rtm.h
index 36bf498..b84e58e 100644
--- a/lib/eal/x86/include/rte_rtm.h
+++ b/lib/eal/x86/include/rte_rtm.h
@@ -5,6 +5,7 @@
#ifndef _RTE_RTM_H_
#define _RTE_RTM_H_ 1
+#include
/* Official RTM intrinsics interface matching gcc/icc, but works
on older gcc compatible compilers and binutils. */
@@ -28,31 +29,22 @@
static __rte_always_inline
unsigned int rte_xbegin(void)
{
- unsigned int ret = RTE_XBEGIN_STARTED;
-
- asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
- return ret;
+ return _xbegin();
}
static __rte_always_inline
void rte_xend(void)
{
-asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+ _xend();
}
/* not an inline function to workaround a clang bug with -O0 */
-#define rte_xabort(status) do { \
- asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory"); \
-} while (0)
+#define rte_xabort(status) _xabort(status)
static __rte_always_inline
int rte_xtest(void)
{
- unsigned char out;
-
- asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
- "=r" (out) :: "memory");
- return out;
+ return _xtest();
}
#ifdef __cplusplus
--
1.8.3.1
[PATCH v6 04/15] eal: use cpuid and cpuidex intrinsics
Inline assembly is not supported for MSVC x64 instead use __cpuid
and __cpuidex intrinsics.
Signed-off-by: Tyler Retzlaff
---
lib/eal/x86/rte_cpuflags.c | 4
lib/eal/x86/rte_cpuid.h | 7 +++
lib/eal/x86/rte_cycles.c | 36
lib/eal/x86/rte_hypervisor.c | 4
4 files changed, 51 insertions(+)
diff --git a/lib/eal/x86/rte_cpuflags.c b/lib/eal/x86/rte_cpuflags.c
index d6b5182..e3624e7 100644
--- a/lib/eal/x86/rte_cpuflags.c
+++ b/lib/eal/x86/rte_cpuflags.c
@@ -165,9 +165,13 @@ struct feature_entry {
if (maxleaf < feat->leaf)
return 0;
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid_count(feat->leaf, feat->subleaf,
regs[RTE_REG_EAX], regs[RTE_REG_EBX],
regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+ __cpuidex(regs, feat->leaf, feat->subleaf);
+#endif
/* check if the feature is enabled */
return (regs[feat->reg] >> feat->bit) & 1;
diff --git a/lib/eal/x86/rte_cpuid.h b/lib/eal/x86/rte_cpuid.h
index b773ad9..c6abaad 100644
--- a/lib/eal/x86/rte_cpuid.h
+++ b/lib/eal/x86/rte_cpuid.h
@@ -5,7 +5,9 @@
#ifndef RTE_CPUID_H
#define RTE_CPUID_H
+#ifndef RTE_TOOLCHAIN_MSVC
#include
+#endif
enum cpu_register_t {
RTE_REG_EAX = 0,
@@ -16,4 +18,9 @@ enum cpu_register_t {
typedef uint32_t cpuid_registers_t[4];
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s);
+#endif
+
#endif /* RTE_CPUID_H */
diff --git a/lib/eal/x86/rte_cycles.c b/lib/eal/x86/rte_cycles.c
index 0e695ca..db56d39 100644
--- a/lib/eal/x86/rte_cycles.c
+++ b/lib/eal/x86/rte_cycles.c
@@ -4,7 +4,11 @@
#include
#include
+#ifndef RTE_TOOLCHAIN_MSVC
#include
+#else
+#define bit_AVX (1 << 28)
+#endif
#include "eal_private.h"
@@ -82,9 +86,25 @@
return 0;
}
+#ifdef RTE_TOOLCHAIN_MSVC
+int
+__get_cpuid_max(unsigned int e, unsigned int *s)
+{
+ uint32_t cpuinfo[4];
+
+ __cpuid(cpuinfo, e);
+ if (s)
+ *s = cpuinfo[1];
+ return cpuinfo[0];
+}
+#endif
+
uint64_t
get_tsc_freq_arch(void)
{
+#ifdef RTE_TOOLCHAIN_MSVC
+ int cpuinfo[4];
+#endif
uint64_t tsc_hz = 0;
uint32_t a, b, c, d, maxleaf;
uint8_t mult, model;
@@ -97,14 +117,30 @@
maxleaf = __get_cpuid_max(0, NULL);
if (maxleaf >= 0x15) {
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(0x15, a, b, c, d);
+#else
+ __cpuid(cpuinfo, 0x15);
+ a = cpuinfo[0];
+ b = cpuinfo[1];
+ c = cpuinfo[2];
+ d = cpuinfo[3];
+#endif
/* EBX : TSC/Crystal ratio, ECX : Crystal Hz */
if (b && c)
return c * (b / a);
}
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(0x1, a, b, c, d);
+#else
+ __cpuid(cpuinfo, 0x1);
+ a = cpuinfo[0];
+ b = cpuinfo[1];
+ c = cpuinfo[2];
+ d = cpuinfo[3];
+#endif
model = rte_cpu_get_model(a);
if (check_model_wsm_nhm(model))
diff --git a/lib/eal/x86/rte_hypervisor.c b/lib/eal/x86/rte_hypervisor.c
index c38cfc0..a9c2017 100644
--- a/lib/eal/x86/rte_hypervisor.c
+++ b/lib/eal/x86/rte_hypervisor.c
@@ -23,9 +23,13 @@ enum rte_hypervisor
if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_HYPERVISOR))
return RTE_HYPERVISOR_NONE;
+#ifndef RTE_TOOLCHAIN_MSVC
__cpuid(HYPERVISOR_INFO_LEAF,
regs[RTE_REG_EAX], regs[RTE_REG_EBX],
regs[RTE_REG_ECX], regs[RTE_REG_EDX]);
+#else
+ __cpuid(regs, HYPERVISOR_INFO_LEAF);
+#endif
for (reg = 1; reg < 4; reg++)
memcpy(name + (reg - 1) * 4, ®s[reg], 4);
name[12] = '\0';
--
1.8.3.1
[PATCH v6 05/15] eal: use umonitor umwait and tpause intrinsics
Inline assembly is not supported for MSVC x64 instead use _umonitor,
_umwait and _tpause intrinsics.
Signed-off-by: Tyler Retzlaff
---
lib/eal/x86/rte_power_intrinsics.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/eal/x86/rte_power_intrinsics.c
b/lib/eal/x86/rte_power_intrinsics.c
index f749da9..7d83c24 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -109,9 +109,13 @@
*/
/* set address for UMONITOR */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
:
: "D"(pmc->addr));
+#else
+ _umonitor(pmc->addr);
+#endif
/* now that we've put this address into monitor, we can unlock */
rte_spinlock_unlock(&s->lock);
@@ -123,10 +127,14 @@
goto end;
/* execute UMWAIT */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
: /* ignore rflags */
: "D"(0), /* enter C0.2 */
"a"(tsc_l), "d"(tsc_h));
+#else
+ _umwait(tsc_l, tsc_h);
+#endif
end:
/* erase sleep address */
@@ -153,10 +161,14 @@
return -ENOTSUP;
/* execute TPAUSE */
+#ifndef RTE_TOOLCHAIN_MSVC
asm volatile(".byte 0x66, 0x0f, 0xae, 0xf7;"
: /* ignore rflags */
: "D"(0), /* enter C0.2 */
"a"(tsc_l), "d"(tsc_h));
+#else
+ _tpause(tsc_l, tsc_h);
+#endif
return 0;
}
--
1.8.3.1
[PATCH v6 06/15] eal: use prefetch intrinsics
Inline assembly is not supported for MSVC x64 instead use _mm_prefetch
and _mm_cldemote intrinsics.
Signed-off-by: Tyler Retzlaff
Acked-by: Bruce Richardson
---
lib/eal/x86/include/rte_prefetch.h | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/eal/x86/include/rte_prefetch.h
b/lib/eal/x86/include/rte_prefetch.h
index 7fd01c4..239e611 100644
--- a/lib/eal/x86/include/rte_prefetch.h
+++ b/lib/eal/x86/include/rte_prefetch.h
@@ -9,30 +9,38 @@
extern "C" {
#endif
+#include
+
#include
#include
#include "generic/rte_prefetch.h"
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
static inline void rte_prefetch0(const volatile void *p)
{
- asm volatile ("prefetcht0 %[p]" : : [p] "m" (*(const volatile char
*)p));
+ _mm_prefetch((const void *)p, _MM_HINT_T0);
}
static inline void rte_prefetch1(const volatile void *p)
{
- asm volatile ("prefetcht1 %[p]" : : [p] "m" (*(const volatile char
*)p));
+ _mm_prefetch((const void *)p, _MM_HINT_T1);
}
static inline void rte_prefetch2(const volatile void *p)
{
- asm volatile ("prefetcht2 %[p]" : : [p] "m" (*(const volatile char
*)p));
+ _mm_prefetch((const void *)p, _MM_HINT_T2);
}
static inline void rte_prefetch_non_temporal(const volatile void *p)
{
- asm volatile ("prefetchnta %[p]" : : [p] "m" (*(const volatile char
*)p));
+ _mm_prefetch((const void *)p, _MM_HINT_NTA);
}
+#pragma GCC diagnostic pop
+
+#ifndef RTE_TOOLCHAIN_MSVC
/*
* We use raw byte codes for now as only the newest compiler
* versions support this instruction natively.
@@ -43,6 +51,15 @@ static inline void rte_prefetch_non_temporal(const volatile
void *p)
{
asm volatile(".byte 0x0f, 0x1c, 0x06" :: "S" (p));
}
+#else
+__rte_experimental
+static inline void
+rte_cldemote(const volatile void *p)
+{
+ _mm_cldemote(p);
+}
+#endif
+
#ifdef __cplusplus
}
--
1.8.3.1
[PATCH v6 07/15] eal: use byte swap intrinsics
Inline assembly is not supported for MSVC x64 instead expand
use _byteswap_u{ushort,ulong,uint64} intrinsics instead.
Signed-off-by: Tyler Retzlaff
---
lib/eal/include/generic/rte_byteorder.h | 11 +++
lib/eal/x86/include/rte_byteorder.h | 4
2 files changed, 15 insertions(+)
diff --git a/lib/eal/include/generic/rte_byteorder.h
b/lib/eal/include/generic/rte_byteorder.h
index a67e1d7..1e32a1b 100644
--- a/lib/eal/include/generic/rte_byteorder.h
+++ b/lib/eal/include/generic/rte_byteorder.h
@@ -234,6 +234,7 @@
#endif /* __DOXYGEN__ */
#ifdef RTE_FORCE_INTRINSICS
+#ifndef RTE_TOOLCHAIN_MSVC
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
#define rte_bswap16(x) __builtin_bswap16(x)
#endif
@@ -241,6 +242,16 @@
#define rte_bswap32(x) __builtin_bswap32(x)
#define rte_bswap64(x) __builtin_bswap64(x)
+#else
+/*
+ * note: we may want to #pragma intrsinsic(_byteswap_u{short,long,uint64})
+ */
+#define rte_bswap16(x) _byteswap_ushort(x)
+
+#define rte_bswap32(x) _byteswap_ulong(x)
+
+#define rte_bswap64(x) _byteswap_uint64(x)
+#endif
#endif
diff --git a/lib/eal/x86/include/rte_byteorder.h
b/lib/eal/x86/include/rte_byteorder.h
index a2dfecc..3d6e58e 100644
--- a/lib/eal/x86/include/rte_byteorder.h
+++ b/lib/eal/x86/include/rte_byteorder.h
@@ -18,6 +18,7 @@
#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
#endif
+#ifndef RTE_TOOLCHAIN_MSVC
/*
* An architecture-optimized byte swap for a 16-bit value.
*
@@ -69,6 +70,7 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
rte_arch_bswap16(x)))
#endif
#endif
+#endif
#define rte_cpu_to_le_16(x) (x)
#define rte_cpu_to_le_32(x) (x)
@@ -86,11 +88,13 @@ static inline uint32_t rte_arch_bswap32(uint32_t _x)
#define rte_be_to_cpu_32(x) rte_bswap32(x)
#define rte_be_to_cpu_64(x) rte_bswap64(x)
+#ifndef RTE_TOOLCHAIN_MSVC
#ifdef RTE_ARCH_I686
#include "rte_byteorder_32.h"
#else
#include "rte_byteorder_64.h"
#endif
+#endif
#ifdef __cplusplus
}
--
1.8.3.1
[PATCH v6 09/15] eal: hide GCC extension based alignment markers
When compiling with MSVC don't expose typedefs used as alignment markers. Signed-off-by: Tyler Retzlaff --- lib/eal/include/rte_common.h | 4 1 file changed, 4 insertions(+) diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h index 15765b4..2f464e3 100644 --- a/lib/eal/include/rte_common.h +++ b/lib/eal/include/rte_common.h @@ -460,6 +460,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) /*** Structure alignment markers / +#ifndef RTE_TOOLCHAIN_MSVC + /** Generic marker for any place in a structure. */ __extension__ typedef void*RTE_MARKER[0]; /** Marker for 1B alignment in a structure. */ @@ -471,6 +473,8 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) /** Marker for 8B alignment in a structure. */ __extension__ typedef uint64_t RTE_MARKER64[0]; +#endif + /** * Combines 32b inputs most significant set bits into the least * significant bits to construct a value with the same MSBs as x -- 1.8.3.1
[PATCH v6 08/15] eal: typedef cpu flag enum as int
Forward declaration of a enum is a non-standard extension and is not
supported by MSVC. Use an int instead.
Abstract the use of the int/enum rte_cpu_flag_t in function parameter
lists by re-typdefing the enum rte_cpu_flag_t to the rte_cpu_flag_t
identifier.
Remove the use of __extension__ on function prototypes where
rte_cpu_flag_t appeared in parameter lists, it is sufficient to have the
conditionally compiled __extension__ at the non-standard forward
declaration site.
Signed-off-by: Tyler Retzlaff
---
lib/eal/include/generic/rte_cpuflags.h | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/eal/include/generic/rte_cpuflags.h
b/lib/eal/include/generic/rte_cpuflags.h
index d35551e..87ab03c 100644
--- a/lib/eal/include/generic/rte_cpuflags.h
+++ b/lib/eal/include/generic/rte_cpuflags.h
@@ -44,8 +44,12 @@ struct rte_cpu_intrinsics {
/**
* Enumeration of all CPU features supported
*/
+#ifndef RTE_TOOLCHAIN_MSVC
__extension__
-enum rte_cpu_flag_t;
+typedef enum rte_cpu_flag_t rte_cpu_flag_t;
+#else
+typedef int rte_cpu_flag_t;
+#endif
/**
* Get name of CPU flag
@@ -56,9 +60,8 @@ struct rte_cpu_intrinsics {
* flag name
* NULL if flag ID is invalid
*/
-__extension__
const char *
-rte_cpu_get_flag_name(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_name(rte_cpu_flag_t feature);
/**
* Function for checking a CPU flag availability
@@ -70,9 +73,8 @@ struct rte_cpu_intrinsics {
* 0 if flag is not available
* -ENOENT if flag is invalid
*/
-__extension__
int
-rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
+rte_cpu_get_flag_enabled(rte_cpu_flag_t feature);
/**
* This function checks that the currently used CPU supports the CPU features
--
1.8.3.1
[PATCH v6 12/15] eal: exclude exposure of rte atomic APIs for MSVC builds
It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.
Signed-off-by: Tyler Retzlaff
---
lib/eal/include/generic/rte_atomic.h | 7 +++
lib/eal/x86/include/rte_atomic.h | 4
2 files changed, 11 insertions(+)
diff --git a/lib/eal/include/generic/rte_atomic.h
b/lib/eal/include/generic/rte_atomic.h
index e973184..1964697 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -131,6 +131,8 @@
/*- 16 bit atomic operations
-*/
+#ifndef RTE_TOOLCHAIN_MSVC
+
/**
* Atomic compare and set.
*
@@ -1038,8 +1040,11 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
}
#endif
+#endif
+
/* 128 bit atomic operations
-*/
+
/**
* 128-bit integer structure.
*/
@@ -1049,8 +1054,10 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
union {
uint64_t val[2];
#ifdef RTE_ARCH_64
+#ifndef RTE_TOOLCHAIN_MSVC
__extension__ __int128 int128;
#endif
+#endif
};
} __rte_aligned(16) rte_int128_t;
diff --git a/lib/eal/x86/include/rte_atomic.h b/lib/eal/x86/include/rte_atomic.h
index 569d3ab..adf3309 100644
--- a/lib/eal/x86/include/rte_atomic.h
+++ b/lib/eal/x86/include/rte_atomic.h
@@ -83,6 +83,8 @@
#define rte_io_rmb() rte_compiler_barrier()
+#ifndef RTE_TOOLCHAIN_MSVC
+
/**
* Synchronization fence between threads based on the specified memory order.
*
@@ -279,6 +281,8 @@ static inline int rte_atomic32_dec_and_test(rte_atomic32_t
*v)
#include "rte_atomic_64.h"
#endif
+#endif
+
#ifdef __cplusplus
}
#endif
--
1.8.3.1
[PATCH v6 13/15] telemetry: avoid expanding versioned symbol macros on MSVC
Windows does not support versioned symbols. Fortunately Windows also
doesn't have an exported stable ABI.
Export rte_tel_data_add_array_int -> rte_tel_data_add_array_int_24
and rte_tel_data_add_dict_int -> rte_tel_data_add_dict_int_v24
functions.
Windows does have a way to achieve similar versioning for symbols but it
is not a simple #define so it will be done as a work package later.
Signed-off-by: Tyler Retzlaff
Acked-by: Bruce Richardson
---
lib/telemetry/telemetry_data.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 2bac2de..284c16e 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -82,8 +82,16 @@
/* mark the v23 function as the older version, and v24 as the default version
*/
VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
int64_t x), rte_tel_data_add_array_int_v24);
+#else
+int
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+#endif
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
@@ -220,8 +228,16 @@
/* mark the v23 function as the older version, and v24 as the default version
*/
VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+#ifndef RTE_TOOLCHAIN_MSVC
MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+#else
+int
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t
val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+#endif
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
--
1.8.3.1
[PATCH v6 10/15] eal: hide typedefs based on GCC vector extensions
When compiling with MSVC don't expose typedefs based on GCC vector extensions. Signed-off-by: Tyler Retzlaff --- lib/eal/include/generic/rte_vect.h | 4 1 file changed, 4 insertions(+) diff --git a/lib/eal/include/generic/rte_vect.h b/lib/eal/include/generic/rte_vect.h index 3fec2bf..777510c 100644 --- a/lib/eal/include/generic/rte_vect.h +++ b/lib/eal/include/generic/rte_vect.h @@ -17,6 +17,8 @@ #include +#ifndef RTE_TOOLCHAIN_MSVC + /* Unsigned vector types */ /** @@ -186,6 +188,8 @@ */ typedef int64_t rte_v256s64_t __attribute__((vector_size(32), aligned(32))); +#endif + /** * The max SIMD bitwidth value to limit vector path selection. */ -- 1.8.3.1
[PATCH v6 15/15] eal: do not define typeof macro when building with MSVC
When building with MSVC do not assume typeof is a macro and don't define a typeof macro that conflicts with C23 typeof keyword. Signed-off-by: Tyler Retzlaff --- lib/eal/include/rte_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h index 5417f68..fffb0fa 100644 --- a/lib/eal/include/rte_common.h +++ b/lib/eal/include/rte_common.h @@ -24,9 +24,11 @@ /* OS specific include */ #include +#ifndef RTE_TOOLCHAIN_MSVC #ifndef typeof #define typeof __typeof__ #endif +#endif #ifndef __cplusplus #ifndef asm -- 1.8.3.1
[PATCH v6 14/15] eal: always define MSVC as little endian
The MSVC compiler does not target big endian platforms so define little endian always. Signed-off-by: Tyler Retzlaff --- lib/eal/include/generic/rte_byteorder.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/eal/include/generic/rte_byteorder.h b/lib/eal/include/generic/rte_byteorder.h index 1e32a1b..375f118 100644 --- a/lib/eal/include/generic/rte_byteorder.h +++ b/lib/eal/include/generic/rte_byteorder.h @@ -45,6 +45,8 @@ #define RTE_BYTE_ORDER RTE_BIG_ENDIAN #elif defined __LITTLE_ENDIAN__ #define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN +#elif defined RTE_TOOLCHAIN_MSVC +#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN #endif #if !defined(RTE_BYTE_ORDER) #error Unknown endianness. -- 1.8.3.1
[PATCH v6 11/15] eal: expand most macros to empty when using MSVC
For now expand a lot of common rte macros empty. The catch here is we need to test that most of the macros do what they should but at the same time they are blocking work needed to bootstrap of the unit tests. Later we will return and provide (where possible) expansions that work correctly for msvc and where not possible provide some alternate macros to achieve the same outcome. Signed-off-by: Tyler Retzlaff --- lib/eal/include/rte_branch_prediction.h | 8 + lib/eal/include/rte_common.h| 54 + lib/eal/include/rte_compat.h| 20 3 files changed, 82 insertions(+) diff --git a/lib/eal/include/rte_branch_prediction.h b/lib/eal/include/rte_branch_prediction.h index 0256a9d..1eff9f6 100644 --- a/lib/eal/include/rte_branch_prediction.h +++ b/lib/eal/include/rte_branch_prediction.h @@ -25,7 +25,11 @@ * */ #ifndef likely +#ifndef RTE_TOOLCHAIN_MSVC #define likely(x) __builtin_expect(!!(x), 1) +#else +#define likely(x) (!!(x)) +#endif #endif /* likely */ /** @@ -39,7 +43,11 @@ * */ #ifndef unlikely +#ifndef RTE_TOOLCHAIN_MSVC #define unlikely(x)__builtin_expect(!!(x), 0) +#else +#define unlikely(x)(!!(x)) +#endif #endif /* unlikely */ #ifdef __cplusplus diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h index 2f464e3..5417f68 100644 --- a/lib/eal/include/rte_common.h +++ b/lib/eal/include/rte_common.h @@ -62,10 +62,18 @@ __GNUC_PATCHLEVEL__) #endif +#ifdef RTE_TOOLCHAIN_MSVC +#define __extension__ +#endif + /** * Force alignment */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_aligned(a) __attribute__((__aligned__(a))) +#else +#define __rte_aligned(a) +#endif #ifdef RTE_ARCH_STRICT_ALIGN typedef uint64_t unaligned_uint64_t __rte_aligned(1); @@ -80,16 +88,29 @@ /** * Force a structure to be packed */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_packed __attribute__((__packed__)) +#else +#define __rte_packed +#endif /** * Macro to mark a type that is not subject to type-based aliasing rules */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_may_alias __attribute__((__may_alias__)) +#else +#define __rte_may_alias +#endif /*** Macro to mark functions and fields scheduled for removal */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_deprecated __attribute__((__deprecated__)) #define __rte_deprecated_msg(msg) __attribute__((__deprecated__(msg))) +#else +#define __rte_deprecated +#define __rte_deprecated_msg(msg) +#endif /** * Macro to mark macros and defines scheduled for removal @@ -110,14 +131,22 @@ /** * Force symbol to be generated even if it appears to be unused. */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_used __attribute__((used)) +#else +#define __rte_used +#endif /*** Macros to eliminate unused variable warnings / /** * short definition to mark a function parameter unused */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_unused __attribute__((__unused__)) +#else +#define __rte_unused +#endif /** * Mark pointer as restricted with regard to pointer aliasing. @@ -141,6 +170,7 @@ * even if the underlying stdio implementation is ANSI-compliant, * so this must be overridden. */ +#ifndef RTE_TOOLCHAIN_MSVC #if RTE_CC_IS_GNU #define __rte_format_printf(format_index, first_arg) \ __attribute__((format(gnu_printf, format_index, first_arg))) @@ -148,6 +178,9 @@ #define __rte_format_printf(format_index, first_arg) \ __attribute__((format(printf, format_index, first_arg))) #endif +#else +#define __rte_format_printf(format_index, first_arg) +#endif /** * Tells compiler that the function returns a value that points to @@ -222,7 +255,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) /** * Hint never returning function */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_noreturn __attribute__((noreturn)) +#else +#define __rte_noreturn +#endif /** * Issue a warning in case the function's return value is ignored. @@ -247,12 +284,20 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) * } * @endcode */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_warn_unused_result __attribute__((warn_unused_result)) +#else +#define __rte_warn_unused_result +#endif /** * Force a function to be inlined */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_always_inline inline __attribute__((always_inline)) +#else +#define __rte_always_inline +#endif /** * Force a function to be noinlined @@ -437,7 +482,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) #define RTE_CACHE_LINE_MIN_SIZE 64 /** Force alignment to cache line. */ +#ifndef RTE_TOOLCHAIN_MSVC #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE) +#else +#define __rte_cache_aligned +#endif /** Force minimum cache line alignment. */ #define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_LINE_MIN_SIZE) @@ -812,12 +861,17 @@ sta
Re: [PATCH v2 00/44] fix segment fault when parse args
Hi Thomas, Ferruh, This patch-set get almost 30% ack by PMD's maintainer. Could it be applied? and squeeze the patch-set is okay. Another thread talk about a change in kvargs API, we could discuss here. My opinion: 1) the below PMD has the bug, but there are also many PMD take care of only key situation. I think it mainly because the API definition is not detailed, but this hole was already fill by commit: 52ab17efdec. 2) the rte_kvargs_get API, I think we could refine it definition, because it can't identify invalid keys and only-keys (both of them return NULL), and I suggest add one extra parameter: const char *rte_kvargs_get(const struct rte_kvargs *kvlist, const char *key, bool *key_exist); Thanks. On 2023/3/20 17:20, Chengwen Feng wrote: > The rte_kvargs_process() was used to parse KV pairs, it also supports > to parse 'only keys' (e.g. socket_id) type. And the callback function > parameter 'value' is NULL when parsed 'only keys'. > > It may leads to segment fault when parse args with 'only key', this > patchset fixes rest of them. > > Chengwen Feng (44): > app/pdump: fix segment fault when parse args > ethdev: fix segment fault when parse args > net/memif: fix segment fault when parse devargs > net/pcap: fix segment fault when parse devargs > net/ring: fix segment fault when parse devargs > net/sfc: fix segment fault when parse devargs > net/af_xdp: fix segment fault when parse devargs > net/ark: fix segment fault when parse devargs > net/cnxk: fix segment fault when parse devargs > net/cxgbe: fix segment fault when parse devargs > net/dpaa2: fix segment fault when parse devargs > net/ena: fix segment fault when parse devargs > net/enic: fix segment fault when parse devargs > net/fm10k: fix segment fault when parse devargs > net/i40e: fix segment fault when parse devargs > net/iavf: fix segment fault when parse devargs > net/ice: fix segment fault when parse devargs > net/idpf: fix segment fault when parse devargs > net/ionic: fix segment fault when parse devargs > net/mana: fix segment fault when parse devargs > net/mlx4: fix segment fault when parse devargs > net/mvneta: fix segment fault when parse devargs > net/mvpp2: fix segment fault when parse devargs > net/netvsc: fix segment fault when parse devargs > net/octeontx: fix segment fault when parse devargs > net/pfe: fix segment fault when parse devargs > net/qede: fix segment fault when parse devargs > baseband/la12xx: fix segment fault when parse devargs > bus/pci: fix segment fault when parse args > common/mlx5: fix segment fault when parse devargs > crypto/cnxk: fix segment fault when parse devargs > crypto/dpaa_sec: fix segment fault when parse devargs > crypto/dpaa2_sec: fix segment fault when parse devargs > crypto/mvsam: fix segment fault when parse devargs > crypto/scheduler: fix segment fault when parse devargs > dma/dpaa2: fix segment fault when parse devargs > event/cnxk: fix segment fault when parse devargs > event/dlb2: fix segment fault when parse devargs > event/dpaa: fix segment fault when parse devargs > event/octeontx: fix segment fault when parse devargs > event/opdl: fix segment fault when parse devargs > event/sw: fix segment fault when parse devargs > mempool/cnxk: fix segment fault when parse devargs > raw/cnxk_gpio: fix segment fault when parse devargs > > --- > v2: according Ferruh's comments: > fix all 'rte_kvargs_process()' bug instances. > only judge value validation. > > app/pdump/main.c | 12 ++ > drivers/baseband/la12xx/bbdev_la12xx.c | 3 ++ > drivers/bus/pci/pci_params.c | 2 + > drivers/common/mlx5/mlx5_common.c| 5 +++ > drivers/crypto/cnxk/cnxk_cryptodev_devargs.c | 3 ++ > drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 2 + > drivers/crypto/dpaa_sec/dpaa_sec.c | 3 ++ > drivers/crypto/mvsam/rte_mrvl_pmd.c | 6 +++ > drivers/crypto/scheduler/scheduler_pmd.c | 21 +++ > drivers/dma/dpaa2/dpaa2_qdma.c | 3 ++ > drivers/event/cnxk/cnxk_eventdev.c | 6 +++ > drivers/event/cnxk/cnxk_eventdev.h | 6 +++ > drivers/event/cnxk/cnxk_tim_evdev.c | 6 +++ > drivers/event/dlb2/dlb2.c| 5 ++- > drivers/event/dpaa/dpaa_eventdev.c | 3 ++ > drivers/event/octeontx/ssovf_evdev.c | 2 + > drivers/event/opdl/opdl_evdev.c | 9 + > drivers/event/sw/sw_evdev.c | 12 ++ > drivers/mempool/cnxk/cnxk_mempool.c | 3 ++ > drivers/net/af_xdp/rte_eth_af_xdp.c | 12 ++ > drivers/net/ark/ark_ethdev.c | 3 ++ > drivers/net/cnxk/cnxk_ethdev_devargs.c | 39 > drivers/net/cnxk/cnxk_ethdev_sec.c | 12 ++ > drivers/net/cxgbe/cxgbe_main.c | 3 ++ > drivers/net/dpaa2/dpaa2_ethde
RE: [PATCH v6 00/15] msvc integration changes
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > Sent: Saturday, 15 April 2023 03.16 > > In accordance with draft plan > http://mails.dpdk.org/archives/web/2023-February/002023.html > introduces conditionally compiled code to enable building with MSVC that > _does not_ require C99/C11 meaning it can be integrated now. > > This series covers minimal changes for item #2 in draft plan for EAL > dependencies kvargs, telemetry and consumed EAL public headers. > > Note if any patch in the series requires in-depth discussion I'll > detach it from this series for separate submission & more focused > discussion so it doesn't block the entire series. > > Note other "common" intrinsics were investigated for viability but > were not adopted either because they were not available on older > versions of gcc or because they generate different code for msvc > vs gcc. Series-acked-by: Morten Brørup
