RE: [PATCH] doc: add outer UDP checksum limitations for mlx5
Hi, > -Original Message- > From: Dariusz Sosnowski > Sent: Monday, July 10, 2023 11:49 AM > To: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; Suanming Mou > > Cc: dev@dpdk.org > Subject: [PATCH] doc: add outer UDP checksum limitations for mlx5 > > Currently available NVIDIA NICs and DPUs do not have a capability to calculate > the UDP checksum in the header added using encapsulation flow actions. > > This limitation was not documented in mlx5 PMD docs. > This patch adds this limitation to the docs and describes application > requirements. > > Signed-off-by: Dariusz Sosnowski > Acked-by: Ori Kam Patch applied to next-net-mlx, Kindest regards, Raslan Darawsheh
Re: [PATCH v3 0/2] Improve docs on getting info on running process
On Tue, Jul 18, 2023 at 10:40:20AM -0700, Stephen Hemminger wrote: > On Tue, 18 Jul 2023 17:48:00 +0100 > Bruce Richardson wrote: > > > Add details to our documentation on how to register logging for a > > component. Also provide guidelines on when to use logs vs tracing > > vs telemetry. > > > > V3: Moved new doc section on runtime info, and other minor changes flagged > > by David on review. > > > > V2: extended second patch based on the feedback provided. > > Hopefully, we can keep this section short and clear as the > > revisions roll! :-) > > > > Bruce Richardson (2): > > doc/contributing: provide coding details for dynamic logging > > doc/contributing: guidelines for logging, tracing and telemetry > > > > doc/guides/contributing/coding_style.rst | 18 + > > doc/guides/contributing/design.rst | 49 > > doc/guides/prog_guide/telemetry_lib.rst | 2 + > > doc/guides/prog_guide/trace_lib.rst | 2 + > > lib/cfgfile/rte_cfgfile.c| 2 + > > 5 files changed, 73 insertions(+) > > > > -- > > 2.39.2 > > > > Should we add explicit statements about: > - Static logtypes (especially LOGTYPE_PMD) should not be used. > - New static logtypes must not be added. I would hope that should not be necessary especially since this section talks about dynamic logging only. However, no harm in adding a one-line note about it. I'll see if I can get a few minutes to spin a V4 with an extra note, but if not I think this set is good to go as-is. /Bruce
[PATCH] net/mlx5: fix the template API requirements
The minimal SW and HW versions are added.
Fixes: 22681deead3e ("net/mlx5/hws: enable hardware steering")
Cc: va...@nvidia.com
Cc: sta...@dpdk.org
Signed-off-by: Bing Zhao
---
doc/guides/nics/mlx5.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 1052591d88..958193a608 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1621,6 +1621,14 @@ shortened below as "OFED".
| | | ConnectX-5| | ConnectX-5|
+---+-+-+
+.. table:: Minimal SW/HW versions for rte_flow template API
+
+ +-+++
+ | DPDK| NIC| Firmware |
+ +=+++
+ | 22.11 | ConnectX-6 Dx | xx.35.1012 |
+ +-+++
+
Notes for metadata
--
--
2.34.1
Re: [PATCH] tap: fix build of tap_bpf_program
On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> The tap_bpf_program.c is not built as part of normal DPDK
> EAL environment. It is intended to be built standalone
> and does not use rte_common.h.
>
> This reverts the related change from
> commit ef5baf3486e0 ("replace packed attributes")
>
> Note: this patch will cause expected warnings from checkpatch
> because the code involved is not used directly in DPDK environment.
>
> Signed-off-by: Stephen Hemminger
>
Agree, this seems done by mistake as part of batch update,
Acked-by: Ferruh Yigit
But I can't update the bpf file at all, if I am not missing something I
am not sure if we should get just this update or have a patch/patchset
that fixes the build.
@Ophir, how the bpf file is compiled? And did you test it recently?
I am using command from the documentation:
`clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
-filetype=obj -o tap_bpf_program.o`
@Aaron, should we add a simple build test around it, since this file is
not build by default with DPDK build?
> ---
> drivers/net/tap/tap_bpf_program.c | 4 ++--
> drivers/net/tap/tap_rss.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/tap/tap_bpf_program.c
> b/drivers/net/tap/tap_bpf_program.c
> index 20c310e5e7ba..532e8838fe27 100644
> --- a/drivers/net/tap/tap_bpf_program.c
> +++ b/drivers/net/tap/tap_bpf_program.c
> @@ -75,14 +75,14 @@ struct ipv4_l3_l4_tuple {
> __u32dst_addr;
> __u16dport;
> __u16sport;
> -} __rte_packed;
> +} __attribute__((packed));
>
> struct ipv6_l3_l4_tuple {
> __u8src_addr[16];
> __u8dst_addr[16];
> __u16 dport;
> __u16 sport;
> -} __rte_packed;
> +} __attribute__((packed));
>
> static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
> 0xd1, 0x81, 0xc6, 0x2c,
> diff --git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
> index 48c151cf6b68..dff46a012f94 100644
> --- a/drivers/net/tap/tap_rss.h
> +++ b/drivers/net/tap/tap_rss.h
> @@ -35,6 +35,6 @@ struct rss_key {
> __u32 key_size;
> __u32 queues[TAP_MAX_QUEUES];
> __u32 nb_queues;
> -} __rte_packed;
> +} __attribute__((packed));
>
> #endif /* _TAP_RSS_H_ */
Re: [PATCH] tap: fix build of tap_bpf_program
On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
>> The tap_bpf_program.c is not built as part of normal DPDK
>> EAL environment. It is intended to be built standalone
>> and does not use rte_common.h.
>>
>> This reverts the related change from
>> commit ef5baf3486e0 ("replace packed attributes")
>>
>> Note: this patch will cause expected warnings from checkpatch
>> because the code involved is not used directly in DPDK environment.
>>
>> Signed-off-by: Stephen Hemminger
>>
>
> Agree, this seems done by mistake as part of batch update,
>
> Acked-by: Ferruh Yigit
>
>
> But I can't update the bpf file at all, if I am not missing something I
* I can't *compile* the bpf file ...
> am not sure if we should get just this update or have a patch/patchset
> that fixes the build.
>
> @Ophir, how the bpf file is compiled? And did you test it recently?
>
> I am using command from the documentation:
> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> -filetype=obj -o tap_bpf_program.o`
>
>
>
> @Aaron, should we add a simple build test around it, since this file is
> not build by default with DPDK build?
>
>
>> ---
>> drivers/net/tap/tap_bpf_program.c | 4 ++--
>> drivers/net/tap/tap_rss.h | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/tap/tap_bpf_program.c
>> b/drivers/net/tap/tap_bpf_program.c
>> index 20c310e5e7ba..532e8838fe27 100644
>> --- a/drivers/net/tap/tap_bpf_program.c
>> +++ b/drivers/net/tap/tap_bpf_program.c
>> @@ -75,14 +75,14 @@ struct ipv4_l3_l4_tuple {
>> __u32dst_addr;
>> __u16dport;
>> __u16sport;
>> -} __rte_packed;
>> +} __attribute__((packed));
>>
>> struct ipv6_l3_l4_tuple {
>> __u8src_addr[16];
>> __u8dst_addr[16];
>> __u16 dport;
>> __u16 sport;
>> -} __rte_packed;
>> +} __attribute__((packed));
>>
>> static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
>> 0xd1, 0x81, 0xc6, 0x2c,
>> diff --git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
>> index 48c151cf6b68..dff46a012f94 100644
>> --- a/drivers/net/tap/tap_rss.h
>> +++ b/drivers/net/tap/tap_rss.h
>> @@ -35,6 +35,6 @@ struct rss_key {
>> __u32 key_size;
>> __u32 queues[TAP_MAX_QUEUES];
>> __u32 nb_queues;
>> -} __rte_packed;
>> +} __attribute__((packed));
>>
>> #endif /* _TAP_RSS_H_ */
>
Re: [PATCH] tap: fix build of tap_bpf_program
On 7/19/2023 11:03 AM, Ferruh Yigit wrote:
> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
>> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
>>> The tap_bpf_program.c is not built as part of normal DPDK
>>> EAL environment. It is intended to be built standalone
>>> and does not use rte_common.h.
>>>
>>> This reverts the related change from
>>> commit ef5baf3486e0 ("replace packed attributes")
>>>
>>> Note: this patch will cause expected warnings from checkpatch
>>> because the code involved is not used directly in DPDK environment.
>>>
>>> Signed-off-by: Stephen Hemminger
>>>
>>
>> Agree, this seems done by mistake as part of batch update,
>>
>> Acked-by: Ferruh Yigit
>>
>>
>> But I can't update the bpf file at all, if I am not missing something I
>
> * I can't *compile* the bpf file ...
>
>> am not sure if we should get just this update or have a patch/patchset
>> that fixes the build.
>>
>> @Ophir, how the bpf file is compiled? And did you test it recently?
>>
>> I am using command from the documentation:
>> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
>> -filetype=obj -o tap_bpf_program.o`
>>
>>
>>
>> @Aaron, should we add a simple build test around it, since this file is
>> not build by default with DPDK build?
>>
I saw Stephen already touched to the topic:
https://inbox.dpdk.org/dev/20230717083032.072b12c5@hermes.local/
>>
>>> ---
>>> drivers/net/tap/tap_bpf_program.c | 4 ++--
>>> drivers/net/tap/tap_rss.h | 2 +-
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/tap/tap_bpf_program.c
>>> b/drivers/net/tap/tap_bpf_program.c
>>> index 20c310e5e7ba..532e8838fe27 100644
>>> --- a/drivers/net/tap/tap_bpf_program.c
>>> +++ b/drivers/net/tap/tap_bpf_program.c
>>> @@ -75,14 +75,14 @@ struct ipv4_l3_l4_tuple {
>>> __u32dst_addr;
>>> __u16dport;
>>> __u16sport;
>>> -} __rte_packed;
>>> +} __attribute__((packed));
>>>
>>> struct ipv6_l3_l4_tuple {
>>> __u8src_addr[16];
>>> __u8dst_addr[16];
>>> __u16 dport;
>>> __u16 sport;
>>> -} __rte_packed;
>>> +} __attribute__((packed));
>>>
>>> static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
>>> 0xd1, 0x81, 0xc6, 0x2c,
>>> diff --git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
>>> index 48c151cf6b68..dff46a012f94 100644
>>> --- a/drivers/net/tap/tap_rss.h
>>> +++ b/drivers/net/tap/tap_rss.h
>>> @@ -35,6 +35,6 @@ struct rss_key {
>>> __u32 key_size;
>>> __u32 queues[TAP_MAX_QUEUES];
>>> __u32 nb_queues;
>>> -} __rte_packed;
>>> +} __attribute__((packed));
>>>
>>> #endif /* _TAP_RSS_H_ */
>>
>
Re: [PATCH v16 6/6] test/memarea: support dump API test
On 7/10/2023 7:49 AM, Chengwen Feng wrote:
This patch supports rte_memarea_dump() API test.
Signed-off-by: Chengwen Feng
Reviewed-by: Dongdong Liu
Acked-by: Morten Brørup
---
app/test/test_memarea.c | 40
1 file changed, 40 insertions(+)
diff --git a/app/test/test_memarea.c b/app/test/test_memarea.c
index 4053cdcac9..6511a86699 100644
--- a/app/test/test_memarea.c
+++ b/app/test/test_memarea.c
@@ -320,6 +320,45 @@ test_memarea_alloc_free(void)
TEST_ASSERT(rte_errno == 0, "Expected Zero");
+ fprintf(stderr, "There should have no allocated object.\n");
+ rte_memarea_dump(ma, stderr, true);
+
+ rte_memarea_destroy(ma);
+
+ return 0;
+}
+
+static int
+test_memarea_dump(void)
+{
+ struct rte_memarea_param init;
+ struct rte_memarea *ma;
+ int ret;
+
+ test_memarea_init_param(&init);
+ init.source = RTE_MEMAREA_SOURCE_LIBC;
+ init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+ ma = rte_memarea_create(&init);
+ TEST_ASSERT(ma != NULL, "Expected Non-NULL");
Here and in other places: I feel it's better to say *why* we expect
non-NULL, or make the error message otherwise more meaningful, such as
"Memarea creation failed".
+
+ /* test for invalid parameters */
+ ret = rte_memarea_dump(NULL, stderr, false);
+ TEST_ASSERT(ret == -1, "Expected -1");
+ TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+ ret = rte_memarea_dump(ma, NULL, false);
+ TEST_ASSERT(ret == -1, "Expected -1");
+ TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+ /* test for dump */
+ (void)rte_memarea_alloc(ma, 1);
+ (void)rte_memarea_alloc(ma, 1);
+ (void)rte_memarea_alloc(ma, 1);
+ (void)rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
+ (void)rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
+ fprintf(stderr, "There should have three allocated object.\n");
I question the value of this printout.
+ ret = rte_memarea_dump(ma, stderr, true);
+ TEST_ASSERT(ret == 0, "Expected ZERO");
+
rte_memarea_destroy(ma);
return 0;
@@ -337,6 +376,7 @@ static struct unit_test_suite memarea_test_suite = {
TEST_CASE(test_memarea_alloc_fail),
TEST_CASE(test_memarea_free_fail),
TEST_CASE(test_memarea_alloc_free),
+ TEST_CASE(test_memarea_dump),
TEST_CASES_END() /**< NULL terminate unit test array */
}
--
Thanks,
Anatoly
[PATCH 1/1] node: remove MAX macro from all nodes
Removed MAX macro from all graph nodes to extend
edges to nodes without ABI breakage
Signed-off-by: Rakesh Kudurumalla
---
Depends-on: series-28807 ("add UDP v4 support")
lib/node/ip4_lookup.c | 2 +-
lib/node/ip6_lookup.c | 2 +-
lib/node/rte_node_ip4_api.h | 2 --
lib/node/rte_node_ip6_api.h | 2 --
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/lib/node/ip4_lookup.c b/lib/node/ip4_lookup.c
index d3fc48baf7..21a135a674 100644
--- a/lib/node/ip4_lookup.c
+++ b/lib/node/ip4_lookup.c
@@ -225,7 +225,7 @@ static struct rte_node_register ip4_lookup_node = {
.init = ip4_lookup_node_init,
- .nb_edges = RTE_NODE_IP4_LOOKUP_NEXT_MAX,
+ .nb_edges = RTE_NODE_IP4_LOOKUP_NEXT_IP4_LOCAL + 1,
.next_nodes = {
[RTE_NODE_IP4_LOOKUP_NEXT_IP4_LOCAL] = "ip4_local",
[RTE_NODE_IP4_LOOKUP_NEXT_REWRITE] = "ip4_rewrite",
diff --git a/lib/node/ip6_lookup.c b/lib/node/ip6_lookup.c
index 646e466551..6f56eb5ec5 100644
--- a/lib/node/ip6_lookup.c
+++ b/lib/node/ip6_lookup.c
@@ -362,7 +362,7 @@ static struct rte_node_register ip6_lookup_node = {
.init = ip6_lookup_node_init,
- .nb_edges = RTE_NODE_IP6_LOOKUP_NEXT_MAX,
+ .nb_edges = RTE_NODE_IP6_LOOKUP_NEXT_PKT_DROP + 1,
.next_nodes = {
[RTE_NODE_IP6_LOOKUP_NEXT_REWRITE] = "ip6_rewrite",
[RTE_NODE_IP6_LOOKUP_NEXT_PKT_DROP] = "pkt_drop",
diff --git a/lib/node/rte_node_ip4_api.h b/lib/node/rte_node_ip4_api.h
index 405bdd3283..f9e38a4b14 100644
--- a/lib/node/rte_node_ip4_api.h
+++ b/lib/node/rte_node_ip4_api.h
@@ -32,8 +32,6 @@ enum rte_node_ip4_lookup_next {
/**< Packet drop node. */
RTE_NODE_IP4_LOOKUP_NEXT_IP4_LOCAL,
/** IP Local node. */
- RTE_NODE_IP4_LOOKUP_NEXT_MAX,
- /**< Number of next nodes of lookup node. */
};
/**
diff --git a/lib/node/rte_node_ip6_api.h b/lib/node/rte_node_ip6_api.h
index f3b5a1002a..a538dc2ea7 100644
--- a/lib/node/rte_node_ip6_api.h
+++ b/lib/node/rte_node_ip6_api.h
@@ -30,8 +30,6 @@ enum rte_node_ip6_lookup_next {
/**< Rewrite node. */
RTE_NODE_IP6_LOOKUP_NEXT_PKT_DROP,
/**< Packet drop node. */
- RTE_NODE_IP6_LOOKUP_NEXT_MAX,
- /**< Number of next nodes of lookup node. */
};
/**
--
2.25.1
Re: [PATCH v2 2/6] dts: add traffic generator config
On Tue, Jul 18, 2023 at 5:55 PM Jeremy Spewock wrote:
>
> Hey Juraj,
>
> These changes look good to me, I just had one question. Is the plan to make
> specifying a TG always required or optional for cases where it isn't
> required? It seems like it is written now as something that is required for
> every execution. I don't think this is necessarily a bad thing, I just wonder
> if it would be beneficial at all to make it optional to allow for executions
> that don't utilize a TG to just not specify it.
>
If there's a legitimate use case (or we can imagine one) for this in
CI (or anywhere else), then we'd want to make a TG node optional.
Let's leave the implementation as is and make the TG node optional
once we discuss it further in the CI call. We talked about a mechanism
to skip test cases based on the testbed capabilities and I think this
would fit into that (as TG could be viewed as a testbed capability).
> On Mon, Jul 17, 2023 at 7:07 AM Juraj Linkeš
> wrote:
>>
>> Node configuration - where to connect, what ports to use and what TG to
>> use.
>>
>> Signed-off-by: Juraj Linkeš
>> ---
>> dts/conf.yaml | 26 ++-
>> dts/framework/config/__init__.py | 87 +++---
>> dts/framework/config/conf_yaml_schema.json | 29 +++-
>> dts/framework/dts.py | 12 +--
>> dts/framework/testbed_model/node.py| 4 +-
>> dts/framework/testbed_model/sut_node.py| 6 +-
>> 6 files changed, 141 insertions(+), 23 deletions(-)
>>
>> diff --git a/dts/conf.yaml b/dts/conf.yaml
>> index 3a5d87cb49..7f089022ba 100644
>> --- a/dts/conf.yaml
>> +++ b/dts/conf.yaml
>> @@ -13,10 +13,11 @@ executions:
>> skip_smoke_tests: false # optional flag that allow you to skip smoke
>> tests
>> test_suites:
>>- hello_world
>> -system_under_test:
>> +system_under_test_node:
>>node_name: "SUT 1"
>>vdevs: # optional; if removed, vdevs won't be used in the execution
>> - "crypto_openssl"
>> +traffic_generator_node: "TG 1"
>> nodes:
>>- name: "SUT 1"
>> hostname: sut1.change.me.localhost
>> @@ -40,3 +41,26 @@ nodes:
>> os_driver: i40e
>> peer_node: "TG 1"
>> peer_pci: ":00:08.1"
>> + - name: "TG 1"
>> +hostname: tg1.change.me.localhost
>> +user: dtsuser
>> +arch: x86_64
>> +os: linux
>> +lcores: ""
>> +ports:
>> + - pci: ":00:08.0"
>> +os_driver_for_dpdk: rdma
>> +os_driver: rdma
>> +peer_node: "SUT 1"
>> +peer_pci: ":00:08.0"
>> + - pci: ":00:08.1"
>> +os_driver_for_dpdk: rdma
>> +os_driver: rdma
>> +peer_node: "SUT 1"
>> +peer_pci: ":00:08.1"
>> +use_first_core: false
>> +hugepages: # optional; if removed, will use system hugepage
>> configuration
>> +amount: 256
>> +force_first_numa: false
>> +traffic_generator:
>> +type: SCAPY
>> diff --git a/dts/framework/config/__init__.py
>> b/dts/framework/config/__init__.py
>> index fad56cc520..72aa021b97 100644
>> --- a/dts/framework/config/__init__.py
>> +++ b/dts/framework/config/__init__.py
>> @@ -13,7 +13,7 @@
>> from dataclasses import dataclass
>> from enum import Enum, auto, unique
>> from pathlib import PurePath
>> -from typing import Any, TypedDict
>> +from typing import Any, TypedDict, Union
>>
>> import warlock # type: ignore
>> import yaml
>> @@ -55,6 +55,11 @@ class Compiler(StrEnum):
>> msvc = auto()
>>
>>
>> +@unique
>> +class TrafficGeneratorType(StrEnum):
>> +SCAPY = auto()
>> +
>> +
>> # Slots enables some optimizations, by pre-allocating space for the defined
>> # attributes in the underlying data structure.
>> #
>> @@ -79,6 +84,29 @@ class PortConfig:
>> def from_dict(node: str, d: dict) -> "PortConfig":
>> return PortConfig(node=node, **d)
>>
>> +def __str__(self) -> str:
>> +return f"Port {self.pci} on node {self.node}"
>> +
>> +
>> +@dataclass(slots=True, frozen=True)
>> +class TrafficGeneratorConfig:
>> +traffic_generator_type: TrafficGeneratorType
>> +
>> +@staticmethod
>> +def from_dict(d: dict):
>> +# This looks useless now, but is designed to allow expansion to
>> traffic
>> +# generators that require more configuration later.
>> +match TrafficGeneratorType(d["type"]):
>> +case TrafficGeneratorType.SCAPY:
>> +return ScapyTrafficGeneratorConfig(
>> +traffic_generator_type=TrafficGeneratorType.SCAPY
>> +)
>> +
>> +
>> +@dataclass(slots=True, frozen=True)
>> +class ScapyTrafficGeneratorConfig(TrafficGeneratorConfig):
>> +pass
>> +
>>
>> @dataclass(slots=True, frozen=True)
>> class NodeConfiguration:
>> @@ -90,17 +118,17 @@ class NodeConfiguration:
>> os: OS
>> lcores: str
>> use_first_core: bool
>> -memory_channels: int
>> hugepages: HugepageConfiguration | None
>>
[PATCH] doc: add tested platforms with NVIDIA NICs
Add tested platforms with NVIDIA NICs to the 23.07 release notes. Signed-off-by: Raslan Darawsheh --- doc/guides/rel_notes/release_23_07.rst | 161 + 1 file changed, 161 insertions(+) diff --git a/doc/guides/rel_notes/release_23_07.rst b/doc/guides/rel_notes/release_23_07.rst index d4af85b3ff..41075d1460 100644 --- a/doc/guides/rel_notes/release_23_07.rst +++ b/doc/guides/rel_notes/release_23_07.rst @@ -326,3 +326,164 @@ Tested Platforms This section is a comment. Do not overwrite or remove it. Also, make sure to start the actual text at the margin. === + +* Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations + + * CPU: + +* Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz + + * OS: + +* Red Hat Enterprise Linux release 9.1 (Plow) +* Red Hat Enterprise Linux release 8.6 (Ootpa) +* Red Hat Enterprise Linux release 8.4 (Ootpa) +* Red Hat Enterprise Linux Server release 7.9 (Maipo) +* Red Hat Enterprise Linux Server release 7.6 (Maipo) +* Ubuntu 22.04 +* Ubuntu 20.04 +* SUSE Enterprise Linux 15 SP2 + + * OFED: + +* MLNX_OFED 23.04-1.1.3.0 and above + + * upstream kernel: + +* Linux 6.4.0 and above + + * rdma-core: + +* rdma-core-46.0 and above + + * NICs: + +* NVIDIA\ |reg| ConnectX\ |reg|-3 Pro 40G MCX354A-FCC_Ax (2x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1007 + * Firmware version: 2.42.5000 + +* NVIDIA\ |reg| ConnectX\ |reg|-3 Pro 40G MCX354A-FCCT (2x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1007 + * Firmware version: 2.42.5000 + +* NVIDIA\ |reg| ConnectX\ |reg|-4 Lx 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-4 Lx 50G MCX4131A-GCAT (1x50G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-5 100G MCX516A-CCAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-5 100G MCX556A-EDAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-5 Ex EN 100G MCX516A-CDAT (2x100G) + + * Host interface: PCI Express 4.0 x16 + * Device ID: 15b3:1019 + * Firmware version: 16.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G) + + * Host interface: PCI Express 4.0 x16 + * Device ID: 15b3:101d + * Firmware version: 22.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G) + + * Host interface: PCI Express 4.0 x8 + * Device ID: 15b3:101f + * Firmware version: 26.37.1014 and above + +* NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) + + * Host interface: PCI Express 5.0 x16 + * Device ID: 15b3:1021 + * Firmware version: 28.37.1014 and above + +* NVIDIA\ |reg| BlueField\ |reg| SmartNIC + + * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 (2x25G) + +* Host interface: PCI Express 3.0 x16 +* Device ID: 15b3:a2d6 +* Firmware version: 24.37.1300 and above + + * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB (2x200G) + +* Host interface: PCI Express 5.0 x16 +* Device ID: 15b3:a2dc +* Firmware version: 32.37.1306 and above + + * Embedded software: + +* Ubuntu 22.04 +* MLNX_OFED 23.04-0.5.3.0 and above +* DOCA_2.0.2 BSP_4.0.3_Ubuntu_22.04-8.23-04 +* DPDK application running on ARM cores + +* IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations + + * CPU: + +* POWER9 2.2 (pvr 004e 1202) + + * OS: + +* Ubuntu 20.04 + + * NICs: + +* NVIDIA\ |reg| ConnectX\ |reg|-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 4.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.37.1014 + +* NVIDIA\ |reg| ConnectX\ |reg|-
Re: [PATCH v2 2/6] dts: add traffic generator config
On Wed, Jul 19, 2023, 08:57 Juraj Linkeš wrote:
> On Tue, Jul 18, 2023 at 5:55 PM Jeremy Spewock
> wrote:
> >
> > Hey Juraj,
> >
> > These changes look good to me, I just had one question. Is the plan to
> make specifying a TG always required or optional for cases where it isn't
> required? It seems like it is written now as something that is required for
> every execution. I don't think this is necessarily a bad thing, I just
> wonder if it would be beneficial at all to make it optional to allow for
> executions that don't utilize a TG to just not specify it.
> >
>
> If there's a legitimate use case (or we can imagine one) for this in
> CI (or anywhere else), then we'd want to make a TG node optional.
> Let's leave the implementation as is and make the TG node optional
> once we discuss it further in the CI call. We talked about a mechanism
> to skip test cases based on the testbed capabilities and I think this
> would fit into that (as TG could be viewed as a testbed capability).
>
I like that idea of thinking of it as a testbed capability and skipping
based on that. I think that would work nicely to address this if there was
a use case for it. Thanks for the input!
> > On Mon, Jul 17, 2023 at 7:07 AM Juraj Linkeš
> wrote:
> >>
> >> Node configuration - where to connect, what ports to use and what TG to
> >> use.
> >>
> >> Signed-off-by: Juraj Linkeš
> >> ---
> >> dts/conf.yaml | 26 ++-
> >> dts/framework/config/__init__.py | 87 +++---
> >> dts/framework/config/conf_yaml_schema.json | 29 +++-
> >> dts/framework/dts.py | 12 +--
> >> dts/framework/testbed_model/node.py| 4 +-
> >> dts/framework/testbed_model/sut_node.py| 6 +-
> >> 6 files changed, 141 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/dts/conf.yaml b/dts/conf.yaml
> >> index 3a5d87cb49..7f089022ba 100644
> >> --- a/dts/conf.yaml
> >> +++ b/dts/conf.yaml
> >> @@ -13,10 +13,11 @@ executions:
> >> skip_smoke_tests: false # optional flag that allow you to skip
> smoke tests
> >> test_suites:
> >>- hello_world
> >> -system_under_test:
> >> +system_under_test_node:
> >>node_name: "SUT 1"
> >>vdevs: # optional; if removed, vdevs won't be used in the
> execution
> >> - "crypto_openssl"
> >> +traffic_generator_node: "TG 1"
> >> nodes:
> >>- name: "SUT 1"
> >> hostname: sut1.change.me.localhost
> >> @@ -40,3 +41,26 @@ nodes:
> >> os_driver: i40e
> >> peer_node: "TG 1"
> >> peer_pci: ":00:08.1"
> >> + - name: "TG 1"
> >> +hostname: tg1.change.me.localhost
> >> +user: dtsuser
> >> +arch: x86_64
> >> +os: linux
> >> +lcores: ""
> >> +ports:
> >> + - pci: ":00:08.0"
> >> +os_driver_for_dpdk: rdma
> >> +os_driver: rdma
> >> +peer_node: "SUT 1"
> >> +peer_pci: ":00:08.0"
> >> + - pci: ":00:08.1"
> >> +os_driver_for_dpdk: rdma
> >> +os_driver: rdma
> >> +peer_node: "SUT 1"
> >> +peer_pci: ":00:08.1"
> >> +use_first_core: false
> >> +hugepages: # optional; if removed, will use system hugepage
> configuration
> >> +amount: 256
> >> +force_first_numa: false
> >> +traffic_generator:
> >> +type: SCAPY
> >> diff --git a/dts/framework/config/__init__.py
> b/dts/framework/config/__init__.py
> >> index fad56cc520..72aa021b97 100644
> >> --- a/dts/framework/config/__init__.py
> >> +++ b/dts/framework/config/__init__.py
> >> @@ -13,7 +13,7 @@
> >> from dataclasses import dataclass
> >> from enum import Enum, auto, unique
> >> from pathlib import PurePath
> >> -from typing import Any, TypedDict
> >> +from typing import Any, TypedDict, Union
> >>
> >> import warlock # type: ignore
> >> import yaml
> >> @@ -55,6 +55,11 @@ class Compiler(StrEnum):
> >> msvc = auto()
> >>
> >>
> >> +@unique
> >> +class TrafficGeneratorType(StrEnum):
> >> +SCAPY = auto()
> >> +
> >> +
> >> # Slots enables some optimizations, by pre-allocating space for the
> defined
> >> # attributes in the underlying data structure.
> >> #
> >> @@ -79,6 +84,29 @@ class PortConfig:
> >> def from_dict(node: str, d: dict) -> "PortConfig":
> >> return PortConfig(node=node, **d)
> >>
> >> +def __str__(self) -> str:
> >> +return f"Port {self.pci} on node {self.node}"
> >> +
> >> +
> >> +@dataclass(slots=True, frozen=True)
> >> +class TrafficGeneratorConfig:
> >> +traffic_generator_type: TrafficGeneratorType
> >> +
> >> +@staticmethod
> >> +def from_dict(d: dict):
> >> +# This looks useless now, but is designed to allow expansion
> to traffic
> >> +# generators that require more configuration later.
> >> +match TrafficGeneratorType(d["type"]):
> >> +case TrafficGeneratorType.SCAPY:
> >> +return ScapyTrafficGeneratorConfig(
> >> +
Re: [PATCH v2 3/6] dts: traffic generator abstractions
On Tue, Jul 18, 2023 at 9:56 PM Jeremy Spewock wrote: > > > Hey Juraj, > > Just a couple of comments below, but very minor stuff. Just a few docstring > that I commented on and one question about the factory for traffic generators > that I was wondering what you thought about. More below: > >> diff --git a/dts/framework/testbed_model/capturing_traffic_generator.py >> b/dts/framework/testbed_model/capturing_traffic_generator.py >> new file mode 100644 >> index 00..1130d87f1e >> --- /dev/null >> +++ b/dts/framework/testbed_model/capturing_traffic_generator.py >> @@ -0,0 +1,135 @@ >> +# SPDX-License-Identifier: BSD-3-Clause >> +# Copyright(c) 2022 University of New Hampshire >> +# Copyright(c) 2023 PANTHEON.tech s.r.o. >> + >> +"""Traffic generator that can capture packets. >> + >> +In functional testing, we need to interrogate received packets to check >> their validity. >> +Here we define the interface common to all >> +traffic generators capable of capturing traffic. > > > Is there a reason for the line break here? Just to keep things consistent I > think it might make sense to extend this line to be the same length as the > one above. > The reason is the full line is above the character limit. I was using Thomas's heuristic of splitting the lines where it makes logical sense, but it does look kinda wonky, so I'll try to reformat it more sensibly. >> >> +""" >> + >> +import uuid >> +from abc import abstractmethod >> + >> +import scapy.utils # type: ignore[import] >> +from scapy.packet import Packet # type: ignore[import] >> + >> +from framework.settings import SETTINGS >> +from framework.utils import get_packet_summaries >> + >> +from .hw.port import Port >> +from .traffic_generator import TrafficGenerator >> + >> + >> +def _get_default_capture_name() -> str: >> +""" >> +This is the function used for the default implementation of capture >> names. >> +""" >> +return str(uuid.uuid4()) >> + >> + >> +class CapturingTrafficGenerator(TrafficGenerator): >> +""" >> +A mixin interface which enables a packet generator to declare that it >> can capture >> +packets and return them to the user. > > > This is missing the one line summary at the top of the comment. Obviously > this is not a big issue, but we likely would want this to be uniform with the > rest of the module which does have the summary at the top. > Good catch. I plan on reviewing all of the docstring when updating the format of the docstrings so this means less work in the future. :-) >> >> + >> +The methods of capturing traffic generators obey the following workflow: >> +1. send packets >> +2. capture packets >> +3. write the capture to a .pcap file >> +4. return the received packets >> +""" >> + >> +@property >> +def is_capturing(self) -> bool: >> +return True >> + >> +def send_packet_and_capture( >> +self, >> +packet: Packet, >> +send_port: Port, >> +receive_port: Port, >> +duration: float, >> +capture_name: str = _get_default_capture_name(), >> +) -> list[Packet]: >> +"""Send a packet, return received traffic. >> + >> +Send a packet on the send_port and then return all traffic captured >> +on the receive_port for the given duration. Also record the >> captured traffic >> +in a pcap file. >> + >> >> +Args: >> +packet: The packet to send. >> +send_port: The egress port on the TG node. >> +receive_port: The ingress port in the TG node. >> +duration: Capture traffic for this amount of time after sending >> the packet. >> +capture_name: The name of the .pcap file where to store the >> capture. >> + >> +Returns: >> + A list of received packets. May be empty if no packets are >> captured. >> +""" >> +return self.send_packets_and_capture( >> +[packet], send_port, receive_port, duration, capture_name >> +) >> + >> +def send_packets_and_capture( >> +self, >> +packets: list[Packet], >> +send_port: Port, >> +receive_port: Port, >> +duration: float, >> +capture_name: str = _get_default_capture_name(), >> +) -> list[Packet]: >> +"""Send packets, return received traffic. >> + >> +Send packets on the send_port and then return all traffic captured >> +on the receive_port for the given duration. Also record the >> captured traffic >> +in a pcap file. >> + >> +Args: >> +packets: The packets to send. >> +send_port: The egress port on the TG node. >> +receive_port: The ingress port in the TG node. >> +duration: Capture traffic for this amount of time after sending >> the packets. >> +capture_name: The name of the .pcap file where to store the >> capture. >> + >> +Returns: >> +
RE: [RFC] lib/ethdev: introduce table driven APIs
Hi folks, > -Original Message- > From: Ori Kam > Sent: Tuesday, June 20, 2023 12:11 PM > To: Jerin Jacob ; Zhang, Qi Z > > Cc: Dumitrescu, Cristian ; NBU-Contact- > Thomas Monjalon (EXTERNAL) ; > david.march...@redhat.com; Richardson, Bruce > ; jer...@marvell.com; ferruh.yi...@amd.com; > Mcnamara, John ; Zhang, Helin > ; techbo...@dpdk.org; dev@dpdk.org; Ivan Malov > > Subject: RE: [RFC] lib/ethdev: introduce table driven APIs > > > > > Yes. We need to change the backend compiler to understand the rte_flow > > mapping to p4 to avoid any translation cost. > +1 > I think the idea is that the complier will convert to rte_flow and supply some > mapping file so when application uses some name it will be translated to the > correct > preconfigured rte_flow action Sorry to join late to this thread. Let me try to clarify the role of the P4 compiler: 1. P4 compiler is for the data path only, while this proposal is for a control path API. 2. The P4 program simply defines the data path pipeline, i.e. the table topology that Ivan was mentioning. The P4 compiler takes this P4 program as input and translates it to a sort of firmware that the HW understands and loads to create that data path. 3. The P4 program defines the key and action formats for each table, but it does NOT contain the set of entries (key/action pairs) for each table; the actual table entries are populated post-init by the user using a control path API such as RTE_FLOW or other. So what Qi's proposal is about is a control path API to populate the tables, an API that is similar to the RTE_FLOW API, and not about a data path API to define a topology of tables (the table topology is either hardcoded at HW design time or configured in HW at init time by "firmware" produced by the P4 compiler out of a P4 program). Makes sense? Regards, Cristian
[Bug 1266] net/mlx5: cannot create rte_flow rule matching ethernet multicast with jump action on bond mode 4
https://bugs.dpdk.org/show_bug.cgi?id=1266 Bug ID: 1266 Summary: net/mlx5: cannot create rte_flow rule matching ethernet multicast with jump action on bond mode 4 Product: DPDK Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: voja...@cesnet.cz Target Milestone: --- [DPDK Version] commit 238f67ca9cc00be4248b14d9ca4412edb7da62f6 (HEAD -> main, origin/main, origin/HEAD) Author: Ajit Khaparde Date: Wed Jul 12 11:05:30 2023 -0700 doc: update firmware version in bnxt guide Update earliest supported firmware version for 22.11 release. Signed-off-by: Ajit Khaparde [OS version] Operating System: Oracle Linux Server 8.7 Kernel: Linux 4.18.0-348.12.2.el8_5.x86_64 Architecture: x86-64 [DPDK build] meson build ninja -C build [Network devices] :3b:00.0 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f0np0 drv=mlx5_core unused= :3b:00.1 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f1np1 drv=mlx5_core unused= [OFED version] MLNX_OFED_LINUX-5.7-1.0.2.0 (OFED-5.7-1.0.2) [Reproduce in testpmd] ``` sudo ./dpdk-testpmd -a :3b:00.0 -a :3b:00.1 -c 0x0f -n 4 --vdev 'net_bonding0,slave=:3b:00.0,slave=:3b:00.1,mode=4,agg_mode=count' -- -i --port-topology=chained EAL: Detected CPU lcores: 40 EAL: Detected NUMA nodes: 2 EAL: Detected shared linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: Probe PCI driver: mlx5_pci (15b3:101d) device: :3b:00.0 (socket 0) EAL: Probe PCI driver: mlx5_pci (15b3:101d) device: :3b:00.1 (socket 0) bond_ethdev_mode_set(1625) - Using mode 4, it is necessary to do TX burst and RX burst at least every 100ms. TELEMETRY: No legacy callbacks, legacy socket not created Interactive-mode selected testpmd: create a new mbuf pool : n=171456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc testpmd: create a new mbuf pool : n=171456, size=2176, socket=1 testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 (socket 0) Port 0: 04:3F:72:C7:B8:84 Configuring Port 1 (socket 0) Port 1: 04:3F:72:C7:B8:85 Configuring Port 2 (socket 0) Device with port_id=0 already stopped Port 2: link state change event Device with port_id=1 already stopped Port 2: 04:3F:72:C7:B8:84 Checking link statuses... Done testpmd> flow create 2 group 0 priority 0 ingress pattern eth dst spec 01:00:00:00:00:00 dst mask 01:00:00:00:00:00 / end actions jump group 1 / end bond_flow_create(104) - Failed to create flow on slave 0 port_flow_complain(): Caught PMD error type 1 (cause unspecified): hardware refuses to create flow: Invalid argument ``` [Notes] When using a different action, such as 'rss' or 'queue', the rule is created without any issues. When using a different ethernet mask, such as '0F:00:00:00:00:00', the rule is also created. When using a different mode of the bonding PMD, the rules is created. -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v3 0/2] Improve docs on getting info on running process
On Tue, Jul 18, 2023 at 10:40:20AM -0700, Stephen Hemminger wrote: > On Tue, 18 Jul 2023 17:48:00 +0100 > Bruce Richardson wrote: > > > Add details to our documentation on how to register logging for a > > component. Also provide guidelines on when to use logs vs tracing > > vs telemetry. > > > > V3: Moved new doc section on runtime info, and other minor changes flagged > > by David on review. > > > > V2: extended second patch based on the feedback provided. > > Hopefully, we can keep this section short and clear as the > > revisions roll! :-) > > > > Bruce Richardson (2): > > doc/contributing: provide coding details for dynamic logging > > doc/contributing: guidelines for logging, tracing and telemetry > > > > doc/guides/contributing/coding_style.rst | 18 + > > doc/guides/contributing/design.rst | 49 > > doc/guides/prog_guide/telemetry_lib.rst | 2 + > > doc/guides/prog_guide/trace_lib.rst | 2 + > > lib/cfgfile/rte_cfgfile.c| 2 + > > 5 files changed, 73 insertions(+) > > > > -- > > 2.39.2 > > > > Should we add explicit statements about: > - Static logtypes (especially LOGTYPE_PMD) should not be used. > - New static logtypes must not be added. How about: +.. note:: + + The statically-defined log types defined in ``rte_log.h`` are for legacy components, + and they will likely be removed in a future release. + Do not add new entries to this file. + Any suggested rewording before I spin a new patch? /Bruce
Re: [PATCH v10 1/1] dts: add smoke tests
Two more things and we're done.
On Tue, Jul 18, 2023 at 11:49 PM wrote:
>
> From: Jeremy Spewock
>
> Adds a new test suite for running smoke tests that verify general
> configuration aspects of the system under test. If any of these tests
> fail, the DTS execution terminates as part of a "fail-fast" model.
>
> Signed-off-by: Jeremy Spewock
> ---
> dts/conf.yaml | 17 +-
> dts/framework/config/__init__.py | 79 ++--
> dts/framework/config/conf_yaml_schema.json| 142 ++-
> dts/framework/dts.py | 84 ++---
> dts/framework/exception.py| 12 ++
> dts/framework/remote_session/__init__.py | 13 +-
> dts/framework/remote_session/linux_session.py | 3 +-
> dts/framework/remote_session/os_session.py| 49 -
> dts/framework/remote_session/posix_session.py | 29 ++-
> .../remote_session/remote/__init__.py | 10 ++
> .../remote/interactive_remote_session.py | 82 +
> .../remote/interactive_shell.py | 132 ++
> .../remote_session/remote/testpmd_shell.py| 49 +
> dts/framework/test_result.py | 21 ++-
> dts/framework/test_suite.py | 10 +-
> dts/framework/testbed_model/node.py | 43 -
> dts/framework/testbed_model/sut_node.py | 169 +-
> dts/framework/utils.py| 3 +
> dts/tests/TestSuite_smoke_tests.py| 114
> 19 files changed, 967 insertions(+), 94 deletions(-)
> create mode 100644
> dts/framework/remote_session/remote/interactive_remote_session.py
> create mode 100644 dts/framework/remote_session/remote/interactive_shell.py
> create mode 100644 dts/framework/remote_session/remote/testpmd_shell.py
> create mode 100644 dts/tests/TestSuite_smoke_tests.py
>
> diff --git
> a/dts/framework/remote_session/remote/interactive_remote_session.py
> b/dts/framework/remote_session/remote/interactive_remote_session.py
> new file mode 100644
> index 00..2d94daf2a7
> --- /dev/null
> +++ b/dts/framework/remote_session/remote/interactive_remote_session.py
We forgot to add proper docstring to this module.
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2023 University of New Hampshire
> +
> +import socket
> +import traceback
> +
> +from paramiko import AutoAddPolicy, SSHClient, Transport # type: ignore
> +from paramiko.ssh_exception import ( # type: ignore
> +AuthenticationException,
> +BadHostKeyException,
> +NoValidConnectionsError,
> +SSHException,
> +)
> +
> +from framework.config import NodeConfiguration
> +from framework.exception import SSHConnectionError
> +from framework.logger import DTSLOG
> +
> +
> +class InteractiveRemoteSession:
> +hostname: str
> +ip: str
> +port: int
> +username: str
> +password: str
> +_logger: DTSLOG
> +_node_config: NodeConfiguration
> +session: SSHClient
> +_transport: Transport | None
> +
> +def __init__(self, node_config: NodeConfiguration, _logger: DTSLOG) ->
> None:
> +self._node_config = node_config
> +self._logger = _logger
> +self.hostname = node_config.hostname
> +self.username = node_config.user
> +self.password = node_config.password if node_config.password else ""
> +port = "22"
> +self.ip = node_config.hostname
> +if ":" in node_config.hostname:
> +self.ip, port = node_config.hostname.split(":")
> +self.port = int(port)
> +self._logger.info(
> +f"Initializing interactive connection for
> {self.username}@{self.hostname}"
> +)
> +self._connect()
> +self._logger.info(
> +f"Interactive connection successful for
> {self.username}@{self.hostname}"
> +)
> +
> +def _connect(self) -> None:
> +client = SSHClient()
> +client.set_missing_host_key_policy(AutoAddPolicy)
> +self.session = client
> +retry_attempts = 10
> +for retry_attempt in range(retry_attempts):
> +try:
> +client.connect(
> +self.ip,
> +username=self.username,
> +port=self.port,
> +password=self.password,
> +timeout=20 if self.port else 10,
> +)
> +except (TypeError, BadHostKeyException, AuthenticationException)
> as e:
> +self._logger.exception(e)
> +raise SSHConnectionError(self.hostname) from e
> +except (NoValidConnectionsError, socket.error, SSHException) as
> e:
> +self._logger.debug(traceback.format_exc())
> +self._logger.warning(e)
> +self._logger.info(
> +"Retrying interactive session connection: "
> +f"retry number {retry_atte
[PATCH v3 0/6] dts: tg abstractions and scapy tg
Add abstractions for traffic generator split into those that can and can't capture traffic. The Scapy implementation uses an XML-RPC server for remote control. This requires an interactive session to add Scapy functions to the server. The interactive session code is based on another patch [0]. The basic test case is there to showcase the Scapy implementation - it sends just one UDP packet and verifies it on the other end. [0]: http://patches.dpdk.org/project/dpdk/patch/20230718214802.3214-3-jspew...@iol.unh.edu/ Juraj Linkeš (6): dts: add scapy dependency dts: add traffic generator config dts: traffic generator abstractions dts: add python remote interactive shell dts: scapy traffic generator implementation dts: add basic UDP test case doc/guides/tools/dts.rst | 31 ++ dts/conf.yaml | 27 +- dts/framework/config/__init__.py | 84 - dts/framework/config/conf_yaml_schema.json| 32 +- dts/framework/dts.py | 65 ++-- dts/framework/remote_session/__init__.py | 1 + dts/framework/remote_session/linux_session.py | 96 ++ dts/framework/remote_session/os_session.py| 35 ++- .../remote_session/remote/__init__.py | 1 + .../remote_session/remote/python_shell.py | 12 + dts/framework/test_suite.py | 221 - dts/framework/testbed_model/__init__.py | 1 + .../capturing_traffic_generator.py| 136 dts/framework/testbed_model/hw/port.py| 60 dts/framework/testbed_model/node.py | 34 +- dts/framework/testbed_model/scapy.py | 290 ++ dts/framework/testbed_model/sut_node.py | 9 +- dts/framework/testbed_model/tg_node.py| 99 ++ .../testbed_model/traffic_generator.py| 72 + dts/framework/utils.py| 13 + dts/poetry.lock | 21 +- dts/pyproject.toml| 1 + dts/tests/TestSuite_os_udp.py | 45 +++ 23 files changed, 1329 insertions(+), 57 deletions(-) create mode 100644 dts/framework/remote_session/remote/python_shell.py create mode 100644 dts/framework/testbed_model/capturing_traffic_generator.py create mode 100644 dts/framework/testbed_model/hw/port.py create mode 100644 dts/framework/testbed_model/scapy.py create mode 100644 dts/framework/testbed_model/tg_node.py create mode 100644 dts/framework/testbed_model/traffic_generator.py create mode 100644 dts/tests/TestSuite_os_udp.py -- 2.34.1
[PATCH v3 1/6] dts: add scapy dependency
Required for scapy traffic generator.
Signed-off-by: Juraj Linkeš
---
dts/poetry.lock| 21 -
dts/pyproject.toml | 1 +
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/dts/poetry.lock b/dts/poetry.lock
index 2438f337cd..8cb9920ec7 100644
--- a/dts/poetry.lock
+++ b/dts/poetry.lock
@@ -346,6 +346,19 @@ category = "main"
optional = false
python-versions = ">=3.6"
+[[package]]
+name = "scapy"
+version = "2.5.0"
+description = "Scapy: interactive packet manipulation tool"
+category = "main"
+optional = false
+python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, <4"
+
+[package.extras]
+basic = ["ipython"]
+complete = ["ipython", "pyx", "cryptography (>=2.0)", "matplotlib"]
+docs = ["sphinx (>=3.0.0)", "sphinx_rtd_theme (>=0.4.3)", "tox (>=3.0.0)"]
+
[[package]]
name = "six"
version = "1.16.0"
@@ -409,7 +422,7 @@ jsonschema = ">=4,<5"
[metadata]
lock-version = "1.1"
python-versions = "^3.10"
-content-hash =
"719c43bcaa5d181921debda884f8f714063df0b2336d61e9f64ecab034e8b139"
+content-hash =
"907bf4ae92b05bbdb7cf2f37fc63e530702f1fff9990afa1f8e6c369b97ba592"
[metadata.files]
attrs = []
@@ -431,10 +444,7 @@ mypy-extensions = []
paramiko = []
pathlib2 = []
pathspec = []
-platformdirs = [
-{file = "platformdirs-2.5.2-py3-none-any.whl", hash =
"sha256:027d8e83a2d7de06bbac4e5ef7e023c02b863d7ea5d079477e722bb41ab25788"},
-{file = "platformdirs-2.5.2.tar.gz", hash =
"sha256:58c8abb07dcb441e6ee4b11d8df0ac856038f944ab98b7be6b27b2a3c7feef19"},
-]
+platformdirs = []
pycodestyle = []
pycparser = []
pydocstyle = []
@@ -443,6 +453,7 @@ pylama = []
pynacl = []
pyrsistent = []
pyyaml = []
+scapy = []
six = []
snowballstemmer = []
toml = []
diff --git a/dts/pyproject.toml b/dts/pyproject.toml
index 50bcdb327a..bd7591f7fb 100644
--- a/dts/pyproject.toml
+++ b/dts/pyproject.toml
@@ -13,6 +13,7 @@ warlock = "^2.0.1"
PyYAML = "^6.0"
types-PyYAML = "^6.0.8"
fabric = "^2.7.1"
+scapy = "^2.5.0"
[tool.poetry.dev-dependencies]
mypy = "^0.961"
--
2.34.1
[PATCH v3 2/6] dts: add traffic generator config
Node configuration - where to connect, what ports to use and what TG to
use.
Signed-off-by: Juraj Linkeš
---
dts/conf.yaml | 26 ++-
dts/framework/config/__init__.py | 84 +++---
dts/framework/config/conf_yaml_schema.json | 29 +++-
dts/framework/dts.py | 12 ++--
dts/framework/testbed_model/sut_node.py| 5 +-
5 files changed, 135 insertions(+), 21 deletions(-)
diff --git a/dts/conf.yaml b/dts/conf.yaml
index 0825d958a6..0440d1d20a 100644
--- a/dts/conf.yaml
+++ b/dts/conf.yaml
@@ -13,10 +13,11 @@ executions:
skip_smoke_tests: false # optional flag that allows you to skip smoke tests
test_suites:
- hello_world
-system_under_test:
+system_under_test_node:
node_name: "SUT 1"
vdevs: # optional; if removed, vdevs won't be used in the execution
- "crypto_openssl"
+traffic_generator_node: "TG 1"
nodes:
- name: "SUT 1"
hostname: sut1.change.me.localhost
@@ -40,3 +41,26 @@ nodes:
os_driver: i40e
peer_node: "TG 1"
peer_pci: ":00:08.1"
+ - name: "TG 1"
+hostname: tg1.change.me.localhost
+user: dtsuser
+arch: x86_64
+os: linux
+lcores: ""
+ports:
+ - pci: ":00:08.0"
+os_driver_for_dpdk: rdma
+os_driver: rdma
+peer_node: "SUT 1"
+peer_pci: ":00:08.0"
+ - pci: ":00:08.1"
+os_driver_for_dpdk: rdma
+os_driver: rdma
+peer_node: "SUT 1"
+peer_pci: ":00:08.1"
+use_first_core: false
+hugepages: # optional; if removed, will use system hugepage configuration
+amount: 256
+force_first_numa: false
+traffic_generator:
+type: SCAPY
diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
index aa7ff358a2..9b5aff8509 100644
--- a/dts/framework/config/__init__.py
+++ b/dts/framework/config/__init__.py
@@ -12,7 +12,7 @@
import pathlib
from dataclasses import dataclass
from enum import auto, unique
-from typing import Any, TypedDict
+from typing import Any, TypedDict, Union
import warlock # type: ignore
import yaml
@@ -54,6 +54,11 @@ class Compiler(StrEnum):
msvc = auto()
+@unique
+class TrafficGeneratorType(StrEnum):
+SCAPY = auto()
+
+
# Slots enables some optimizations, by pre-allocating space for the defined
# attributes in the underlying data structure.
#
@@ -79,6 +84,26 @@ def from_dict(node: str, d: dict) -> "PortConfig":
return PortConfig(node=node, **d)
+@dataclass(slots=True, frozen=True)
+class TrafficGeneratorConfig:
+traffic_generator_type: TrafficGeneratorType
+
+@staticmethod
+def from_dict(d: dict):
+# This looks useless now, but is designed to allow expansion to traffic
+# generators that require more configuration later.
+match TrafficGeneratorType(d["type"]):
+case TrafficGeneratorType.SCAPY:
+return ScapyTrafficGeneratorConfig(
+traffic_generator_type=TrafficGeneratorType.SCAPY
+)
+
+
+@dataclass(slots=True, frozen=True)
+class ScapyTrafficGeneratorConfig(TrafficGeneratorConfig):
+pass
+
+
@dataclass(slots=True, frozen=True)
class NodeConfiguration:
name: str
@@ -89,17 +114,17 @@ class NodeConfiguration:
os: OS
lcores: str
use_first_core: bool
-memory_channels: int
hugepages: HugepageConfiguration | None
ports: list[PortConfig]
@staticmethod
-def from_dict(d: dict) -> "NodeConfiguration":
+def from_dict(d: dict) -> Union["SutNodeConfiguration",
"TGNodeConfiguration"]:
hugepage_config = d.get("hugepages")
if hugepage_config:
if "force_first_numa" not in hugepage_config:
hugepage_config["force_first_numa"] = False
hugepage_config = HugepageConfiguration(**hugepage_config)
+
common_config = {
"name": d["name"],
"hostname": d["hostname"],
@@ -109,12 +134,31 @@ def from_dict(d: dict) -> "NodeConfiguration":
"os": OS(d["os"]),
"lcores": d.get("lcores", "1"),
"use_first_core": d.get("use_first_core", False),
-"memory_channels": d.get("memory_channels", 1),
"hugepages": hugepage_config,
"ports": [PortConfig.from_dict(d["name"], port) for port in
d["ports"]],
}
-return NodeConfiguration(**common_config)
+if "traffic_generator" in d:
+return TGNodeConfiguration(
+traffic_generator=TrafficGeneratorConfig.from_dict(
+d["traffic_generator"]
+),
+**common_config,
+)
+else:
+return SutNodeConfiguration(
+memory_channels=d.get("memory_channels", 1), **common_config
+)
+
+
+@dataclass(slots=True, frozen=True)
+class SutNodeConfiguration(NodeConfiguratio
[PATCH v3 3/6] dts: traffic generator abstractions
There are traffic abstractions for all traffic generators and for
traffic generators that can capture (not just count) packets.
There also related abstractions, such as TGNode where the traffic
generators reside and some related code.
Signed-off-by: Juraj Linkeš
---
doc/guides/tools/dts.rst | 31
dts/framework/dts.py | 61
dts/framework/remote_session/linux_session.py | 78 ++
dts/framework/remote_session/os_session.py| 15 ++
dts/framework/test_suite.py | 4 +-
dts/framework/testbed_model/__init__.py | 1 +
.../capturing_traffic_generator.py| 136 ++
dts/framework/testbed_model/hw/port.py| 60
dts/framework/testbed_model/node.py | 20 ++-
dts/framework/testbed_model/scapy.py | 74 ++
dts/framework/testbed_model/sut_node.py | 1 +
dts/framework/testbed_model/tg_node.py| 99 +
.../testbed_model/traffic_generator.py| 72 ++
dts/framework/utils.py| 13 ++
14 files changed, 637 insertions(+), 28 deletions(-)
create mode 100644 dts/framework/testbed_model/capturing_traffic_generator.py
create mode 100644 dts/framework/testbed_model/hw/port.py
create mode 100644 dts/framework/testbed_model/scapy.py
create mode 100644 dts/framework/testbed_model/tg_node.py
create mode 100644 dts/framework/testbed_model/traffic_generator.py
diff --git a/doc/guides/tools/dts.rst b/doc/guides/tools/dts.rst
index c7b31623e4..2f97d1df6e 100644
--- a/doc/guides/tools/dts.rst
+++ b/doc/guides/tools/dts.rst
@@ -153,6 +153,37 @@ There are two areas that need to be set up on a System
Under Test:
sudo usermod -aG sudo
+
+Setting up Traffic Generator Node
+-
+
+These need to be set up on a Traffic Generator Node:
+
+#. **Traffic generator dependencies**
+
+ The traffic generator running on the traffic generator node must be
installed beforehand.
+ For Scapy traffic generator, only a few Python libraries need to be
installed:
+
+ .. code-block:: console
+
+ sudo apt install python3-pip
+ sudo pip install --upgrade pip
+ sudo pip install scapy==2.5.0
+
+#. **Hardware dependencies**
+
+ The traffic generators, like DPDK, need a proper driver and firmware.
+ The Scapy traffic generator doesn't have strict requirements - the drivers
that come
+ with most OS distributions will be satisfactory.
+
+
+#. **User with administrator privileges**
+
+ Similarly to the System Under Test, traffic generators need administrator
privileges
+ to be able to use the devices.
+ Refer to the `System Under Test section ` for details.
+
+
Running DTS
---
diff --git a/dts/framework/dts.py b/dts/framework/dts.py
index 1c4a637fbd..f773f0c38d 100644
--- a/dts/framework/dts.py
+++ b/dts/framework/dts.py
@@ -15,7 +15,7 @@
from .logger import DTSLOG, getLogger
from .test_result import BuildTargetResult, DTSResult, ExecutionResult, Result
from .test_suite import get_test_suites
-from .testbed_model import SutNode
+from .testbed_model import SutNode, TGNode
from .utils import check_dts_python_version
dts_logger: DTSLOG = getLogger("DTSRunner")
@@ -33,29 +33,31 @@ def run_all() -> None:
# check the python version of the server that run dts
check_dts_python_version()
-nodes: dict[str, SutNode] = {}
+sut_nodes: dict[str, SutNode] = {}
+tg_nodes: dict[str, TGNode] = {}
try:
# for all Execution sections
for execution in CONFIGURATION.executions:
-sut_node = None
-if execution.system_under_test_node.name in nodes:
-# a Node with the same name already exists
-sut_node = nodes[execution.system_under_test_node.name]
-else:
-# the SUT has not been initialized yet
-try:
+sut_node = sut_nodes.get(execution.system_under_test_node.name)
+tg_node = tg_nodes.get(execution.traffic_generator_node.name)
+
+try:
+if not sut_node:
sut_node = SutNode(execution.system_under_test_node)
-result.update_setup(Result.PASS)
-except Exception as e:
-dts_logger.exception(
-f"Connection to node
{execution.system_under_test_node} failed."
-)
-result.update_setup(Result.FAIL, e)
-else:
-nodes[sut_node.name] = sut_node
-
-if sut_node:
-_run_execution(sut_node, execution, result)
+sut_nodes[sut_node.name] = sut_node
+if not tg_node:
+tg_node = TGNode(execution.traffic_generator_node)
+tg_nodes[tg_node.name] = tg_node
+result.update_setup(Result.PASS)
+except
[PATCH v3 4/6] dts: add python remote interactive shell
The shell can be used to remotely run any Python code interactively.
Signed-off-by: Juraj Linkeš
---
dts/framework/remote_session/remote/python_shell.py | 12
1 file changed, 12 insertions(+)
create mode 100644 dts/framework/remote_session/remote/python_shell.py
diff --git a/dts/framework/remote_session/remote/python_shell.py
b/dts/framework/remote_session/remote/python_shell.py
new file mode 100644
index 00..cc3ad48a68
--- /dev/null
+++ b/dts/framework/remote_session/remote/python_shell.py
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2023 PANTHEON.tech s.r.o.
+
+from pathlib import PurePath
+
+from .interactive_shell import InteractiveShell
+
+
+class PythonShell(InteractiveShell):
+_default_prompt: str = ">>>"
+_command_extra_chars: str = "\n"
+path: PurePath = PurePath("python3")
--
2.34.1
[PATCH v3 5/6] dts: scapy traffic generator implementation
Scapy is a traffic generator capable of sending and receiving traffic. Since it's a software traffic generator, it's not suitable for performance testing, but it is suitable for functional testing. Signed-off-by: Juraj Linkeš --- dts/framework/remote_session/__init__.py | 1 + .../remote_session/remote/__init__.py | 1 + dts/framework/testbed_model/scapy.py | 224 +- 3 files changed, 222 insertions(+), 4 deletions(-) diff --git a/dts/framework/remote_session/__init__.py b/dts/framework/remote_session/__init__.py index 1155dd8318..00b6d1f03a 100644 --- a/dts/framework/remote_session/__init__.py +++ b/dts/framework/remote_session/__init__.py @@ -22,6 +22,7 @@ CommandResult, InteractiveRemoteSession, InteractiveShell, +PythonShell, RemoteSession, SSHSession, TestPmdDevice, diff --git a/dts/framework/remote_session/remote/__init__.py b/dts/framework/remote_session/remote/__init__.py index 1d29c3ea0d..06403691a5 100644 --- a/dts/framework/remote_session/remote/__init__.py +++ b/dts/framework/remote_session/remote/__init__.py @@ -9,6 +9,7 @@ from .interactive_remote_session import InteractiveRemoteSession from .interactive_shell import InteractiveShell +from .python_shell import PythonShell from .remote_session import CommandResult, RemoteSession from .ssh_session import SSHSession from .testpmd_shell import TestPmdDevice, TestPmdShell diff --git a/dts/framework/testbed_model/scapy.py b/dts/framework/testbed_model/scapy.py index 1a23dc9fa3..af0d4dbb25 100644 --- a/dts/framework/testbed_model/scapy.py +++ b/dts/framework/testbed_model/scapy.py @@ -12,10 +12,21 @@ a local server proxy. """ +import inspect +import marshal +import time +import types +import xmlrpc.client +from xmlrpc.server import SimpleXMLRPCServer + +import scapy.all # type: ignore[import] +from scapy.layers.l2 import Ether # type: ignore[import] from scapy.packet import Packet # type: ignore[import] from framework.config import OS, ScapyTrafficGeneratorConfig -from framework.logger import getLogger +from framework.logger import DTSLOG, getLogger +from framework.remote_session import PythonShell +from framework.settings import SETTINGS from .capturing_traffic_generator import ( CapturingTrafficGenerator, @@ -24,6 +35,134 @@ from .hw.port import Port from .tg_node import TGNode +""" += BEGIN RPC FUNCTIONS = + +All of the functions in this section are intended to be exported to a python +shell which runs a scapy RPC server. These functions are made available via that +RPC server to the packet generator. To add a new function to the RPC server, +first write the function in this section. Then, if you need any imports, make sure to +add them to SCAPY_RPC_SERVER_IMPORTS as well. After that, add the function to the list +in EXPORTED_FUNCTIONS. Note that kwargs (keyword arguments) do not work via xmlrpc, +so you may need to construct wrapper functions around many scapy types. +""" + +""" +Add the line needed to import something in a normal python environment +as an entry to this array. It will be imported before any functions are +sent to the server. +""" +SCAPY_RPC_SERVER_IMPORTS = [ +"from scapy.all import *", +"import xmlrpc", +"import sys", +"from xmlrpc.server import SimpleXMLRPCServer", +"import marshal", +"import pickle", +"import types", +"import time", +] + + +def scapy_send_packets_and_capture( +xmlrpc_packets: list[xmlrpc.client.Binary], +send_iface: str, +recv_iface: str, +duration: float, +) -> list[bytes]: +"""RPC function to send and capture packets. + +The function is meant to be executed on the remote TG node. + +Args: +xmlrpc_packets: The packets to send. These need to be converted to +xmlrpc.client.Binary before sending to the remote server. +send_iface: The logical name of the egress interface. +recv_iface: The logical name of the ingress interface. +duration: Capture for this amount of time, in seconds. + +Returns: +A list of bytes. Each item in the list represents one packet, which needs +to be converted back upon transfer from the remote node. +""" +scapy_packets = [scapy.all.Packet(packet.data) for packet in xmlrpc_packets] +sniffer = scapy.all.AsyncSniffer( +iface=recv_iface, +store=True, +started_callback=lambda *args: scapy.all.sendp(scapy_packets, iface=send_iface), +) +sniffer.start() +time.sleep(duration) +return [scapy_packet.build() for scapy_packet in sniffer.stop(join=True)] + + +def scapy_send_packets( +xmlrpc_packets: list[xmlrpc.client.Binary], send_iface: str +) -> None: +"""RPC function to send packets. + +The function is meant to be executed on the remote TG node. +It doesn't return anything, only sends packets. + +Args: +xmlrpc_packets: The packets to send. These need to be con
[PATCH v3 6/6] dts: add basic UDP test case
The test cases showcases the scapy traffic generator code.
Signed-off-by: Juraj Linkeš
---
dts/conf.yaml | 1 +
dts/framework/config/conf_yaml_schema.json| 3 +-
dts/framework/remote_session/linux_session.py | 20 +-
dts/framework/remote_session/os_session.py| 20 +-
dts/framework/test_suite.py | 217 +-
dts/framework/testbed_model/node.py | 14 +-
dts/framework/testbed_model/sut_node.py | 3 +
dts/tests/TestSuite_os_udp.py | 45
8 files changed, 315 insertions(+), 8 deletions(-)
create mode 100644 dts/tests/TestSuite_os_udp.py
diff --git a/dts/conf.yaml b/dts/conf.yaml
index 0440d1d20a..37967daea0 100644
--- a/dts/conf.yaml
+++ b/dts/conf.yaml
@@ -13,6 +13,7 @@ executions:
skip_smoke_tests: false # optional flag that allows you to skip smoke tests
test_suites:
- hello_world
+ - os_udp
system_under_test_node:
node_name: "SUT 1"
vdevs: # optional; if removed, vdevs won't be used in the execution
diff --git a/dts/framework/config/conf_yaml_schema.json
b/dts/framework/config/conf_yaml_schema.json
index 936a4bac5b..84e45fe3c2 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -185,7 +185,8 @@
"test_suite": {
"type": "string",
"enum": [
-"hello_world"
+"hello_world",
+"os_udp"
]
},
"test_target": {
diff --git a/dts/framework/remote_session/linux_session.py
b/dts/framework/remote_session/linux_session.py
index decce4039c..a3f1a6bf3b 100644
--- a/dts/framework/remote_session/linux_session.py
+++ b/dts/framework/remote_session/linux_session.py
@@ -3,7 +3,8 @@
# Copyright(c) 2023 University of New Hampshire
import json
-from typing import TypedDict
+from ipaddress import IPv4Interface, IPv6Interface
+from typing import TypedDict, Union
from typing_extensions import NotRequired
@@ -181,3 +182,20 @@ def configure_port_state(self, port: Port, enable: bool)
-> None:
self.send_command(
f"ip link set dev {port.logical_name} {state}", privileged=True
)
+
+def configure_port_ip_address(
+self,
+address: Union[IPv4Interface, IPv6Interface],
+port: Port,
+delete: bool,
+) -> None:
+command = "del" if delete else "add"
+self.send_command(
+f"ip address {command} {address} dev {port.logical_name}",
+privileged=True,
+verify=True,
+)
+
+def configure_ipv4_forwarding(self, enable: bool) -> None:
+state = 1 if enable else 0
+self.send_command(f"sysctl -w net.ipv4.ip_forward={state}",
privileged=True)
diff --git a/dts/framework/remote_session/os_session.py
b/dts/framework/remote_session/os_session.py
index ab4bfbfe4c..8a709eac1c 100644
--- a/dts/framework/remote_session/os_session.py
+++ b/dts/framework/remote_session/os_session.py
@@ -4,8 +4,9 @@
from abc import ABC, abstractmethod
from collections.abc import Iterable
+from ipaddress import IPv4Interface, IPv6Interface
from pathlib import PurePath
-from typing import Type, TypeVar
+from typing import Type, TypeVar, Union
from framework.config import Architecture, NodeConfiguration, NodeInfo
from framework.logger import DTSLOG
@@ -264,3 +265,20 @@ def configure_port_state(self, port: Port, enable: bool)
-> None:
"""
Enable/disable port.
"""
+
+@abstractmethod
+def configure_port_ip_address(
+self,
+address: Union[IPv4Interface, IPv6Interface],
+port: Port,
+delete: bool,
+) -> None:
+"""
+Configure (add or delete) an IP address of the input port.
+"""
+
+@abstractmethod
+def configure_ipv4_forwarding(self, enable: bool) -> None:
+"""
+Enable IPv4 forwarding in the underlying OS.
+"""
diff --git a/dts/framework/test_suite.py b/dts/framework/test_suite.py
index 056460dd05..3b890c0451 100644
--- a/dts/framework/test_suite.py
+++ b/dts/framework/test_suite.py
@@ -9,7 +9,13 @@
import importlib
import inspect
import re
+from ipaddress import IPv4Interface, IPv6Interface, ip_interface
from types import MethodType
+from typing import Union
+
+from scapy.layers.inet import IP # type: ignore[import]
+from scapy.layers.l2 import Ether # type: ignore[import]
+from scapy.packet import Packet, Padding # type: ignore[import]
from .exception import (
BlockingTestSuiteError,
@@ -21,6 +27,8 @@
from .settings import SETTINGS
from .test_result import BuildTargetResult, Result, TestCaseResult,
TestSuiteResult
from .testbed_model import SutNode, TGNode
+from .testbed_model.hw.port import Port, PortLink
+from .utils import get_packet_summaries
class TestSuite(object):
@@ -47,6 +55,15 @@ class TestSuite(object):
_test_cases_to_run: list[str]
_func: bool
_result: TestSuiteResult
+_port_li
[PATCH] doc: postpone deprecation of pipeline legacy API
Postpone the deprecation of the legacy pipeline, table and port library API and gradual stabilization of the new API. Signed-off-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index fb771a0305..56ef906cdb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -145,19 +145,16 @@ Deprecation Notices In the absence of such interest, this library will be removed in DPDK 23.11. * pipeline: The pipeline library legacy API (functions rte_pipeline_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new pipeline library API (functions rte_swx_pipeline_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new pipeline library API (functions rte_swx_pipeline_*) + will gradually transition from experimental to stable status. * table: The table library legacy API (functions rte_table_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new table library API (functions rte_swx_table_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new table library API (functions rte_swx_table_*) + will gradually transition from experimental to stable status. * port: The port library legacy API (functions rte_port_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new port library API (functions rte_swx_port_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new port library API (functions rte_swx_port_*) + will gradually transition from experimental to stable status. -- 2.34.1
[PATCH v2] doc: fix the template API requirements
The minimal SW and HW versions are added.
Fixes: 22681deead3e ("net/mlx5/hws: enable hardware steering")
Cc: va...@nvidia.com
Cc: sta...@dpdk.org
Signed-off-by: Bing Zhao
---
v2: fix the incorrect headline prefix
---
doc/guides/nics/mlx5.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 1052591d88..958193a608 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1621,6 +1621,14 @@ shortened below as "OFED".
| | | ConnectX-5| | ConnectX-5|
+---+-+-+
+.. table:: Minimal SW/HW versions for rte_flow template API
+
+ +-+++
+ | DPDK| NIC| Firmware |
+ +=+++
+ | 22.11 | ConnectX-6 Dx | xx.35.1012 |
+ +-+++
+
Notes for metadata
--
--
2.34.1
[PATCH v2] MAINTAINERS: add status information
Add a new field S: which indicates the status of support for individual sub-trees. Almost everything is marked as supported but components without any maintainer are listed as Orphan. Signed-off-by: Stephen Hemminger --- v2 - mark FreeBSD as Odd Fixes - pipeline, table, port are marked as deprecated so should be Obsolete MAINTAINERS | 267 +++- 1 file changed, 266 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5bb8090ebe7e..7882a3c020bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17,6 +17,16 @@ Descriptions of section entries: X: Files and directories exclusion, same rules as F: K: Keyword regex pattern to match content. One regex pattern per line. Multiple K: lines acceptable. + S: *Status*, one of the following: + Supported: Someone is actually paid to look after this. + Maintained: Someone actually looks after it. + Odd Fixes: It has a maintainer but they don't have time to do + much other than throw the odd patch in. See below.. + Orphan: No current maintainer [but maybe you could take the + role as you write your new code]. + Obsolete:Old code. Something tagged obsolete generally means + it has been replaced by a better system and you + should be using that. General Project Administration @@ -25,44 +35,54 @@ General Project Administration Main Branch M: Thomas Monjalon M: David Marchand +S: Supported T: git://dpdk.org/dpdk Next-net Tree M: Ferruh Yigit M: Andrew Rybchenko +S: Supported T: git://dpdk.org/next/dpdk-next-net Next-net-brcm Tree M: Ajit Khaparde +S: Supported T: git://dpdk.org/next/dpdk-next-net-brcm Next-net-intel Tree M: Qi Zhang +S: Supported T: git://dpdk.org/next/dpdk-next-net-intel Next-net-mrvl Tree M: Jerin Jacob +S: Supported T: git://dpdk.org/next/dpdk-next-net-mrvl Next-net-mlx Tree M: Raslan Darawsheh +S: Supported T: git://dpdk.org/next/dpdk-next-net-mlx Next-virtio Tree M: Maxime Coquelin M: Chenbo Xia +S: Supported T: git://dpdk.org/next/dpdk-next-virtio Next-crypto Tree M: Akhil Goyal +S: Supported T: git://dpdk.org/next/dpdk-next-crypto Next-eventdev Tree M: Jerin Jacob +S: Supported T: git://dpdk.org/next/dpdk-next-eventdev Next-baseband Tree M: Maxime Coquelin +S: Supported T: git://dpdk.org/next/dpdk-next-baseband Stable Branches @@ -70,17 +90,21 @@ M: Luca Boccassi M: Kevin Traynor M: Christian Ehrhardt M: Xueming Li +S: Supported T: git://dpdk.org/dpdk-stable Security Issues M: maintain...@dpdk.org +S: Supported Documentation (with overlaps) F: README F: doc/ +S: Supported Developers and Maintainers Tools M: Thomas Monjalon +S: Supported F: MAINTAINERS F: devtools/build-dict.sh F: devtools/check-abi.sh @@ -110,7 +134,7 @@ F: .mailmap Build System M: Bruce Richardson -F: Makefile +S: Maintained F: meson.build F: meson_options.txt F: config/ @@ -130,11 +154,13 @@ F: devtools/check-meson.py Public CI M: Aaron Conole M: Michael Santana +S: Supported F: .github/workflows/build.yml F: .ci/ Driver information M: Dmitry Kozlyuk +S: Maintained F: buildtools/coff.py F: buildtools/gen-pmdinfo-cfile.py F: buildtools/pmdinfogen.py @@ -147,6 +173,7 @@ Environment Abstraction Layer T: git://dpdk.org/dpdk EAL API and common code +S: Supported F: lib/eal/common/ F: lib/eal/unix/ F: lib/eal/include/ @@ -180,6 +207,7 @@ F: app/test/test_version.c Trace - EXPERIMENTAL M: Jerin Jacob M: Sunil Kumar Kori +S: Supported F: lib/eal/include/rte_trace*.h F: lib/eal/common/eal_common_trace*.c F: lib/eal/common/eal_trace.h @@ -188,6 +216,7 @@ F: app/test/test_trace* Memory Allocation M: Anatoly Burakov +S: Supported F: lib/eal/include/rte_fbarray.h F: lib/eal/include/rte_mem* F: lib/eal/include/rte_malloc.h @@ -209,11 +238,13 @@ F: app/test/test_memzone.c Interrupt Subsystem M: Harman Kalra +S: Supported F: lib/eal/include/rte_epoll.h F: lib/eal/*/*interrupts.* F: app/test/test_interrupts.c Keep alive +S: Orphan F: lib/eal/include/rte_keepalive.h F: lib/eal/common/rte_keepalive.c F: examples/l2fwd-keepalive/ @@ -221,6 +252,7 @@ F: doc/guides/sample_app_ug/keep_alive.rst Secondary process M: Anatoly Burakov +S: Maintained K: RTE_PROC_ F: lib/eal/common/eal_common_proc.c F: doc/guides/prog_guide/multi_proc_support.rst @@ -230,6 +262,7 @@ F: doc/guides/sample_app_ug/multi_process.rst Service Cores M: Harry van Haaren +S: Supported F: lib/eal/include/rte_service.h F: lib/eal/include/rte_service_component.h F: lib/eal/common/rte_service.c @@ -240,44 +273,52 @@ F: doc/guides/sample_app_ug/service_cores.rst Bitops M: Joyce Kong +S: Supported F: lib/eal/include/rte_bitops.h F: app/test/test_bitops.c Bitmap M: Cristian Dumitrescu +S: Supported F: lib/eal/include
Re: [PATCH] tap: fix build of tap_bpf_program
On Wed, 19 Jul 2023 11:03:36 +0100
Ferruh Yigit wrote:
> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> > On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> >> The tap_bpf_program.c is not built as part of normal DPDK
> >> EAL environment. It is intended to be built standalone
> >> and does not use rte_common.h.
> >>
> >> This reverts the related change from
> >> commit ef5baf3486e0 ("replace packed attributes")
> >>
> >> Note: this patch will cause expected warnings from checkpatch
> >> because the code involved is not used directly in DPDK environment.
> >>
> >> Signed-off-by: Stephen Hemminger
> >>
> >
> > Agree, this seems done by mistake as part of batch update,
> >
> > Acked-by: Ferruh Yigit
> >
> >
> > But I can't update the bpf file at all, if I am not missing something I
>
> * I can't *compile* the bpf file ...
>
> > am not sure if we should get just this update or have a patch/patchset
> > that fixes the build.
> >
> > @Ophir, how the bpf file is compiled? And did you test it recently?
> >
> > I am using command from the documentation:
> > `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> > -filetype=obj -o tap_bpf_program.o`
It looks like this won't work because it was expecting to be able
to find header files from older version of iproute2. These are not
distributed, and the change to support libbpf in iproute2 makes the
current versions not work.
As a stopgap, will look back in history and see what version of header
files will at least get a working build.
From there, need to replace how the conversion of .o to array works.
Would prefer to use dlopen() to read the ELF file rather than expecting
developers to hack together their own tools.
Not sure how much effort is really needed here. This is only being
used for the case of rte_flow with multiq RSS. Probably, no one ever
used it.
Re: [PATCH] doc: postpone deprecation of pipeline legacy API
On Wed, Jul 19, 2023 at 03:12:25PM +, Cristian Dumitrescu wrote: > Postpone the deprecation of the legacy pipeline, table and port > library API and gradual stabilization of the new API. > > Signed-off-by: Cristian Dumitrescu > --- > doc/guides/rel_notes/deprecation.rst | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) > No objection to this, though it would be really good to get the new functions stabilized in 23.11 when we lock down the 24 ABI. Acked-by: Bruce Richardson > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index fb771a0305..56ef906cdb 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -145,19 +145,16 @@ Deprecation Notices >In the absence of such interest, this library will be removed in DPDK > 23.11. > > * pipeline: The pipeline library legacy API (functions rte_pipeline_*) > - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. > - The new pipeline library API (functions rte_swx_pipeline_*) > - will gradually transition from experimental to stable status > - starting with DPDK 23.07 release. > + will be deprecated and subsequently removed in DPDK 24.11 release. > + Before this, the new pipeline library API (functions rte_swx_pipeline_*) > + will gradually transition from experimental to stable status. > > * table: The table library legacy API (functions rte_table_*) > - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. > - The new table library API (functions rte_swx_table_*) > - will gradually transition from experimental to stable status > - starting with DPDK 23.07 release. > + will be deprecated and subsequently removed in DPDK 24.11 release. > + Before this, the new table library API (functions rte_swx_table_*) > + will gradually transition from experimental to stable status. > > * port: The port library legacy API (functions rte_port_*) > - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. > - The new port library API (functions rte_swx_port_*) > - will gradually transition from experimental to stable status > - starting with DPDK 23.07 release. > + will be deprecated and subsequently removed in DPDK 24.11 release. > + Before this, the new port library API (functions rte_swx_port_*) > + will gradually transition from experimental to stable status. > -- > 2.34.1 >
Re: [PATCH] doc: update doc for idpf and cpfl
On Tue, 18 Jul 2023 17:02:12 + beilei.x...@intel.com wrote: > From: Beilei Xing > > Add recommended matching list for idpf pmd and cpfl pmd. > > Signed-off-by: Beilei Xing > --- > doc/guides/nics/cpfl.rst | 16 > doc/guides/nics/idpf.rst | 16 > 2 files changed, 32 insertions(+) > > diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst > index e88008e16e..258e89ed48 100644 > --- a/doc/guides/nics/cpfl.rst > +++ b/doc/guides/nics/cpfl.rst > @@ -21,6 +21,22 @@ To get better performance on Intel platforms, > please follow the :doc:`../linux_gsg/nic_perf_intel_platform`. > > > +Recommended Matching List > +- > + > +It is highly recommended to upgrade the MEV-ts release to avoid the > compatibility issues > +with the cpfl PMD. > +Here is the suggested matching list which has been tested and verified. > + > + ++--+ > + | DPDK | MEV-ts release | > + ++==+ > + |23.03 | 0.6.0 | > + ++--+ > + |23.07 | 0.9.1 | > + ++--+ > Since 23.03 is not an LTS release, it will not be supported when 23.07 is release. Probably best not to clutter up docs with 23.03
[PATCH v11 0/1] Add DTS smoke tests
From: Jeremy Spewock Added proper doc comments to the InteractiveRemoteSession and made InteractiveShell an abstract class. RFCs for this patch: * v3: https://mails.dpdk.org/archives/dev/2023-June/269859.html * v2: https://mails.dpdk.org/archives/dev/2023-May/267915.html * v1: https://mails.dpdk.org/archives/dev/2023-April/266580.html Previous patch: * v1: https://mails.dpdk.org/archives/dev/2023-June/271309.html * v2: https://mails.dpdk.org/archives/dev/2023-July/272833.html * v3: https://mails.dpdk.org/archives/dev/2023-July/272930.html * v4: https://mails.dpdk.org/archives/dev/2023-July/272964.html * v5: https://mails.dpdk.org/archives/dev/2023-July/272983.html * v6: https://mails.dpdk.org/archives/dev/2023-July/273019.html * v7: https://mails.dpdk.org/archives/dev/2023-July/273028.html * v8: https://mails.dpdk.org/archives/dev/2023-July/273117.html * v9: https://mails.dpdk.org/archives/dev/2023-July/273178.html * v10: https://mails.dpdk.org/archives/dev/2023-July/273197.html Jeremy Spewock (1): dts: add smoke tests dts/conf.yaml | 17 +- dts/framework/config/__init__.py | 79 ++-- dts/framework/config/conf_yaml_schema.json| 142 ++- dts/framework/dts.py | 84 ++--- dts/framework/exception.py| 12 ++ dts/framework/remote_session/__init__.py | 13 +- dts/framework/remote_session/linux_session.py | 3 +- dts/framework/remote_session/os_session.py| 49 - dts/framework/remote_session/posix_session.py | 29 ++- .../remote_session/remote/__init__.py | 10 ++ .../remote/interactive_remote_session.py | 122 + .../remote/interactive_shell.py | 133 ++ .../remote_session/remote/testpmd_shell.py| 49 + dts/framework/test_result.py | 21 ++- dts/framework/test_suite.py | 10 +- dts/framework/testbed_model/node.py | 43 - dts/framework/testbed_model/sut_node.py | 169 +- dts/framework/utils.py| 3 + dts/tests/TestSuite_smoke_tests.py| 114 19 files changed, 1008 insertions(+), 94 deletions(-) create mode 100644 dts/framework/remote_session/remote/interactive_remote_session.py create mode 100644 dts/framework/remote_session/remote/interactive_shell.py create mode 100644 dts/framework/remote_session/remote/testpmd_shell.py create mode 100644 dts/tests/TestSuite_smoke_tests.py -- 2.41.0
[PATCH v11 1/1] dts: add smoke tests
From: Jeremy Spewock
Adds a new test suite for running smoke tests that verify general
configuration aspects of the system under test. If any of these tests
fail, the DTS execution terminates as part of a "fail-fast" model.
Signed-off-by: Jeremy Spewock
---
dts/conf.yaml | 17 +-
dts/framework/config/__init__.py | 79 ++--
dts/framework/config/conf_yaml_schema.json| 142 ++-
dts/framework/dts.py | 84 ++---
dts/framework/exception.py| 12 ++
dts/framework/remote_session/__init__.py | 13 +-
dts/framework/remote_session/linux_session.py | 3 +-
dts/framework/remote_session/os_session.py| 49 -
dts/framework/remote_session/posix_session.py | 29 ++-
.../remote_session/remote/__init__.py | 10 ++
.../remote/interactive_remote_session.py | 122 +
.../remote/interactive_shell.py | 133 ++
.../remote_session/remote/testpmd_shell.py| 49 +
dts/framework/test_result.py | 21 ++-
dts/framework/test_suite.py | 10 +-
dts/framework/testbed_model/node.py | 43 -
dts/framework/testbed_model/sut_node.py | 169 +-
dts/framework/utils.py| 3 +
dts/tests/TestSuite_smoke_tests.py| 114
19 files changed, 1008 insertions(+), 94 deletions(-)
create mode 100644
dts/framework/remote_session/remote/interactive_remote_session.py
create mode 100644 dts/framework/remote_session/remote/interactive_shell.py
create mode 100644 dts/framework/remote_session/remote/testpmd_shell.py
create mode 100644 dts/tests/TestSuite_smoke_tests.py
diff --git a/dts/conf.yaml b/dts/conf.yaml
index 129801d87c..0825d958a6 100644
--- a/dts/conf.yaml
+++ b/dts/conf.yaml
@@ -10,9 +10,13 @@ executions:
compiler_wrapper: ccache
perf: false
func: true
+skip_smoke_tests: false # optional flag that allows you to skip smoke tests
test_suites:
- hello_world
-system_under_test: "SUT 1"
+system_under_test:
+ node_name: "SUT 1"
+ vdevs: # optional; if removed, vdevs won't be used in the execution
+- "crypto_openssl"
nodes:
- name: "SUT 1"
hostname: sut1.change.me.localhost
@@ -25,3 +29,14 @@ nodes:
hugepages: # optional; if removed, will use system hugepage configuration
amount: 256
force_first_numa: false
+ports:
+ - pci: ":00:08.0"
+os_driver_for_dpdk: vfio-pci # OS driver that DPDK will use
+os_driver: i40e
+peer_node: "TG 1"
+peer_pci: ":00:08.0"
+ - pci: ":00:08.1"
+os_driver_for_dpdk: vfio-pci
+os_driver: i40e
+peer_node: "TG 1"
+peer_pci: ":00:08.1"
diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
index a4b73483e6..aa7ff358a2 100644
--- a/dts/framework/config/__init__.py
+++ b/dts/framework/config/__init__.py
@@ -65,6 +65,20 @@ class HugepageConfiguration:
force_first_numa: bool
+@dataclass(slots=True, frozen=True)
+class PortConfig:
+node: str
+pci: str
+os_driver_for_dpdk: str
+os_driver: str
+peer_node: str
+peer_pci: str
+
+@staticmethod
+def from_dict(node: str, d: dict) -> "PortConfig":
+return PortConfig(node=node, **d)
+
+
@dataclass(slots=True, frozen=True)
class NodeConfiguration:
name: str
@@ -77,6 +91,7 @@ class NodeConfiguration:
use_first_core: bool
memory_channels: int
hugepages: HugepageConfiguration | None
+ports: list[PortConfig]
@staticmethod
def from_dict(d: dict) -> "NodeConfiguration":
@@ -85,19 +100,36 @@ def from_dict(d: dict) -> "NodeConfiguration":
if "force_first_numa" not in hugepage_config:
hugepage_config["force_first_numa"] = False
hugepage_config = HugepageConfiguration(**hugepage_config)
+common_config = {
+"name": d["name"],
+"hostname": d["hostname"],
+"user": d["user"],
+"password": d.get("password"),
+"arch": Architecture(d["arch"]),
+"os": OS(d["os"]),
+"lcores": d.get("lcores", "1"),
+"use_first_core": d.get("use_first_core", False),
+"memory_channels": d.get("memory_channels", 1),
+"hugepages": hugepage_config,
+"ports": [PortConfig.from_dict(d["name"], port) for port in
d["ports"]],
+}
+
+return NodeConfiguration(**common_config)
-return NodeConfiguration(
-name=d["name"],
-hostname=d["hostname"],
-user=d["user"],
-password=d.get("password"),
-arch=Architecture(d["arch"]),
-os=OS(d["os"]),
-lcores=d.get("lcores", "1"),
-use_first_core=d.get("use_first_core", False),
-memory_channel
Re: release candidate 23.07-rc3
IBM - Power Systems DPDK v23.07-rc3-8-g238f67ca9c * Build CI on Fedora 30,31,34,36,37 for ppc64le * Basic PF on Mellanox: No issue found * Performance: not tested. * OS: RHEL 9.1 kernel: 5.14.0-162.6.1.el9_1.ppc64le with gcc version 11.3.1 20220421 (Red Hat 11.3.1-2) (GCC) RHEL 8.8 kernel: 4.18.0-477.10.1.el8_8.ppc64le with gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC) RHEL 8.4 kernel: 4.18.0-305.72.1.el8_4.ppc64le with gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC) Systems tested: - LPARs on IBM Power10 CHRP IBM,9105-22A NICs: - Mellanox Mellanox Technologies MT2894 Family [ConnectX-6 Lx] - firmware version: 26.37.1014 - MLNX_OFED_LINUX-23.04-0.5.3.6 - LPARs on Power9 IBM,9009-42G NICs: - Mellanox Technologies MT28800 Family [ConnectX-5 Ex] - firmware-version: 16.35.2000 - MLNX_OFED_LINUX-23.04-0.5.3.6 Regards, Thinh Tran On 7/12/2023 12:38 PM, Thomas Monjalon wrote: A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v23.07-rc3 There are 139 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_23_07.html Only documentation and bug fixes should be accepted at this stage. As usual, you can report any issue on https://bugs.dpdk.org Do not forget to review documentation updates and deprecation notices. DPDK 23.07-rc4 should be the last release candidate. The final release should be done end of next week. Thank you everyone
Re: [PATCH v2] doc: fix the template API requirements
19/07/2023 17:35, Bing Zhao:
> The minimal SW and HW versions are added.
>
> Fixes: 22681deead3e ("net/mlx5/hws: enable hardware steering")
> Cc: va...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bing Zhao
Applied as "doc: add flow template API requirements for mlx5"
Re: [PATCH] doc: add tested platforms with NVIDIA NICs
19/07/2023 15:08, Raslan Darawsheh: > Add tested platforms with NVIDIA NICs to the 23.07 release notes. > > Signed-off-by: Raslan Darawsheh Applied, thanks.
Re: [PATCH] MAINTAINERS: remove one maintainer from procinfo
17/07/2023 16:28, Bruce Richardson: > On Wed, Jul 05, 2023 at 04:00:25PM -0700, Stephen Hemminger wrote: > > Mail to marayam.tah...@intel.com is bouncing. > > Presume no longer at Intel. > > > > Signed-off-by: Stephen Hemminger > > --- > > MAINTAINERS | 1 - > > 1 file changed, 1 deletion(-) > > > Acked-by: Bruce Richardson Applied, thanks.
Re: [PATCH] doc: fix description of runtime directories
16/07/2023 20:11, Stephen Hemminger:
> The documentation was never updated when the DPDK EAL
> was modified to follow standard runtime conventions.
>
> Fixes: 1835a22f342f ("support systemd service convention for runtime
> directory")
>
> Signed-off-by: Stephen Hemminger
Applied, thanks.
Re: [PATCH] doc: fix typos and wording of cuda guide
03/07/2023 10:14, Ali Alnubani:
> Adds missing punctuation, and improves wording.
> Additionally, one of the example commands for adding CUDA
> headers to CFLAGS is removed as it's redundant.
>
> Fixes: 24c77594e08f ("gpu/cuda: map GPU memory with GDRCopy")
> Fixes: 1306a73b1958 ("gpu/cuda: introduce CUDA driver")
> Cc: eagost...@nvidia.com
>
> Signed-off-by: Ali Alnubani
Applied, thanks.
Re: [PATCH] doc: fix typos and wording of cuda guide
03/07/2023 10:14, Ali Alnubani:
> Adds missing punctuation, and improves wording.
> Additionally, one of the example commands for adding CUDA
> headers to CFLAGS is removed as it's redundant.
>
> Fixes: 24c77594e08f ("gpu/cuda: map GPU memory with GDRCopy")
> Fixes: 1306a73b1958 ("gpu/cuda: introduce CUDA driver")
> Cc: eagost...@nvidia.com
>
> Signed-off-by: Ali Alnubani
Applied, thanks.
Re: [PATCH] doc: update BIOS setting and supported HW list for NTB
> > Update BIOS settings and supported platform list for Intel NTB.
> >
> > Fixes: f5057be340e4 ("raw/ntb: support Intel Ice Lake")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Junfeng Guo
>
> Acked-by: Jingjing Wu
Applied and replaced unicode characters with "\ |reg|" syntax.
Re: [PATCH v2] devtools: allow variable declaration inside for loop
> > > > > Declaring variable inside for loop is not supported via C89 and it was
> > > > > checked in checkpatch.sh via commit [1].
> > > > > But as DPDK supported C standard is becoming C99/C11 [2], declaring
> > > > > variable inside loop can be allowed.
> > > > >
> > > > > [1]
> > > > > Commit 43e73483a4b8 ("devtools: forbid variable declaration inside
> > > > for")
> > > > >
> > > > > [2]
> > > > > https://dpdk.org/patch/121912
> > > > >
> > > > > Signed-off-by: Ferruh Yigit
> > > > > ---
> > > > > Cc: Bruce Richardson
> > > > > Cc: David Marchand
> > > > >
> > > > > v2:
> > > > > * Update coding convention too
> > > > > ---
> > > >
> > > > Acked-by: Bruce Richardson
> > >
> > > Acked-by: Morten Brørup
>
> Acked-by: Tyler Retzlaff
Applied, thanks.
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Peng, Yuan > Sent: Tuesday, July 18, 2023 8:39 PM > To: Chen, LingliX ; Zhang, Qi Z > ; dev@dpdk.org > Subject: RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > -Original Message- > > From: Chen, LingliX > > Sent: Wednesday, March 22, 2023 1:52 PM > > To: Zhang, Qi Z ; dev@dpdk.org > > Cc: Peng, Yuan ; Chen, LingliX > > > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > > > Signed-off-by: Lingli Chen > > --- > Reviewed-by: Yuan Peng Applied to dpdk-next-net-intel. Thanks Qi
Re: [PATCH] devtools: forbid reference to doc.dpdk.org/guides
21/06/2023 12:51, Bruce Richardson: > On Wed, Jun 21, 2023 at 10:09:20AM +0200, David Marchand wrote: > > Putting links to doc.dpdk.org/guides in our documentation should be > > avoided because it makes the documentation point at the current state of > > the DPDK tree regardless of the version it is generated against. > > > > Note: it should be acceptable to mention previous versions of DPDK (like > > in old release notes), so the pattern has an explicit trailing /. > > > > Signed-off-by: David Marchand > > > Acked-by: Bruce Richardson Applied, thanks.
Re: [PATCH] doc: fix link to AF XDP PMD in CNI howto
21/06/2023 12:52, Bruce Richardson:
> On Wed, Jun 21, 2023 at 11:57:18AM +0200, David Marchand wrote:
> > Having an explicit link to the main repository documentation breaks
> > other repositories documentation (like for LTS releases).
> >
> > Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
>
> Acked-by: Bruce Richardson
Applied, thanks.
Re: [PATCH] doc: fix link to net/bnxt flow capabilities
21/06/2023 11:57, David Marchand:
> Having an explicit link to the main repository documentation breaks
> other repositories documentation (like for LTS releases).
>
> Besides, the tables numerotation may change so add an explicit anchor to
> those tables and refer to them.
>
> Fixes: b845c295cd13 ("doc: update Broadcom bnxt guide")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Applied, thanks.
Re: [PATCH V1] doc: add tested Intel platforms with Intel NICs
20/07/2023 06:11, Zhang, Qi Z: > > > -Original Message- > > From: Peng, Yuan > > Sent: Tuesday, July 18, 2023 8:39 PM > > To: Chen, LingliX ; Zhang, Qi Z > > ; dev@dpdk.org > > Subject: RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > > > -Original Message- > > > From: Chen, LingliX > > > Sent: Wednesday, March 22, 2023 1:52 PM > > > To: Zhang, Qi Z ; dev@dpdk.org > > > Cc: Peng, Yuan ; Chen, LingliX > > > > > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > > > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > > > > > Signed-off-by: Lingli Chen > > > --- > > Reviewed-by: Yuan Peng > > Applied to dpdk-next-net-intel. Did you apply a patch for the release notes of the last release??? I think there is no such patch yet for 23.07 release.
Re: [PATCH v2] usertools: add tool to generate balanced rss traffic flows
28/06/2023 15:47, Robin Jarry:
> usage: dpdk-rss-flows.py [-h] [-s SPORT_RANGE] [-d DPORT_RANGE] [-r]
> [-k RSS_KEY] [-t RETA_SIZE] [-a] [-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.
[...]
> usertools/dpdk-rss-flows.py | 418
> usertools/meson.build | 1 +
Applied, thanks.
You have great skills for user tools in Python,
and this file as other ones have no official maintainer:
usertools/dpdk-devbind.py
usertools/dpdk-hugepages.py
usertools/dpdk-rss-flows.py
Would like to take care of them?
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Thomas Monjalon > Sent: Thursday, July 20, 2023 12:38 PM > To: Zhang, Qi Z > Cc: Peng, Yuan ; Chen, LingliX > ; dev@dpdk.org; Zhang, Helin > > Subject: Re: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > 20/07/2023 06:11, Zhang, Qi Z: > > > > > -Original Message- > > > From: Peng, Yuan > > > Sent: Tuesday, July 18, 2023 8:39 PM > > > To: Chen, LingliX ; Zhang, Qi Z > > > ; dev@dpdk.org > > > Subject: RE: [PATCH V1] doc: add tested Intel platforms with Intel > > > NICs > > > > > > > -Original Message- > > > > From: Chen, LingliX > > > > Sent: Wednesday, March 22, 2023 1:52 PM > > > > To: Zhang, Qi Z ; dev@dpdk.org > > > > Cc: Peng, Yuan ; Chen, LingliX > > > > > > > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel > > > > NICs > > > > > > > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > > > > > > > Signed-off-by: Lingli Chen > > > > --- > > > Reviewed-by: Yuan Peng > > > > Applied to dpdk-next-net-intel. > > Did you apply a patch for the release notes of the last release??? > > I think there is no such patch yet for 23.07 release. > Sorry, actually I applied below one which looks almost same as this one 😊 https://patchwork.dpdk.org/project/dpdk/patch/20230717095222.28978-1-linglix.c...@intel.com/
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Chen, LingliX > Sent: Monday, July 17, 2023 5:52 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Chen, LingliX > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > Add tested Intel platforms with Intel NICs to v23.07 release note. > > Signed-off-by: Lingli Chen > --- > doc/guides/rel_notes/release_23_07.rst | 135 + > 1 file changed, 135 insertions(+) > > diff --git a/doc/guides/rel_notes/release_23_07.rst > b/doc/guides/rel_notes/release_23_07.rst > index d4af85b3ff..7ffcc31541 100644 > --- a/doc/guides/rel_notes/release_23_07.rst > +++ b/doc/guides/rel_notes/release_23_07.rst > @@ -326,3 +326,138 @@ Tested Platforms > This section is a comment. Do not overwrite or remove it. > Also, make sure to start the actual text at the margin. > === > + > +* Intel\ |reg| platforms with Intel\ |reg| NICs combinations > + > + * CPU > + > +* Intel\ |reg| Atom\ |trade| CPU C3758 @ 2.20GHz > +* Intel\ |reg| Xeon\ |reg| CPU D-1553N @ 2.30GHz > +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v4 @ 2.20GHz > +* Intel\ |reg| Xeon\ |reg| D-1747NTE CPU @ 2.50GHz > +* Intel\ |reg| Xeon\ |reg| D-2796NT CPU @ 2.00GHz > +* Intel\ |reg| Xeon\ |reg| Gold 6139 CPU @ 2.30GHz > +* Intel\ |reg| Xeon\ |reg| Gold 6140M CPU @ 2.30GHz > +* Intel\ |reg| Xeon\ |reg| Gold 6252N CPU @ 2.30GHz > +* Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz > +* Intel\ |reg| Xeon\ |reg| Platinum 8180 CPU @ 2.50GHz > +* Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz > +* Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz > +* Genuine Intel\ |reg| > + > + * OS: > + > +* CBL Mariner 2.0 > +* Fedora 38 > +* FreeBSD 13.2 > +* OpenAnolis OS 8.8 > +* Red Hat Enterprise Linux Server release 8.7 > +* Red Hat Enterprise Linux Server release 9.0 > +* SUSE Linux Enterprise Server 15 SP4 > +* Ubuntu 22.04.2 > + > + * NICs: > + > +* Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) > + > + * Firmware version: 4.30 0x80019dcc 1.3415.0 > + * Device id (pf/vf): 8086:1593 / 8086:1889 > + * Driver version(out-tree): 1.12.4_dirty (ice) > + * Driver version(in-tree): 5.15.0-70-generic (Ubuntu22.04.2)/ 5.14.0- > 70.13.1.rt21.83.el9_0.x86_64 (RHEL9.0)/ 5.15.107-rt62 (Ubuntu22.04.2)(ice) > + * OS Default DDP: 1.3.35.0 > + * COMMS DDP: 1.3.45.0 > + * Wireless Edge DDP: 1.3.13.0 > + > +* Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) > + > + * Firmware version: 4.30 0x80019dad 1.3415.0 > + * Device id (pf/vf): 8086:1592 / 8086:1889 > + * Driver version(out-tree): 1.12.4_dirty (ice) > + * Driver version(in-tree): 5.15.55.1-1.cm2-5464b22cac7+ (CBL Mariner > 2.0) > (ice) > + * OS Default DDP: 1.3.35.0 > + * COMMS DDP: 1.3.45.0 > + * Wireless Edge DDP: 1.3.13.0 > + > +* Intel\ |reg| Ethernet Controller E810-XXV for SFP (2x25G) > + > + * Firmware version: 4.30 0x80019da5 1.3415.0 > + * Device id (pf/vf): 8086:159b / 8086:1889 > + * Driver version: 1.12.4_dirty (ice) > + * OS Default DDP: 1.3.35.0 > + * COMMS DDP: 1.3.45.0 > + > +* Intel\ |reg| Ethernet Connection E823-C for QSFP > + > + * Firmware version: 3.32 0x8001a33d 1.3353.0 > + * Device id (pf/vf): 8086:188b / 8086:1889 > + * Driver version: 1.12.4_dirty (ice) > + * OS Default DDP: 1.3.35.0 > + * COMMS DDP: 1.3.45.0 > + * Wireless Edge DDP: 1.3.13.0 > + > +* Intel\ |reg| Ethernet Connection E823-L for QSFP > + > + * Firmware version: 3.32 0x8001a66d 1.3353.0 > + * Device id (pf/vf): 8086:124c / 8086:1889 > + * Driver version: 1.12.4_dirty (ice) > + * OS Default DDP: 1.3.35.0 > + * COMMS DDP: 1.3.45.0 > + * Wireless Edge DDP: 1.3.13.0 > + > +* Intel\ |reg| 82599ES 10 Gigabit Ethernet Controller > + > + * Firmware version: 0x61bf0001 > + * Device id (pf/vf): 8086:10fb / 8086:10ed > + * Driver version(out-tree): 5.18.13 (ixgbe) > + * Driver version(in-tree): 5.15.0-70-generic (Ubuntu22.04.2)/ 5.14.0- > 70.13.1.el9_0.x86_64 (RHEL9.0)(ixgbe) > + > +* Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) > + > + * Firmware version: 9.20 0x8000d8bd 1.3353.0 > + * Device id (pf/vf): 8086:1572 / 8086:154c > + * Driver version(out-tree): 2.23.5 (Fedora 38)(i40e) > + > +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ > (2x10G) > + > + * Firmware version: 6.20 0x80003d82 1.3353.0 > + * Device id (pf/vf): 8086:37d0 / 8086:37cd > + * Driver version(out-tree): 2.22.20 (i40e) > + * Driver version(in-tree): 5.14.0-70.13.1.el9_0.x86_64 (RHEL9.0)(i40e) > + > +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GBASE-T > + > + * Firmware version: 6.20 0x80003d3e 1.2935.0 > + * Device id (pf/vf): 8086:37d2 /
Re: [PATCH v2] doc: add information to update dma entry limit
05/07/2023 15:39, Nipun Gupta: > VFIO module provides configurable dma_entry_limit > parameter to store the DMA entries. By default this > is 64K and if we are using --no-huge, we shall need > to increase the value of dma_entry_limit. Add > commands in linux_gsg document to change the > dma_entry_limit. > > Signed-off-by: Nipun Gupta Applied, thanks.
release candidate 23.07-rc4
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v23.07-rc4 There are 37 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_23_07.html Except few policy updates and last minute release notes, everything ready and not risky should be there in DPDK 23.07-rc4. Do not forget to review the deprecation notices. You may share some release validation results by replying to this message at dev@dpdk.org and by adding tested hardware in the release notes. Please think about sharing your roadmap now for DPDK 23.11. Thank you everyone
Re: [PATCH v3 00/10] codeql fixes for various subsystems
On Thu, 2023-07-06 at 15:43 -0700, Stephen Hemminger wrote: > > lib/eal/common/eal_common_memalloc.c | 5 - > > lib/eal/common/eal_common_memzone.c | 10 +- > > lib/eal/common/malloc_elem.c | 14 +++--- > > lib/eal/common/malloc_heap.c | 9 - > > lib/ethdev/ethdev_vdev.h | 2 ++ > > lib/ethdev/rte_class_eth.c | 4 +++- > > 6 files changed, 37 insertions(+), 7 deletions(-) > > > The patches are fine, only warning was from the requirement that all > > submitters be in .mailmap now. Do you mind if I rebase these, add a > mailmap > > and combine the like ones together? > Please go ahead. > > > Acked-by: Stephen Hemminger
RE: net/mlx:mlx5 mlx_flow_create failed when set bond_mode_8023
Hi, Yan
Sorry, I do not follow the letter?
Are you proposing the patch for bonding PMD?
If so, could you, please send your patch in plain text, according to ML rules?
It is application responsibility to start bonding virtual device (and it will
start its slaves)
before flow creation.
With best regards,
Slava
From: compile_success <980965...@qq.com>
Sent: Tuesday, June 20, 2023 6:26 PM
To: users ; dev ; Matan Azrad
; Shahaf Shuler ; Slava Ovsiienko
Subject: net/mlx:mlx5 mlx_flow_create failed when set bond_mode_8023
Hi,
When I create bond4 with ConnectX-4 , mlx_flow_create return error;
When bond_port is opened, slave_port will be closed to sync bond_port config
（bond_ethdev_start -> slave_configure->rte_eth_dev_stop）
slave_configure(struct rte_eth_dev *bonded_eth_dev,
struct rte_eth_dev *slave_eth_dev)
{
uint16_t nb_rx_queues;
uint16_t nb_tx_queues;
int errval;
struct bond_dev_private *internals = bonded_eth_dev->data->dev_private;
/* Stop slave */
errval = rte_eth_dev_stop(slave_eth_dev->data->port_id);
if (errval != 0)
RTE_BOND_LOG(ERR, "rte_eth_dev_stop: port %u, err (%d)",
slave_eth_dev->data->port_id, errval);
However, If the device is not started yetm it is not allowed to created a flow
from application.
（slave_configure -> bond_ethdev_8023ad_flow_set -> rte_flow_create ->
mlx5_flow_create）
I want to add rte_eth_dev_start before bond_ethdev_8023ad_flow_set. This can
solve my problem.
[cid:image001.png@01D9B4CB.A5D91B50]
[PATCH] eal/linux: prevent deadlocks on rte init and cleanup
Resolves a deadlock that can occur when multiple secondary
processes are starting and stopping. A deadlock can occur because
eal_memalloc_init() is taking a second unnecessary read lock.
If another DPDK process that is terminating enters rte_eal_memory_detach()
and acquires a write lock wait state before the starting process can
acquire it's second read lock then no process will be able to proceed.
Cc: sta...@dpdk.org
Signed-off-by: Jonathan Erb
---
.mailmap | 2 +-
lib/eal/linux/eal_memalloc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/.mailmap b/.mailmap
index 6eccf0c555..a64bfcf1d2 100644
--- a/.mailmap
+++ b/.mailmap
@@ -663,7 +663,7 @@ John OLoughlin
John Ousterhout
John W. Linville
Jonas Pfefferle
-Jonathan Erb
+Jonathan Erb
Jon DeVree
Jon Loeliger
Joongi Kim
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index f8b1588cae..a34f1cf2f9 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -1740,7 +1740,7 @@ eal_memalloc_init(void)
eal_get_internal_configuration();
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
- if (rte_memseg_list_walk(secondary_msl_create_walk, NULL) < 0)
+ if
(rte_memseg_list_walk_thread_unsafe(secondary_msl_create_walk, NULL) < 0)
return -1;
if (rte_eal_process_type() == RTE_PROC_PRIMARY &&
internal_conf->in_memory) {
@@ -1778,7 +1778,7 @@ eal_memalloc_init(void)
}
/* initialize all of the fd lists */
- if (rte_memseg_list_walk(fd_list_create_walk, NULL))
+ if (rte_memseg_list_walk_thread_unsafe(fd_list_create_walk, NULL))
return -1;
return 0;
}
--
2.34.1
RE: [PATCH] doc: postpone deprecation of pipeline legacy API
-Original Message- From: Dumitrescu, Cristian Sent: Wednesday, July 19, 2023 8:42 PM To: dev@dpdk.org Cc: Richardson, Bruce ; Nicolau, Radu ; R, Kamalakannan ; Suresh Narayane, Harshad Subject: [PATCH] doc: postpone deprecation of pipeline legacy API Postpone the deprecation of the legacy pipeline, table and port library API and gradual stabilization of the new API. Signed-off-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index fb771a0305..56ef906cdb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -145,19 +145,16 @@ Deprecation Notices In the absence of such interest, this library will be removed in DPDK 23.11. * pipeline: The pipeline library legacy API (functions rte_pipeline_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new pipeline library API (functions rte_swx_pipeline_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new pipeline library API (functions + rte_swx_pipeline_*) will gradually transition from experimental to stable status. * table: The table library legacy API (functions rte_table_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new table library API (functions rte_swx_table_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new table library API (functions rte_swx_table_*) + will gradually transition from experimental to stable status. * port: The port library legacy API (functions rte_port_*) - will be deprecated in DPDK 23.07 release and removed in DPDK 23.11 release. - The new port library API (functions rte_swx_port_*) - will gradually transition from experimental to stable status - starting with DPDK 23.07 release. + will be deprecated and subsequently removed in DPDK 24.11 release. + Before this, the new port library API (functions rte_swx_port_*) + will gradually transition from experimental to stable status. -- 2.34.1 Acked-by: Harshad Narayane
Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle
On Thu, May 18, 2023 at 6:52 PM wrote: > > From: Jerin Jacob > > Based on techboard meeting[1] action item, defining the process for a > new library approval in principle. > > [1] > https://mails.dpdk.org/archives/dev/2023-January/260035.html > > Signed-off-by: Jerin Jacob > --- > RFC..v1: > - Fix the review comments by Konstantin, Keven, Thomas at > http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jer...@marvell.com/ Ping for review or merge
Re: [dpdk-dev] [PATCH v1] doc: add inbuilt graph nodes data flow
On Mon, Jun 26, 2023 at 11:34 AM Yan, Zhirun wrote: > > > > > -Original Message- > > From: jer...@marvell.com > > Sent: Friday, June 23, 2023 3:36 PM > > To: dev@dpdk.org; Jerin Jacob ; Kiran Kumar K > > ; Nithin Dabilpuram ; > > Yan, Zhirun > > Cc: tho...@monjalon.net; pbhagavat...@marvell.com > > Subject: [dpdk-dev] [PATCH v1] doc: add inbuilt graph nodes data flow > > > > From: Jerin Jacob > > > > Added diagram to depict the data flow between inbuilt graph nodes. > > > > In order to avoid graphviz package dependency to DPDK documentation, manual > > step added to create a svg file from the dot file. The details for the same > > is > > documented in graph_inbuilt_node_flow.svg as a comment. > > > > Signed-off-by: Jerin Jacob > > --- > > Reviewed-by: Zhirun Yan Ping for merge
