Re: [V1] doc: announce deprecation of flow item VXLAN-GPE
26/07/2024 13:31, Ferruh Yigit: > On 7/26/2024 9:51 AM, Gavin Li wrote: > > Adding the deprecation notice as reminder for removing > > RTE_FLOW_ITEM_TYPE_VXLAN_GPE and its related structures, > > eg. rte_vxlan_gpe_hdr, rte_flow_item_vxlan_gpe, etc. > > > > The proposed time of the removal is DPDK release 25.11. > > > > Signed-off-by: Gavin Li > > --- > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > + * ethdev,net: The flow item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE`` is replaced > > with ``RTE_FLOW_ITEM_TYPE_VXLAN``. > > + The struct ``rte_flow_item_vxlan_gpe``, its mask > > ``rte_flow_item_vxlan_gpe_mask`` are replaced with > > + ``rte_flow_item_vxlan and its mask`` and its mask > > ``rte_flow_item_vxlan_mask``. > > + The item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE``, the struct > > ``rte_flow_item_vxlan_gpe``, its mask ``rte_flow_item_vxlan_gpe_mask``, > > + and the header struct ``rte_vxlan_gpe_hdr`` with the macro > > ``RTE_ETHER_VXLAN_GPE_HLEN`` > > + will be removed in DPDK 25.11. > > Acked-by: Ferruh Yigit Acked-by: Thomas Monjalon
RE: [PATCH v2] doc: announce rte_ipsec API changes
> > > > > > In case of event mode operations where event device can help > > > > > > in atomic sequence number increment across cores, sequence > > > > > > number need to be provided by the application instead of being > > > > > > updated in rte_ipsec or the PMD. To support this, a new flag > > > > > > ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` > > > > > > will be added to disable sequence number update inside IPsec > > > > > > library and the API rte_ipsec_pkt_crypto_prepare will be > > > > > > extended to include ``sqn`` as an additional parameter to > > > > > > specify sequence number to be used for IPsec from the application. > > > > > > > > > > Could you probably elaborate a bit more: > > > > > Why such change is necessary for event-dev mode, what exactly > > > > > will be affected in librte_ipsec (would it be for outbound mode, or > both), etc. > > > > > > > > > > > > > [Aakash] When using eventdev, it is possible to have multiple > > > > cores process packets from the same flow at the same time, but > > > > still have ordering > > > maintained. > > > > > > > > Sequence for IPsec would be like below, 1. Ethdev Rx computes flow > > > > hash and submits packets to an ORDERED eventdev queue. > > > > One flow would always hit one event dev queue. > > > > One eventdev queue can be attached to multiple eventdev ports. > > > > 2. Lcores receives packets via these eventdev ports. > > > > Lcores can now process the packets from the same flow in parallel. > > > > 3. Lcores submit the packets to an ATOMIC queue > > > > This is needed as IPsec seq no update needs to be done atomically. > > > > 4. After seq no update, packets are moved to ORDERED queue. > > > > Lcores can now processes the packets in parallel again. > > > > 5. During Tx, eventdev ensures packet ordering based on ORDERED > queue. > > > > > > > > Since lib IPsec takes care of sequence number assignment, complete > > > > rte_ipsec_pkt_crypto_prepare() routine need to be made as ATOMIC > stage. > > > > But apart from seq no update, rest of the operations can be done in > parallel. > > > > > > Thanks for explanation. > > > Basically you are seeking ability to split > > > rte_ipsec_pkt_crypto_prepare() for outbound into two stages: > > > 1. update sqn > > > 2. all other preps > > > To be able to do step #2 in parallel, correct? > > > My thought always was that step #2 is not that expensive in terms of > > > performance, and there probably not much point to make it parallel. > > > But I suppose you measured step#2 overhead on your platform and > > > concluded that it worth it... > > > > > > One concern I have with the way you suggested - now we need to > > > store/update sa.sqn by some external entity. > > > Another thing - don't really want to pollute crypto_prepare() API > > > with new parameters which meaning is a bit obscure and depends on other > API calls... > > > > > > Wouldn't it be easier and probably more straightforward to just > > > introduce 2 new functions here that would represent step #1 and step #2? > > > Then we can keep crypto_prepare() intact, and user will have a choice: > > > - either use original crypto_prepare() - nothing needs to be > > > changed > > > - or instead call these new functions on his own, if he wants to. > > > > > > > [Aakash] As I understand, your suggestion is to introduce a set of two > > new APIs by splitting the current logic in crypto_prepare(). This should be > okay. > > For this, I believe we would need change in the structure > rte_ipsec_sa_pkt_func to hold the function pointers for the new APIs. > > Yes, that was my thought. > > > > > Assuming that, introduction of the new flag > > RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE to disable seq no assignment in > lib IPsec is fine, shall I send v3 announcing changes in ``struct > rte_ipsec_sa_pkt_func``? > > I am definitely not against this new flag, but if we'll have 2 new functions > instead, do you still need it? > > > > > In addition, we are also looking at another use case when a set of > > > > packets from a session can be IPsec processed by rte_security > > > > device and some packets from the same session would need to be SW > > > > processed > > > with lib IPsec. Here again the sequence number assignment would need > > > to occur at central place so that sequence number is not repeated. > > > > > > Interesting, and how SW/HW SQN will be synchronized in that case? > > > > > > > [Aakash] The design is such that HW would assign sequence number for > > all cases. HW would then pass this data as a metadata to SW so that it can > > do > SW processing with the assigned sequence number. > > As I can see there are two options to fulfill that requirement: > > 1. Introduce a new function that would update sa.sqn value. > Something like rte_ipsec_sa_update_sqn(...). > So when metadata from HW arrives, SW can call it and sync sa.sqn with new > HW value, and then continue with conventional rte_ipsec_crypto_prepare(...); > [Aakash] With option 1,
RE: [PATCH v5 6/6] vhost: optimize memcpy routines when cc memcpy is used
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> Sent: Wednesday, 24 July 2024 09.54
Which packet mix was used for your tests? Synthetic IMIX, or some live data?
> +/* The code generated by GCC (and to a lesser extent, clang) with just
> + * a straight memcpy() to copy packets is less than optimal on Intel
> + * P-cores, for small packets. Thus the need of this specialized
> + * memcpy() in builds where use_cc_memcpy is set to true.
> + */
> +#if defined(RTE_USE_CC_MEMCPY) && defined(RTE_ARCH_X86_64)
> +static __rte_always_inline void
> +pktcpy(void *restrict in_dst, const void *restrict in_src, size_t len)
> +{
> + void *dst = __builtin_assume_aligned(in_dst, 16);
> + const void *src = __builtin_assume_aligned(in_src, 16);
> +
> + if (len <= 256) {
> + size_t left;
> +
> + for (left = len; left >= 32; left -= 32) {
> + memcpy(dst, src, 32);
> + dst = RTE_PTR_ADD(dst, 32);
> + src = RTE_PTR_ADD(src, 32);
> + }
> +
> + memcpy(dst, src, left);
> + } else
Although the packets within a burst often have similar size, I'm not sure you
can rely on the dynamic branch predictor here.
Looking at the ethdev packet size counters at an ISP (at the core of their
Layer 3 network), 71 % are 256 byte or larger [1].
For static branch prediction, I would consider > 256 more likely and swap the
two branches, i.e. compare (len > 256) instead of (len <= 256).
But again: I don't know how the dynamic branch predictor behaves here. Perhaps
my suggested change makes no difference.
> + memcpy(dst, src, len);
> +}
With or without suggested change,
Acked-by: Morten Brørup
[1]: Details (incl. one VLAN tag)
tx_size_64_packets1,1 %
tx_size_65_to_127_packets25,7 %
tx_size_128_to_255_packets2,6 %
tx_size_256_to_511_packets1,4 %
tx_size_512_to_1023_packets 1,7 %
tx_size_1024_to_1522_packets 67,6 %
[DPDK/testpmd Bug 1504] Segmentation fault when enable avail_thresh on hairpin queues
https://bugs.dpdk.org/show_bug.cgi?id=1504 Bug ID: 1504 Summary: Segmentation fault when enable avail_thresh on hairpin queues Product: DPDK Version: 23.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: testpmd Assignee: dev@dpdk.org Reporter: k...@cesnet.cz Target Milestone: --- [Environment] DPDK version: dpdk-23.11 OS: Oracle Linux Server 8.10 NIC hardware: MT2892 Family [ConnectX-6 Dx] 101d NIC driver: MLNX_OFED_LINUX-23.10-0.5.5.0 (OFED-23.10-0.5.5) NIC firmware: 22.38.1002 [Test Setup] sudo dpdk-testpmd -l 0-1 -n 4 -a :17:00.0 -- --rxq=1 --txq=1 --hairpinq=1 -i testpmd> set port 0 rxq 1 avail_thresh 50 Segmentation fault [Expected Result] sudo dpdk-testpmd -l 0-1 -n 4 -a :17:00.0 -- --rxq=1 --txq=1 --hairpinq=1 -i testpmd> set port 0 rxq 1 avail_thresh 50 testpmd> Received avail_thresh event, port: 0, rxq_id: 0 mlx5_test_avail_thresh_event_handler port_id:0 rxq_id:0 mlx5_test_host_shaper_disable disable shaper Received avail_thresh event, port: 0, rxq_id: 0 mlx5_test_avail_thresh_event_handler port_id:0 rxq_id:0 mlx5_test_host_shaper_disable disable shaper ... -- You are receiving this mail because: You are the assignee for the bug.
[PATCH v3] doc: announce rte_ipsec API changes
In case of event mode operations where event device can help in atomic sequence number increment across cores, sequence number need to be provided by the application instead of being updated in rte_ipsec or the PMD. To support this, two new APIs rte_ipsec_pkt_crypto_sqn_assign and rte_ipsec_pkt_crypto_xprepare are introduced decoupling the seq no update functionality from the existing rte_ipsec_pkt_crypto_prepare API. Additionally, a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` will be added to allow disabling of internal sequence number update inside IPsec library. Signed-off-by: Aakash Sasidharan --- doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 6948641ff6..9be7b90b94 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -133,6 +133,14 @@ Deprecation Notices Since these functions are not called directly by the application, the API remains unaffected. +* ipsec: The rte_ipsec library is updated to support sequence number provided + by application. To allow the same, two new APIs are being introduced: + rte_ipsec_pkt_crypto_sqn_assign and rte_ipsec_pkt_crypto_xprepare. These APIs + separate the seq no update functionality from the existing rte_ipsec_pkt_crypto_prepare + API. Corresponding configure structure changes are being made for the new APIs. + Additionally a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` is + introduced to disable sequence number assignment in lib IPsec. + * pipeline: The pipeline library legacy API (functions rte_pipeline_*) will be deprecated and subsequently removed in DPDK 24.11 release. Before this, the new pipeline library API (functions rte_swx_pipeline_*) -- 2.25.1
RE: [PATCH v3] doc: announce rte_ipsec API changes
> Subject: [PATCH v3] doc: announce rte_ipsec API changes > > In case of event mode operations where event device can help in atomic > sequence number increment across cores, sequence number need to be > provided by the application instead of being updated in rte_ipsec or the > PMD. > > To support this, two new APIs rte_ipsec_pkt_crypto_sqn_assign and > rte_ipsec_pkt_crypto_xprepare are introduced decoupling the seq no update > functionality from the existing rte_ipsec_pkt_crypto_prepare API. > Additionally, a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` will be > added to allow disabling of internal sequence number update inside IPsec > library. > > Signed-off-by: Aakash Sasidharan Acked-by: Akhil Goyal <>
[RFC] dmadev: add QoS capability
Some DMA controllers support QoS at HW command queue level to
differentiate the performance on different HW queues based on
the priority configured. Patch adds required fields in dmadev
structures to get hardware supported priority levels and the
provision to configure the priority from the applications.
Signed-off-by: Vamsi Attunuru
---
lib/dmadev/rte_dmadev.c | 10 ++
lib/dmadev/rte_dmadev.h | 19 +++
2 files changed, 29 insertions(+)
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 845727210f..9ff62efcb4 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -491,6 +491,16 @@ rte_dma_configure(int16_t dev_id, const struct
rte_dma_conf *dev_conf)
"Device %d configure too many vchans", dev_id);
return -EINVAL;
}
+ if (dev_conf->priority &&
+ !(dev_info.dev_capa & RTE_DMA_CAPA_QOS)) {
+ RTE_DMA_LOG(ERR, "Device %d don't support QoS", dev_id);
+ return -EINVAL;
+ }
+ if (dev_conf->priority >= dev_info.nb_priorities) {
+ RTE_DMA_LOG(ERR,
+ "Device %d configure invalid priority", dev_id);
+ return -EINVAL;
+ }
if (dev_conf->enable_silent &&
!(dev_info.dev_capa & RTE_DMA_CAPA_SILENT)) {
RTE_DMA_LOG(ERR, "Device %d don't support silent", dev_id);
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index 5474a5281d..08db8ead0a 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -268,6 +268,16 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
#define RTE_DMA_CAPA_OPS_COPY_SG RTE_BIT64(33)
/** Support fill operation. */
#define RTE_DMA_CAPA_OPS_FILL RTE_BIT64(34)
+/** Support QoS at DMA HW channel level
+ *
+ * If device supports QoS then application could configure priority to the
+ * DMA HW channel using 'priority' field in struct rte_dma_conf. Number of
+ * supported prioirty levels will be known from 'nb_priorities' field in
+ * struct rte_dma_info.
+ * DMA devices which support QoS at HW channel level can advertise this
+ * capability.
+ */
+#define RTE_DMA_CAPA_QOS RTE_BIT64(35)
/**@}*/
/**
@@ -297,6 +307,8 @@ struct rte_dma_info {
int16_t numa_node;
/** Number of virtual DMA channel configured. */
uint16_t nb_vchans;
+ /** Number of priority levels supported by DMA HW channel. */
+ uint16_t nb_priorities;
};
/**
@@ -332,6 +344,13 @@ struct rte_dma_conf {
* @see RTE_DMA_CAPA_SILENT
*/
bool enable_silent;
+ /* The prioirty of the DMA HW channel.
+* This value cannot be greater than or equal to the field
'nb_priorities'
+* of struct rte_dma_info which get from rte_dma_info_get().
+* Among the values between '0' and 'nb_priorities - 1', lowest value
+* indicates higher priority and vice-versa.
+*/
+ uint16_t priority;
};
/**
--
2.25.1
RE: [PATCH v3] doc: announce rte_ipsec API changes
> In case of event mode operations where event device can help in atomic > sequence number increment across cores, sequence number need to be > provided by the application instead of being updated in rte_ipsec or the > PMD. > > To support this, two new APIs rte_ipsec_pkt_crypto_sqn_assign and > rte_ipsec_pkt_crypto_xprepare are introduced decoupling the seq no update > functionality from the existing rte_ipsec_pkt_crypto_prepare API. > Additionally, a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` will be > added to allow disabling of internal sequence number update inside IPsec > library. > > Signed-off-by: Aakash Sasidharan > --- > doc/guides/rel_notes/deprecation.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 6948641ff6..9be7b90b94 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -133,6 +133,14 @@ Deprecation Notices >Since these functions are not called directly by the application, >the API remains unaffected. > > +* ipsec: The rte_ipsec library is updated to support sequence number provided > + by application. To allow the same, two new APIs are being introduced: > + rte_ipsec_pkt_crypto_sqn_assign and rte_ipsec_pkt_crypto_xprepare. These > APIs > + separate the seq no update functionality from the existing > rte_ipsec_pkt_crypto_prepare > + API. Corresponding configure structure changes are being made for the new > APIs. > + Additionally a new flag ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE`` is > + introduced to disable sequence number assignment in lib IPsec. > + > * pipeline: The pipeline library legacy API (functions rte_pipeline_*) >will be deprecated and subsequently removed in DPDK 24.11 release. >Before this, the new pipeline library API (functions rte_swx_pipeline_*) > -- Acked-by: Konstantin Ananyev > 2.25.1
[PATCH] doc: announce dmadev new capability addition
Announce addition of new capability flag and fields in rte_dma_info and rte_dma_conf structures. Signed-off-by: Vamsi Attunuru --- RFC: https://patchwork.dpdk.org/project/dpdk/patch/20240729115558.263574-1-vattun...@marvell.com/ doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 6948641ff6..05d28473c0 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -147,3 +147,8 @@ Deprecation Notices 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. + +* dmadev: A new flag ``RTE_DMA_CAPA_QOS`` will be introduced to advertise + dma device's QoS capability. Also new fields will be added in ``rte_dma_info`` + and ``rte_dma_conf`` structures to get device supported priority levels + and to configure the required priority level. -- 2.25.1
[PATCH] examples/ipsec-secgw: revert fix SA salt endianness
The previous commit swapped the bytes of SA salt which
led to incorrect work of the ipsec-secgw application.
This patch reverts the previous commit and changes
the type of the salt field in the ipsec_sa structure.
Fixes: e6bfd9676109 ("examples/ipsec-secgw: fix SA salt endianness")
Cc: shihong.w...@corigine.com
Cc: sta...@dpdk.org
Signed-off-by: Vladimir Medvedkin
---
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/sa.c| 13 ++---
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index a83fd2283b..1fe6b97168 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -117,7 +117,7 @@ struct __rte_cache_aligned ipsec_sa {
uint32_t spi;
struct cdev_qp *cqp[RTE_MAX_LCORE];
uint64_t seq;
- uint32_t salt;
+ rte_be32_t salt;
uint32_t fallback_sessions;
enum rte_crypto_cipher_algorithm cipher_algo;
enum rte_crypto_auth_algorithm auth_algo;
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 8aa9aca739..c4bac17cd7 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -374,7 +374,6 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
uint32_t ti; /*token index*/
uint32_t *ri /*rule index*/;
struct ipsec_sa_cnt *sa_cnt;
- rte_be32_t salt; /*big-endian salt*/
uint32_t cipher_algo_p = 0;
uint32_t auth_algo_p = 0;
uint32_t aead_algo_p = 0;
@@ -509,8 +508,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
if (algo->algo == RTE_CRYPTO_CIPHER_AES_CTR) {
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&salt, &rule->cipher_key[key_len], 4);
- rule->salt = rte_be_to_cpu_32(salt);
+ memcpy(&rule->salt,
+ &rule->cipher_key[key_len], 4);
}
cipher_algo_p = 1;
@@ -574,8 +573,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->auth_key_len = key_len;
rule->iv_len = algo->iv_len;
- memcpy(&salt, &rule->auth_key[key_len], 4);
- rule->salt = rte_be_to_cpu_32(salt);
+ memcpy(&rule->salt,
+ &rule->auth_key[key_len], 4);
}
auth_algo_p = 1;
@@ -633,8 +632,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&salt, &rule->cipher_key[key_len], 4);
- rule->salt = rte_be_to_cpu_32(salt);
+ memcpy(&rule->salt,
+ &rule->cipher_key[key_len], 4);
aead_algo_p = 1;
continue;
--
2.34.1
[RFC PATCH v2 0/1] Add Visual Studio Code configuration script
Lots of developers (myself included) uses Visual Studio Code as their primary IDE for DPDK development. I have been successfully using various incarnations of this script internally to quickly set up my development trees whenever I need a new configuration, so this script is being shared in hopes that it will be useful both to new developers starting with DPDK, and to seasoned DPDK developers who are already using Visual Studio Code. It makes starting working on DPDK in Visual Studio Code so much easier! ** NOTE: Currently, only x86 configuration is generated as I have no way to test the code analysis configuration on any other platforms. ** NOTE 2: this is not for *Visual Studio* the Windows IDE, this is for *Visual Studio Code* the cross-platform code editor. Specifically, main target audience for this script is people who either run DPDK directly on their Linux machine, or who use Remote SSH functionality to connect to a remote Linux machine and set up VSCode build there. No other OS's are currently supported by the script. (if you're unaware of what is Remote SSH, I highly suggest checking it out [1]) Philosophy behind this script is as follows: - The assumption is made that a developer will not be using wildly different configurations from build to build - usually, they build the same things, work with the same set of apps/drivers for a while, then switch to something else, at which point a new configuration is needed - Some configurations I consider to be "common" are included: debug build, debug optimized build, release build with docs, and ASan build (feel free to make suggestions here!) - By default, the script will not add any meson flags unless user requested it, however it will create launch configurations for all apps because not specifying any flags leads to all apps being enabled - All parameters that can be adjusted by TUI are also available as command line arguments, so while user interaction is the default (using whiptail), it's actually not required and can be bypassed - I usually work as a local user not as root, so by default the script will attempt to use "gdbsudo" (a "sudo gdb $@" script in /usr/local/bin) for launch tasks, unless user specifically requests using gdb or is running as root With the above assumptions, the script is expected to work for basic DPDK configuration, as well as allow scripting any and all parts of it: - Any build configurations specified on the command-line will be added to the interactive configuration selector - Any apps/examples/drivers specified on the command-line will be selected by default in the interactive configuration selector - Any custom meson strings will also be filled in by default - When --no-ui is passed, all of the above parameters will be used to generate config as if the user has selected them There are a few usability issues with the script that are very difficult, if not impossible to solve for all cases, so a few other decisions have been made to hopefully address these issues for most cases. For starters, we can only know which apps/examples will get built after we create a build directory and process dependencies; we cannot infer this from our script. Therefore, by default all apps will get launch configurations created, even though these apps might not be built later. We could add another step after build to check config for missing apps and removing them, but it's difficult to do that without destroying any custom configuration user might have created. We remove generated configuration as it is! More importantly, our build system supports wildcards - for example, we can request "net/*" drivers to be built, and they will be built on a best-effort basis; that is, if the driver lacks a dependency, it will get ignored without any errors. For this script, a design decision has been made to handle internal driver dependencies (such as "net/ice" depending on "common/iavf") automatically to enhance user experience, until such time as the build system can do it better. However, the downside of this decision is that we need to handle dependencies between drivers for when user specifies wildcards on the command-line, which can be solved in three ways: * Not allow wildcards at all * Allow wildcards and always expand them * Allow wildcards and be smarter about handling them The first option is, IMO, inferior one: wildcards are convenient and quick to work with, so I would rather leave them as an option available to the user. The second options is nice, but it has a fundamental issue: when we expand very broad wildcards like "net/*", we will definitely cover a lot of drivers we do not have any dependencies for, but since we're now explicitly requesting them, the build will now error out if we requested something we didn't necessarily expect to be built. For this reason, I decided against this option. The third option is what I went with, with "smarter" being defined as follows:
[RFC PATCH v2 1/1] devtools: add vscode configuration generator
A lot of developers use Visual Studio Code as their primary IDE. This
script generates a configuration file for VSCode that sets up basic build
tasks, launch tasks, as well as C/C++ code analysis settings that will
take into account compile_commands.json that is automatically generated
by meson.
Files generated by script:
- .vscode/settings.json: stores variables needed by other files
- .vscode/tasks.json: defines build tasks
- .vscode/launch.json: defines launch tasks
- .vscode/c_cpp_properties.json: defines code analysis settings
The script uses a combination of globbing and meson file parsing to
discover available apps, examples, and drivers, and generates a
project-wide settings file, so that the user can later switch between
debug/release/etc. configurations while keeping their desired apps,
examples, and drivers, built by meson, and ensuring launch configurations
still work correctly whatever the configuration selected.
This script uses whiptail as TUI, which is expected to be universally
available as it is shipped by default on most major distributions.
However, the script is also designed to be scriptable and can be run
without user interaction, and have its configuration supplied from
command-line arguments.
Signed-off-by: Anatoly Burakov
---
Notes:
RFCv1 -> RFCv2:
- No longer disable apps and drivers if nothing was specified via command
line
or TUI, and warn user about things being built by default
- Generate app launch configuration by default for when no apps are selected
- Added paramters:
- --force to avoid overwriting existing config
- --common-conf to specify global meson flags applicable to all configs
- --gdbsudo/--no-gdbsudo to specify gdbsudo behavior
- Autodetect gdbsudo/gdb from UID
- Updated comments, error messages, fixed issues with user interaction
- Improved handling of wildcards and driver dependencies
- Fixed a few bugs in dependency detection due to incorrect parsing
- [Stephen] flake8 is happy
devtools/gen-vscode-config.py | 871 ++
1 file changed, 871 insertions(+)
create mode 100755 devtools/gen-vscode-config.py
diff --git a/devtools/gen-vscode-config.py b/devtools/gen-vscode-config.py
new file mode 100755
index 00..f0d6044c1b
--- /dev/null
+++ b/devtools/gen-vscode-config.py
@@ -0,0 +1,871 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2024 Intel Corporation
+#
+
+"""Visual Studio Code configuration generator script."""
+
+import os
+import json
+import argparse
+import fnmatch
+import shutil
+from typing import List, Dict, Tuple, Any
+from sys import exit as _exit, stderr
+from subprocess import run, CalledProcessError, PIPE
+from mesonbuild import mparser
+from mesonbuild.mesonlib import MesonException
+
+
+class DPDKBuildTask:
+"""A build task for DPDK"""
+
+def __init__(self, label: str, description: str, param: str):
+# label as it appears in build configuration
+self.label = label
+# description to be given in menu
+self.description = description
+# task-specific configuration parameters
+self.param = param
+
+def to_json_dict(self) -> Dict[str, Any]:
+"""Generate JSON dictionary for this task"""
+return {
+"label": f"Configure {self.label}",
+"detail": self.description,
+"type": "shell",
+"dependsOn": "Remove builddir",
+# take configuration from settings.json using config: namespace
+"command": f"meson setup ${{config:BUILDCONFIG}} " \
+ f"{self.param} ${{config:BUILDDIR}}",
+"problemMatcher": [],
+"group": "build"
+}
+
+
+class DPDKLaunchTask:
+"""A launch task for DPDK"""
+
+def __init__(self, label: str, exe: str, gdb_path: str):
+# label as it appears in launch configuration
+self.label = label
+# path to executable
+self.exe = exe
+self.gdb_path = gdb_path
+
+def to_json_dict(self) -> Dict[str, Any]:
+"""Generate JSON dictionary for this task"""
+return {
+"name": f"Run {self.label}",
+"type": "cppdbg",
+"request": "launch",
+# take configuration from settings.json using config: namespace
+"program": f"${{config:BUILDDIR}}/{self.exe}",
+"args": [],
+"stopAtEntry": False,
+"cwd": "${workspaceFolder}",
+"externalConsole": False,
+"preLaunchTask": "Build",
+"MIMode": "gdb",
+"miDebuggerPath": self.gdb_path,
+"setupCommands": [
+{
+"description": "Enable pretty-printing for gdb",
+"text": "-gdb-set print pretty on",
+"ignoreFailures": True
+}
+]
+}
+
+
+class VSCodeConfig:
+"""C
Re: [PATCH] examples/ipsec-secgw: revert fix SA salt endianness
On 29-Jul-24 1:57 PM, Vladimir Medvedkin wrote:
The previous commit swapped the bytes of SA salt which
led to incorrect work of the ipsec-secgw application.
This patch reverts the previous commit and changes
the type of the salt field in the ipsec_sa structure.
Fixes: e6bfd9676109 ("examples/ipsec-secgw: fix SA salt endianness")
Cc: shihong.w...@corigine.com
Cc: sta...@dpdk.org
Signed-off-by: Vladimir Medvedkin
---
Acked-by: Radu Nicolau
RE: [RFC] dmadev: add QoS capability
> From: Vamsi Attunuru [mailto:vattun...@marvell.com]
> Sent: Monday, 29 July 2024 13.56
>
> Some DMA controllers support QoS at HW command queue level to
> differentiate the performance on different HW queues based on
> the priority configured. Patch adds required fields in dmadev
> structures to get hardware supported priority levels and the
> provision to configure the priority from the applications.
Do we foresee anything more advanced than Strict Priority scheduling for DMA
anytime in the future?
If not, then consider calling this new capability Prioritization (CAPA_PRIO)
instead of Quality Of Service (CAPA_QOS). Then we don't need to add and
describe QoS parameters for a more advanced QoS scheduling algorithm (e.g. the
"weight" for weighted fair queueing).
>
> Signed-off-by: Vamsi Attunuru
> ---
> lib/dmadev/rte_dmadev.c | 10 ++
> lib/dmadev/rte_dmadev.h | 19 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 845727210f..9ff62efcb4 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -491,6 +491,16 @@ rte_dma_configure(int16_t dev_id, const struct
> rte_dma_conf *dev_conf)
> "Device %d configure too many vchans", dev_id);
> return -EINVAL;
> }
> + if (dev_conf->priority &&
- if (dev_conf->priority &&
+ if (dev_conf->priority != 0 &&
> + !(dev_info.dev_capa & RTE_DMA_CAPA_QOS)) {
> + RTE_DMA_LOG(ERR, "Device %d don't support QoS", dev_id);
> + return -EINVAL;
> + }
> + if (dev_conf->priority >= dev_info.nb_priorities) {
> + RTE_DMA_LOG(ERR,
> + "Device %d configure invalid priority", dev_id);
> + return -EINVAL;
> + }
> if (dev_conf->enable_silent &&
> !(dev_info.dev_capa & RTE_DMA_CAPA_SILENT)) {
> RTE_DMA_LOG(ERR, "Device %d don't support silent", dev_id);
> diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
> index 5474a5281d..08db8ead0a 100644
> --- a/lib/dmadev/rte_dmadev.h
> +++ b/lib/dmadev/rte_dmadev.h
> @@ -268,6 +268,16 @@ int16_t rte_dma_next_dev(int16_t start_dev_id);
> #define RTE_DMA_CAPA_OPS_COPY_SG RTE_BIT64(33)
> /** Support fill operation. */
> #define RTE_DMA_CAPA_OPS_FILLRTE_BIT64(34)
> +/** Support QoS at DMA HW channel level
> + *
> + * If device supports QoS then application could configure priority to the
> + * DMA HW channel using 'priority' field in struct rte_dma_conf. Number of
> + * supported prioirty levels will be known from 'nb_priorities' field in
> + * struct rte_dma_info.
> + * DMA devices which support QoS at HW channel level can advertise this
> + * capability.
> + */
> +#define RTE_DMA_CAPA_QOS RTE_BIT64(35)
> /**@}*/
>
> /**
> @@ -297,6 +307,8 @@ struct rte_dma_info {
> int16_t numa_node;
> /** Number of virtual DMA channel configured. */
> uint16_t nb_vchans;
> + /** Number of priority levels supported by DMA HW channel. */
> + uint16_t nb_priorities;
This value must be 0 or > 1, never 1. Please mention in the comment, e.g.:
/** Number of priority levels, if supported by DMA HW channel. 0 otherwise. */
Please add a test case to verify that the DMA device reports nb_priorities > 1
if it has CAPA_PRIO, and 0 if not.
Alternatively:
Assuming we don't foresee anything more advanced than Strict Priority...
Remove the CAPA_PRIO capability flag. Reading nb_priorities should suffice.
> };
>
> /**
> @@ -332,6 +344,13 @@ struct rte_dma_conf {
>* @see RTE_DMA_CAPA_SILENT
>*/
> bool enable_silent;
> + /* The prioirty of the DMA HW channel.
> + * This value cannot be greater than or equal to the field
> 'nb_priorities'
> + * of struct rte_dma_info which get from rte_dma_info_get().
> + * Among the values between '0' and 'nb_priorities - 1', lowest value
> + * indicates higher priority and vice-versa.
> + */
> + uint16_t priority;
> };
>
> /**
> --
> 2.25.1
Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator
On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: > A lot of developers use Visual Studio Code as their primary IDE. This > script generates a configuration file for VSCode that sets up basic build > tasks, launch tasks, as well as C/C++ code analysis settings that will > take into account compile_commands.json that is automatically generated > by meson. > > Files generated by script: > - .vscode/settings.json: stores variables needed by other files > - .vscode/tasks.json: defines build tasks > - .vscode/launch.json: defines launch tasks > - .vscode/c_cpp_properties.json: defines code analysis settings > > The script uses a combination of globbing and meson file parsing to > discover available apps, examples, and drivers, and generates a > project-wide settings file, so that the user can later switch between > debug/release/etc. configurations while keeping their desired apps, > examples, and drivers, built by meson, and ensuring launch configurations > still work correctly whatever the configuration selected. > > This script uses whiptail as TUI, which is expected to be universally > available as it is shipped by default on most major distributions. > However, the script is also designed to be scriptable and can be run > without user interaction, and have its configuration supplied from > command-line arguments. > > Signed-off-by: Anatoly Burakov > --- > Not sure where it would go - contributors guide probably - but I think this script could do with some docs, especially a quick-setup example on how to use. Having it in the docs will also make it more likely someone will use this. /Bruce
Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator
On 7/29/2024 3:14 PM, Bruce Richardson wrote: On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: A lot of developers use Visual Studio Code as their primary IDE. This script generates a configuration file for VSCode that sets up basic build tasks, launch tasks, as well as C/C++ code analysis settings that will take into account compile_commands.json that is automatically generated by meson. Files generated by script: - .vscode/settings.json: stores variables needed by other files - .vscode/tasks.json: defines build tasks - .vscode/launch.json: defines launch tasks - .vscode/c_cpp_properties.json: defines code analysis settings The script uses a combination of globbing and meson file parsing to discover available apps, examples, and drivers, and generates a project-wide settings file, so that the user can later switch between debug/release/etc. configurations while keeping their desired apps, examples, and drivers, built by meson, and ensuring launch configurations still work correctly whatever the configuration selected. This script uses whiptail as TUI, which is expected to be universally available as it is shipped by default on most major distributions. However, the script is also designed to be scriptable and can be run without user interaction, and have its configuration supplied from command-line arguments. Signed-off-by: Anatoly Burakov --- Not sure where it would go - contributors guide probably - but I think this script could do with some docs, especially a quick-setup example on how to use. Having it in the docs will also make it more likely someone will use this. /Bruce Yep, this is the next step :) I've left it until v1 to add docs. -- Thanks, Anatoly
Re: [RFC] dmadev: add QoS capability
On Mon, Jul 29, 2024 at 03:14:55PM +0200, Morten Brørup wrote: > > From: Vamsi Attunuru [mailto:vattun...@marvell.com] > > Sent: Monday, 29 July 2024 13.56 > > > > Some DMA controllers support QoS at HW command queue level to > > differentiate the performance on different HW queues based on > > the priority configured. Patch adds required fields in dmadev > > structures to get hardware supported priority levels and the > > provision to configure the priority from the applications. > > Do we foresee anything more advanced than Strict Priority scheduling for DMA > anytime in the future? > > If not, then consider calling this new capability Prioritization (CAPA_PRIO) > instead of Quality Of Service (CAPA_QOS). Then we don't need to add and > describe QoS parameters for a more advanced QoS scheduling algorithm (e.g. > the "weight" for weighted fair queueing). > There could be more than just regular prioritization settings involved, so I think it's best to leave some options open. Even with just a "prioritization" setting, it could be used as a weighting vs strict priority. Question is whether in such a case - of a single-value number for high vs low priority - it's better to explicitly separate out a weight priority vs a strict priority, or give a simpler interface by allowing just a single number value. /Bruce
Re: [V1] doc: announce deprecation of flow item VXLAN-GPE
On Mon, Jul 29, 2024 at 1:48 AM Thomas Monjalon wrote: > > 26/07/2024 13:31, Ferruh Yigit: > > On 7/26/2024 9:51 AM, Gavin Li wrote: > > > Adding the deprecation notice as reminder for removing > > > RTE_FLOW_ITEM_TYPE_VXLAN_GPE and its related structures, > > > eg. rte_vxlan_gpe_hdr, rte_flow_item_vxlan_gpe, etc. > > > > > > The proposed time of the removal is DPDK release 25.11. > > > > > > Signed-off-by: Gavin Li > > > --- > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > + * ethdev,net: The flow item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE`` is > > > replaced with ``RTE_FLOW_ITEM_TYPE_VXLAN``. > > > + The struct ``rte_flow_item_vxlan_gpe``, its mask > > > ``rte_flow_item_vxlan_gpe_mask`` are replaced with > > > + ``rte_flow_item_vxlan and its mask`` and its mask > > > ``rte_flow_item_vxlan_mask``. > > > + The item ``RTE_FLOW_ITEM_TYPE_VXLAN_GPE``, the struct > > > ``rte_flow_item_vxlan_gpe``, its mask ``rte_flow_item_vxlan_gpe_mask``, > > > + and the header struct ``rte_vxlan_gpe_hdr`` with the macro > > > ``RTE_ETHER_VXLAN_GPE_HLEN`` > > > + will be removed in DPDK 25.11. > > > > Acked-by: Ferruh Yigit > > Acked-by: Thomas Monjalon Acked-by: Ajit Khaparde > > smime.p7s Description: S/MIME Cryptographic Signature
RE: [PATCH v6 2/3] eventdev: add support for independent enqueue
> On 2024-07-11 21:54, Abdullah Sevincer wrote: > > This commit adds support for independent enqueue feature and updates > > Event Device and PMD feature list. > > > > A new capability RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ is introduced to > > support independent enqueue to support PMD to enqueue in any order > > even the underlined hardware device needs enqueues in a strict dequeue > > order. > > > > To use this capability applications need to set flag > > RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ during port setup only if the > > capability RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ exists. > > > > Signed-off-by: Abdullah Sevincer > > --- > > doc/guides/eventdevs/features/default.ini | 1 + > > doc/guides/eventdevs/features/dlb2.ini| 1 + > > doc/guides/rel_notes/release_24_07.rst| 5 > > lib/eventdev/rte_eventdev.h | 36 +++ > > 4 files changed, 43 insertions(+) > > > > diff --git a/doc/guides/eventdevs/features/default.ini > > b/doc/guides/eventdevs/features/default.ini > > index 1cc4303fe5..7c4ee99238 100644 > > --- a/doc/guides/eventdevs/features/default.ini > > +++ b/doc/guides/eventdevs/features/default.ini > > @@ -22,6 +22,7 @@ carry_flow_id = > > maintenance_free = > > runtime_queue_attr = > > profile_links = > > +independent_enq= > > > > ; > > ; Features of a default Ethernet Rx adapter. > > diff --git a/doc/guides/eventdevs/features/dlb2.ini > > b/doc/guides/eventdevs/features/dlb2.ini > > index 7b80286927..c7193b47c1 100644 > > --- a/doc/guides/eventdevs/features/dlb2.ini > > +++ b/doc/guides/eventdevs/features/dlb2.ini > > @@ -15,6 +15,7 @@ implicit_release_disable = Y > > runtime_port_link = Y > > multiple_queue_port= Y > > maintenance_free = Y > > +independent_enq= Y > > > > [Eth Rx adapter Features] > > > > diff --git a/doc/guides/rel_notes/release_24_07.rst > > b/doc/guides/rel_notes/release_24_07.rst > > index 76a79093d1..d8564b19f0 100644 > > --- a/doc/guides/rel_notes/release_24_07.rst > > +++ b/doc/guides/rel_notes/release_24_07.rst > > @@ -162,6 +162,11 @@ New Features > > ``RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ`` to enable the feature if the > capability > > ``RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ`` exists. > > > > +* **Updated Event Device Library for independent enqueue feature** > > + > > + * Added support for independent enqueue feature. Updated Event Device > and > > +PMD feature list. > > + > > > > Removed Items > > - > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > > index 08e5f9320b..462fc3f18f 100644 > > --- a/lib/eventdev/rte_eventdev.h > > +++ b/lib/eventdev/rte_eventdev.h > > @@ -446,6 +446,30 @@ struct rte_event; > >* @see RTE_SCHED_TYPE_PARALLEL > >*/ > > > > +#define RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ (1ULL << 16) /**< Event > > +device is capable of independent enqueue. > > + * A new capability, RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ, will indicate > > +that Eventdev > > + * supports the enqueue in any order or specifically in a different > > +order than the > > + * dequeue. Eventdev PMD can either transmit events in the changed > > +order in which > > + * they are enqueued or restore the original order before sending > > +them to the > > + * underlying hardware device. A flag is provided during the port > > +configuration to > > + * inform Eventdev PMD that the application intends to use an > > +independent enqueue > > + * order on a particular port. Note that this capability only matters > > +for Eventdevs > > + * supporting burst mode. > > + * > > + * To Inform PMD that the application plans to use independent > > +enqueue order on a port > > + * this code example can be used: > > + * > > + * if (capability & RTE_EVENT_DEV_CAP_INDEPENDENT_ENQ) > > + * port_config = port_config | > RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ; > > + * > > + * When an implicit release is enabled on a port, Eventdev PMD will > > +also handle > > + * the insertion of RELEASE events in place of dropped events. The > > +order restoration > > "The independent enqueue feature only applies to /../" maybe? > > > + * only applies to FORWARD and RELEASE events. New events > > + (op=RTE_EVENT_OP_NEW) will > > + * be transmitted in the order the application enqueues them. New > > + events do not > > + * maintain any order relative to FORWARD/RELEASE events. > > Is FORWARD<->NEW relaxed ordering specific to ports which has enabled > RTE_EVENT_PORT_CFG_INDEPENDENT_ENQ? Yes. Relaxed ordering only applies to ports with independent enqueue enabled. We will update the documentation. > If not, that information should probably be somewhere else. > > Either way, > Reviewed-by: Mattias Rönnblom > > > + */ > > + > > /* Event device priority levels */ > > #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0 > > /**< Highest priority level for events and queues. > > @@ -1072,6 +1096,18 @@ rte_event_queue_a
RE: [RFC] dmadev: add QoS capability
> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Monday, 29 July 2024 15.27 > > On Mon, Jul 29, 2024 at 03:14:55PM +0200, Morten Brørup wrote: > > > From: Vamsi Attunuru [mailto:vattun...@marvell.com] > > > Sent: Monday, 29 July 2024 13.56 > > > > > > Some DMA controllers support QoS at HW command queue level to > > > differentiate the performance on different HW queues based on > > > the priority configured. Patch adds required fields in dmadev > > > structures to get hardware supported priority levels and the > > > provision to configure the priority from the applications. > > > > Do we foresee anything more advanced than Strict Priority scheduling for DMA > anytime in the future? > > > > If not, then consider calling this new capability Prioritization (CAPA_PRIO) > instead of Quality Of Service (CAPA_QOS). Then we don't need to add and > describe QoS parameters for a more advanced QoS scheduling algorithm (e.g. the > "weight" for weighted fair queueing). > > > > There could be more than just regular prioritization settings involved, so > I think it's best to leave some options open. Even with just a > "prioritization" setting, it could be used as a weighting vs strict priority. > Question is whether in such a case - of a single-value number for high vs > low priority - it's better to explicitly separate out a weight priority vs > a strict priority, or give a simpler interface by allowing just a single > number value. If we leave some options open, we need to define the API for them. Let's not go overboard with this, but stay within what could be realistic for a DMA engine. Remember, the API needs to be cross-platform, so simply replacing the "Priority" parameter with a "QoS Class ID" also requires adding configuration parameters to map each QoS Class ID to a generically defined behavior (e.g. priority, weight). @Vamsi, how many priority levels does your DMA hardware support?
[PATCH] net/mlx5/hws: fix the valid bit of E-Switch owner
The 'eswitch_owner_vhca_id_valid' only depends on the
'merged_eswitch' capability. And it should be set for all
vport actions.
Fixes: ac8415cfe760 ("net/mlx5/hws: set E-Switch owner VHC ID valid")
Cc: ere...@nvidia.com
Signed-off-by: Bing Zhao
Reviewed-by: Alex Vesker
---
drivers/net/mlx5/hws/mlx5dr_action.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c
b/drivers/net/mlx5/hws/mlx5dr_action.c
index 8f6be37818..3fceb96de2 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -826,7 +826,7 @@ mlx5dr_action_fixup_stc_attr(struct mlx5dr_context *ctx,
fixup_stc_attr->vport.vport_num = 0;
fixup_stc_attr->vport.esw_owner_vhca_id =
stc_attr->vport.esw_owner_vhca_id;
fixup_stc_attr->vport.eswitch_owner_vhca_id_valid =
- ctx->caps->merged_eswitch;
+ stc_attr->vport.eswitch_owner_vhca_id_valid;
}
use_fixup = true;
break;
@@ -1057,6 +1057,7 @@ static void mlx5dr_action_fill_stc_attr(struct
mlx5dr_action *action,
attr->action_type = MLX5_IFC_STC_ACTION_TYPE_JUMP_TO_VPORT;
attr->vport.vport_num = action->vport.vport_num;
attr->vport.esw_owner_vhca_id = action->vport.esw_owner_vhca_id;
+ attr->vport.eswitch_owner_vhca_id_valid =
action->ctx->caps->merged_eswitch;
break;
case MLX5DR_ACTION_TYP_POP_VLAN:
attr->action_type = MLX5_IFC_STC_ACTION_TYPE_REMOVE_WORDS;
--
2.34.1
Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator
On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: > A lot of developers use Visual Studio Code as their primary IDE. This > script generates a configuration file for VSCode that sets up basic build > tasks, launch tasks, as well as C/C++ code analysis settings that will > take into account compile_commands.json that is automatically generated > by meson. > > Files generated by script: > - .vscode/settings.json: stores variables needed by other files > - .vscode/tasks.json: defines build tasks > - .vscode/launch.json: defines launch tasks > - .vscode/c_cpp_properties.json: defines code analysis settings > > The script uses a combination of globbing and meson file parsing to > discover available apps, examples, and drivers, and generates a > project-wide settings file, so that the user can later switch between > debug/release/etc. configurations while keeping their desired apps, > examples, and drivers, built by meson, and ensuring launch configurations > still work correctly whatever the configuration selected. > > This script uses whiptail as TUI, which is expected to be universally > available as it is shipped by default on most major distributions. > However, the script is also designed to be scriptable and can be run > without user interaction, and have its configuration supplied from > command-line arguments. > > Signed-off-by: Anatoly Burakov > --- > Just was trying this out, nice script, thanks. Initial thoughts concerning the build directory: - the script doesn't actually create the build directory, so there is no guarantee that the build directory created will have the same parameters as that specified in the script run. I'd suggest in the case where the user runs the script and specifies build settings, that the build directory is then configured using those settings. - On the other hand, when the build directory already exists - I think the script should pull all settings from there, rather than prompting the user. - I'm not sure I like the idea for reconfiguring of just removing the build directory and doing a whole meson setup command all over again. This seems excessive and also removes the possibility of the user having made changes in config to the build dir without re-running the whole config script. For example, having tweaked the LTO setting, or the instruction_set_isa_setting. Rather than deleting it and running meson setup, it would be better to use "meson configure" to adjust the one required setting and let ninja figure out how to propagate that change. That saves the script from having to track all meson parameters itself. - Finally, and semi-related, this script assumes that the user does everything in a single build directory. Just something to consider, but my own workflow till now has tended to keep multiple build directories around, generally a "build" directory, which is either release or debugoptimized type, and a separate "build-debug" directory + occasionally others for build testing. When doing incremental builds, the time taken to do two builds following a change is a lot less noticable than the time taken for periodic switches of a single build directory between debug and release mode. Final thoughts on usability: - Please don't write gdbsudo to /usr/local/bin without asking the user first. Instead I think it should default to $HOME/.local/bin, but with a prompt for the user to specify a path. - While I realise your primary concern here is an interactive script, I'd tend towards requiring a cmdline arg to run in interactive mode and instead printing the help usage when run without parameters. Just a personal preference on my part though. /Bruce
RE: [RFC] dmadev: add QoS capability
>-Original Message- >From: Morten Brørup >Sent: Monday, July 29, 2024 7:23 PM >To: Bruce Richardson >Cc: Vamsi Krishna Attunuru ; >fengcheng...@huawei.com; dev@dpdk.org; kevin.la...@intel.com; Jerin >Jacob ; Anoob Joseph >Subject: [EXTERNAL] RE: [RFC] dmadev: add QoS capability > >> From: Bruce Richardson [mailto: bruce. richardson@ intel. com] > Sent: >> Monday, 29 July 2024 15. 27 > > On Mon, Jul 29, 2024 at 03: 14: 55PM >> +0200, Morten Brørup wrote: > > > From: Vamsi Attunuru [mailto: >> vattunuru@ marvell. com] > >> From: Bruce Richardson [mailto:bruce.richard...@intel.com] >> Sent: Monday, 29 July 2024 15.27 >> >> On Mon, Jul 29, 2024 at 03:14:55PM +0200, Morten Brørup wrote: >> > > From: Vamsi Attunuru [mailto:vattun...@marvell.com] >> > > Sent: Monday, 29 July 2024 13.56 >> > > >> > > Some DMA controllers support QoS at HW command queue level to >> > > differentiate the performance on different HW queues based on the >> > > priority configured. Patch adds required fields in dmadev >> > > structures to get hardware supported priority levels and the >> > > provision to configure the priority from the applications. >> > >> > Do we foresee anything more advanced than Strict Priority scheduling >> > for DMA >> anytime in the future? >> > >> > If not, then consider calling this new capability Prioritization >> > (CAPA_PRIO) >> instead of Quality Of Service (CAPA_QOS). Then we don't need to add >> and describe QoS parameters for a more advanced QoS scheduling >> algorithm (e.g. the "weight" for weighted fair queueing). >> > >> >> There could be more than just regular prioritization settings >> involved, so I think it's best to leave some options open. Even with >> just a "prioritization" setting, it could be used as a weighting vs strict >> priority. >> Question is whether in such a case - of a single-value number for high >> vs low priority - it's better to explicitly separate out a weight >> priority vs a strict priority, or give a simpler interface by allowing >> just a single number value. > >If we leave some options open, we need to define the API for them. >Let's not go overboard with this, but stay within what could be realistic for a >DMA engine. > >Remember, the API needs to be cross-platform, so simply replacing the >"Priority" parameter with a "QoS Class ID" also requires adding configuration >parameters to map each QoS Class ID to a generically defined behavior (e.g. >priority, weight). > >@Vamsi, how many priority levels does your DMA hardware support? Hi Morten & Bruce, thanks for the comments. Our DMA HW supports 4 priorities. Yes, as Bruce pointed, we can have options open to support both(weighted & strict). Let me get back on this that could be sensible for DMA kind of hardware. Regards Vamsi
Re: [PATCH] doc: announce dmadev new capability addition
On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru wrote: > > Announce addition of new capability flag and fields in The new capability flag won't break ABI. We can mention only fields update rte_dma_info and rte_dma_conf structures. Another option is new set APIs for priority enablement. The downside is more code. All, opinions? > rte_dma_info and rte_dma_conf structures. > > Signed-off-by: Vamsi Attunuru > --- > RFC: > https://patchwork.dpdk.org/project/dpdk/patch/20240729115558.263574-1-vattun...@marvell.com/ > > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 6948641ff6..05d28473c0 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -147,3 +147,8 @@ Deprecation Notices >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. > + > +* dmadev: A new flag ``RTE_DMA_CAPA_QOS`` will be introduced to advertise > + dma device's QoS capability. Also new fields will be added in > ``rte_dma_info`` > + and ``rte_dma_conf`` structures to get device supported priority levels > + and to configure the required priority level. > -- > 2.25.1 >
RE: [PATCH] net/mlx5/hws: fix the valid bit of E-Switch owner
> -Original Message-
> From: Bing Zhao
> Sent: Monday, July 29, 2024 16:07
> To: Dariusz Sosnowski ; Slava Ovsiienko
> ; dev@dpdk.org; Raslan Darawsheh
>
> Cc: Ori Kam ; Suanming Mou ;
> Matan Azrad ; Erez Shitrit ; Alex
> Vesker
> Subject: [PATCH] net/mlx5/hws: fix the valid bit of E-Switch owner
>
> The 'eswitch_owner_vhca_id_valid' only depends on the 'merged_eswitch'
> capability. And it should be set for all vport actions.
>
> Fixes: ac8415cfe760 ("net/mlx5/hws: set E-Switch owner VHC ID valid")
> Cc: ere...@nvidia.com
>
> Signed-off-by: Bing Zhao
> Reviewed-by: Alex Vesker
Acked-by: Dariusz Sosnowski
Best regards,
Dariusz Sosnowski
Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator
On 7/29/2024 4:30 PM, Bruce Richardson wrote: On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: A lot of developers use Visual Studio Code as their primary IDE. This script generates a configuration file for VSCode that sets up basic build tasks, launch tasks, as well as C/C++ code analysis settings that will take into account compile_commands.json that is automatically generated by meson. Files generated by script: - .vscode/settings.json: stores variables needed by other files - .vscode/tasks.json: defines build tasks - .vscode/launch.json: defines launch tasks - .vscode/c_cpp_properties.json: defines code analysis settings The script uses a combination of globbing and meson file parsing to discover available apps, examples, and drivers, and generates a project-wide settings file, so that the user can later switch between debug/release/etc. configurations while keeping their desired apps, examples, and drivers, built by meson, and ensuring launch configurations still work correctly whatever the configuration selected. This script uses whiptail as TUI, which is expected to be universally available as it is shipped by default on most major distributions. However, the script is also designed to be scriptable and can be run without user interaction, and have its configuration supplied from command-line arguments. Signed-off-by: Anatoly Burakov --- Just was trying this out, nice script, thanks. Thanks for the feedback! Comments below. Initial thoughts concerning the build directory: - the script doesn't actually create the build directory, so there is no guarantee that the build directory created will have the same parameters as that specified in the script run. I'd suggest in the case where the user runs the script and specifies build settings, that the build directory is then configured using those settings. I'm not sure I follow. The script creates a command for VSCode to create a build directory using configuration the user has supplied at script's run time. The directory is not created by the script, that is the job of meson build system. This script is merely codifying commands for meson to do that, with the expectation that the user is familiar with VSCode workflow and will go straight to build commands anyway, and will pick one of them. Are you suggesting running `meson setup` right after? Assuming we do that, it would actually then be possible to adjust launch tasks to only include *actual* built apps/examples (as well as infer things like platform, compiler etc.), as that's one weakness of my current "flying blind" approach, so I wouldn't be opposed to adding an extra step here, just want to make sure I understand what you're saying correctly. - On the other hand, when the build directory already exists - I think the script should pull all settings from there, rather than prompting the user. That can be done, however, my own workflow has been that I do not ever keep build directories inside my source directory, so it would not be possible to pick up directories anywhere but the source directory. I also think from the point of view of the script it would be easier to start from known quantities rather than guess what user was trying to do from current configuration, but I guess a few common-sense heuristics should suffice for most use cases, such as e.g. inferring debug builds. - I'm not sure I like the idea for reconfiguring of just removing the build directory and doing a whole meson setup command all over again. This seems excessive and also removes the possibility of the user having made changes in config to the build dir without re-running the whole config script. For example, having tweaked the LTO setting, or the instruction_set_isa_setting. Rather than deleting it and running meson setup, it would be better to use "meson configure" to adjust the one required setting and let ninja figure out how to propagate that change. That saves the script from having to track all meson parameters itself. Last I checked, meson doesn't have a command that would "setup or configure existing" a directory, it's either "set up new one" or "configure existing one". I guess we could set up a fallback of "configure || setup". - Finally, and semi-related, this script assumes that the user does everything in a single build directory. Just something to consider, but my own workflow till now has tended to keep multiple build directories around, generally a "build" directory, which is either release or debugoptimized type, and a separate "build-debug" directory + occasionally others for build testing. When doing incremental builds, the time taken to do two builds following a change is a lot less noticable than the time taken for periodic switches of a single build directory between debug and release mode. The problem with that approach is the launch tasks, because a launch
Re: [PATCH] net/mlx5/hws: fix the valid bit of E-Switch owner
29/07/2024 17:54, Dariusz Sosnowski:
> >
> > The 'eswitch_owner_vhca_id_valid' only depends on the 'merged_eswitch'
> > capability. And it should be set for all vport actions.
> >
> > Fixes: ac8415cfe760 ("net/mlx5/hws: set E-Switch owner VHC ID valid")
> > Cc: ere...@nvidia.com
> >
> > Signed-off-by: Bing Zhao
> > Reviewed-by: Alex Vesker
>
> Acked-by: Dariusz Sosnowski
Applied, thanks.
Re: [PATCH] test: fix 32 bit overflow in pcapng test
18/07/2024 21:07, Luca Boccassi: > On Thu, 18 Jul 2024 at 18:43, Stephen Hemminger > wrote: > > > > The conversion from seconds to nanoseconds in the pcapng test > > would overflow on 32 bit platforms leading to this test failing. > > > > Reported-by: Luca Boccassi > > Signed-off-by: Stephen Hemminger > > --- > > - ns = h->ts.tv_sec * NS_PER_S + h->ts.tv_usec; > > + ns = (uint64_t)h->ts.tv_sec * NS_PER_S + h->ts.tv_usec; > > Thanks this fixes the issue, the build is now green > > Tested-by: Luca Boccassi Applied, thanks.
[v24.11 PATCH v1] net/sfc: allow for use of indirect counter in tunnel offload
Support the use of indirect counters in so-called SWITCH
rules (second stage lookup and steering after supposed
decapsulation) in tunnel offload. An indirect counter
can either come instead of an inline counter or, when
the latter is a conntrack-assisted counter, follow it.
Signed-off-by: Ivan Malov
Reviewed-by: Andy Moreton
---
drivers/net/sfc/sfc_mae.c | 66 ---
drivers/net/sfc/sfc_mae.h | 1 +
2 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/drivers/net/sfc/sfc_mae.c b/drivers/net/sfc/sfc_mae.c
index 60ff6d2181..ebca402ce4 100644
--- a/drivers/net/sfc/sfc_mae.c
+++ b/drivers/net/sfc/sfc_mae.c
@@ -972,6 +972,9 @@ sfc_mae_counter_del(struct sfc_adapter *sa, struct
sfc_mae_counter *counter)
--(counter->refcnt);
+ if (counter->refcnt == 1)
+ counter->ft_switch_hit_counter = NULL;
+
if (counter->refcnt != 0)
return;
@@ -4517,21 +4520,23 @@ sfc_mae_rule_parse_action_indirect(struct sfc_adapter
*sa, bool replayable_only,
return EEXIST;
}
- if (ft_rule_type != SFC_FT_RULE_NONE) {
- return rte_flow_error_set(error, EINVAL,
+ if (ft_rule_type != SFC_FT_RULE_SWITCH &&
+ entry->counter->ft_switch_hit_counter !=
NULL) {
+ return rte_flow_error_set(error, EBUSY,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
- "cannot use indirect count action in
tunnel model");
+ "cannot use requested indirect
counter as it is in use by incompatible offload");
}
SFC_ASSERT(ctx->counter == NULL);
rc =
efx_mae_action_set_populate_count(ctx->spec);
- if (rc != 0) {
+ if (rc != 0 && !ctx->counter_implicit) {
return rte_flow_error_set(error, rc,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
"failed to add COUNT to MAE action
set");
}
+ ctx->counter_implicit = false;
ctx->counter = entry->counter;
++(ctx->counter->refcnt);
break;
@@ -5237,7 +5242,7 @@ sfc_mae_rule_parse_actions(struct sfc_adapter *sa,
goto fail_action_set_spec_init;
if (spec_mae->ft_rule_type == SFC_FT_RULE_SWITCH) {
- bool have_user_action_count = false;
+ bool have_inline_action_count = false;
/* TUNNEL rules don't decapsulate packets. SWITCH rules do. */
rc = efx_mae_action_set_populate_decap(ctx->spec);
@@ -5247,15 +5252,15 @@ sfc_mae_rule_parse_actions(struct sfc_adapter *sa,
for (action = actions;
action->type != RTE_FLOW_ACTION_TYPE_END; ++action) {
if (action->type == RTE_FLOW_ACTION_TYPE_COUNT) {
- have_user_action_count = true;
+ have_inline_action_count = true;
break;
}
}
- if (!have_user_action_count &&
+ if (!have_inline_action_count &&
sfc_mae_counter_stream_enabled(sa)) {
/*
-* The user opted not to use action COUNT in this rule,
+* The user might have opted not to have a counter here,
* but the counter should be enabled implicitly because
* packets hitting this rule contribute to the tunnel's
* total number of hits. See sfc_mae_counter_get().
@@ -5264,9 +5269,19 @@ sfc_mae_rule_parse_actions(struct sfc_adapter *sa,
if (rc != 0)
goto fail_enforce_ft_count;
- rc = sfc_mae_counter_add(sa, NULL, &ctx->counter);
- if (rc != 0)
- goto fail_enforce_ft_count;
+ /*
+* An action of type COUNT may come inlined (see above)
+* or via a shareable handle (enclosed by an action of
+* type INDIRECT). The latter is expensive to resolve
+* here. For now assume an implicit counter is needed.
+*
+* But if the flow does come with an indirect counter,
+* sfc_mae_rule_parse_action_indirect() will t
Re: [RFC PATCH v2 1/1] devtools: add vscode configuration generator
On Mon, Jul 29, 2024 at 06:16:48PM +0200, Burakov, Anatoly wrote: > On 7/29/2024 4:30 PM, Bruce Richardson wrote: > > On Mon, Jul 29, 2024 at 02:05:52PM +0100, Anatoly Burakov wrote: > > > A lot of developers use Visual Studio Code as their primary IDE. This > > > script generates a configuration file for VSCode that sets up basic build > > > tasks, launch tasks, as well as C/C++ code analysis settings that will > > > take into account compile_commands.json that is automatically generated > > > by meson. > > > > > > Files generated by script: > > > - .vscode/settings.json: stores variables needed by other files > > > - .vscode/tasks.json: defines build tasks > > > - .vscode/launch.json: defines launch tasks > > > - .vscode/c_cpp_properties.json: defines code analysis settings > > > > > > The script uses a combination of globbing and meson file parsing to > > > discover available apps, examples, and drivers, and generates a > > > project-wide settings file, so that the user can later switch between > > > debug/release/etc. configurations while keeping their desired apps, > > > examples, and drivers, built by meson, and ensuring launch configurations > > > still work correctly whatever the configuration selected. > > > > > > This script uses whiptail as TUI, which is expected to be universally > > > available as it is shipped by default on most major distributions. > > > However, the script is also designed to be scriptable and can be run > > > without user interaction, and have its configuration supplied from > > > command-line arguments. > > > > > > Signed-off-by: Anatoly Burakov > > > --- > > > > > Just was trying this out, nice script, thanks. > > Thanks for the feedback! Comments below. > > > > > Initial thoughts concerning the build directory: > > - the script doesn't actually create the build directory, so there is no > >guarantee that the build directory created will have the same parameters > >as that specified in the script run. I'd suggest in the case where the > >user runs the script and specifies build settings, that the build > >directory is then configured using those settings. > > I'm not sure I follow. > > The script creates a command for VSCode to create a build directory using > configuration the user has supplied at script's run time. The directory is > not created by the script, that is the job of meson build system. This > script is merely codifying commands for meson to do that, with the > expectation that the user is familiar with VSCode workflow and will go > straight to build commands anyway, and will pick one of them. Are you > suggesting running `meson setup` right after? > Yes, that is what I was thinking, based on the assumption that running "meson setup" should be a once-only task. I suppose overall it's a different workflow to what you have - where you run meson setup repeatedly each time you change a build type. My thinking for the approach to take here is that your script firstly asks for a build directory, and then: * if build-dir exists, pull settings you need from there, such as build type and the apps being built. * if not existing, ask for config settings as you do now, and then run meson setup to create the build dir. Thereafter, the source for all build settings is not in vscode, but in meson, and you just use "meson configure" from vscode to tweak whatever needs tweaking, without affecting any other settings. Since you don't affect any other settings there is no need to record what they should be. > Assuming we do that, it would actually then be possible to adjust launch > tasks to only include *actual* built apps/examples (as well as infer things > like platform, compiler etc.), as that's one weakness of my current "flying > blind" approach, so I wouldn't be opposed to adding an extra step here, just > want to make sure I understand what you're saying correctly. > > > > > - On the other hand, when the build directory already exists - I think the > >script should pull all settings from there, rather than prompting the > >user. > > > > That can be done, however, my own workflow has been that I do not ever keep > build directories inside my source directory, so it would not be possible to > pick up directories anywhere but the source directory. > Why is that, and how does it work now, for e.g. getting the compile_commands.json file from your build folder? > I also think from the point of view of the script it would be easier to > start from known quantities rather than guess what user was trying to do > from current configuration, but I guess a few common-sense heuristics should > suffice for most use cases, such as e.g. inferring debug builds. > What you need depends on whether you want to keep running "meson setup" - which means you need to track all settings - or want to use "meson configure" where you don't really need to track much at all. > > - I'm not sure I like the idea for reconfiguring of just rem
Regarding port numbers assigned by DPDK for PCI devices
Hi, I have 4 ethernet interfaces available as PCI devices. The PCI addresses are known. When I start my DPDK application, it starts up properly and assigns the port numbers to them as 0, 1, 2, 3 expectedly. However, is there a way I can force that a particular PCI address should be identified as port 0 by DPDK, another one as port 1 and so forth ? Does passing the arguments like -a -a to rte_eal_init ensure that, or is there any other way, or is there no way ? I am on 24.03 Regards -Prashant
Re: [PATCH v6 0/3] Improve interactive shell output gathering and logging
26/07/2024 13:01, Juraj Linkeš:
> For series:
> Reviewed-by: Juraj Linkeš
>
> On 24. 7. 2024 20:39, jspew...@iol.unh.edu wrote:
> > From: Jeremy Spewock
> >
> > v6:
> > * Fix error catch for retries. This series changed the error that
> > is thrown in the case of a timeout, but it was originally overlooked
> > that the context manager patch added a catch that is looking for the
> > old timeout error. This version fixes the patch by adjusting the
> > error that is expected in the context manager patch to match what
> > this series changes it to.
> >
>
> Here's the diff for anyone interested:
> diff --git
> a/dts/framework/remote_session/single_active_interactive_shell.py
> b/dts/framework/remote_session/single_active_interactive_shell.py
> index 701d0c..77a4dcefdf 100644
> --- a/dts/framework/remote_session/single_active_interactive_shell.py
> +++ b/dts/framework/remote_session/single_active_interactive_shell.py
> @@ -150,7 +150,7 @@ def _start_application(self) -> None:
> try:
> self.send_command(start_command)
> break
> -except TimeoutError:
> +except InteractiveSSHTimeoutError:
> self._logger.info(
> f"Interactive shell failed to start (attempt
> {attempt+1} out of "
> f"{self._init_attempts})"
>
> self.send_command raises InteractiveSSHTimeoutError (and not
> TimeoutError) which is why we needed this change.
>
> > Jeremy Spewock (3):
> >dts: Improve output gathering in interactive shells
> >dts: Add missing docstring from XML-RPC server
> >dts: Improve logging for interactive shells
Applied, thanks.
RE: [PATCH] doc: announce dmadev new capability addition
> From: Jerin Jacob [mailto:jerinjac...@gmail.com] > Sent: Monday, 29 July 2024 17.20 > > On Mon, Jul 29, 2024 at 6:19 PM Vamsi Attunuru > wrote: > > > > Announce addition of new capability flag and fields in > > rte_dma_info and rte_dma_conf structures. > > The new capability flag won't break ABI. We can mention only fields > update rte_dma_info and rte_dma_conf structures. > > Another option is new set APIs for priority enablement. The downside > is more code. All, opinions? I think that this feature should be simple enough to expand the rte_dma_info and rte_dma_conf structures with a few new fields, rather than adding a new set of APIs for it. It seems to become 1-level weighted priority scheduling of a few QoS classes, not hierarchical or anything complex enough to justify a new set of APIs. Just a simple array of per-class properties. The max possible number of QoS classes (i.e. the array size) should be build time configurable. Considering Marvell hardware, it seems 4 would be a good default.
Re: [PATCH 1/2] app/proc-info: add memory heap dump
02/07/2024 15:14, Gagandeep Singh:
> --- a/app/proc-info/main.c
> +++ b/app/proc-info/main.c
> @@ -637,6 +638,10 @@ meminfo_display(void)
> rte_memzone_dump(stdout);
> printf("-- END_MEMORY_ZONES ---\n");
>
> + printf(" HEAP DUMP -\n");
Should we add "MALLOC"?
With underscores for consistency?
> + rte_malloc_dump_heaps(stdout);
> + printf("-- END_HEAP_DUMP ---\n");
> +
> printf("- TAIL_QUEUES -\n");
> rte_dump_tailq(stdout);
> printf("-- END_TAIL_QUEUES \n");
>
Re: [PATCH] examples/ipsec-secgw: revert fix SA salt endianness
29/07/2024 15:13, Radu Nicolau:
>
> On 29-Jul-24 1:57 PM, Vladimir Medvedkin wrote:
> > The previous commit swapped the bytes of SA salt which
> > led to incorrect work of the ipsec-secgw application.
> > This patch reverts the previous commit and changes
> > the type of the salt field in the ipsec_sa structure.
> >
> > Fixes: e6bfd9676109 ("examples/ipsec-secgw: fix SA salt endianness")
> > Cc: shihong.w...@corigine.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Vladimir Medvedkin
>
> Acked-by: Radu Nicolau
Applied, thanks.
Re: Regarding port numbers assigned by DPDK for PCI devices
2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya: > Hi, > > I have 4 ethernet interfaces available as PCI devices. > The PCI addresses are known. > When I start my DPDK application, it starts up properly and assigns the > port numbers to them as 0, 1, 2, 3 expectedly. > > However, is there a way I can force that a particular PCI address should be > identified as port 0 by DPDK, another one as port 1 and so forth ? > Does passing the arguments like -a -a to rte_eal_init > ensure that, or is there any other way, or is there no way ? > > I am on 24.03 > > Regards > -Prashant Hi, Why do you need specific port numbers assigned to devices? If you're going to use devices for different purposes, you'd better have an application-level configuration to specify PCI addresses to use for each purpose. Iterate devices to match the address and find the port number. It is also possible to disable automatic probing with "-a 0:0.0", then to use rte_dev_probe() + rte_dev_event_callback_register() to add devices and to get their port numbers. However, this API, strictly speaking, does not guarantee that the numbers will be assigned sequentially. One advantage of using hot-plug is that you can build devargs from within the application (or from configuration). Refer to "rte_dev.h" in any case. Multiple "-a" don't work the way you've described.
[DPDK/DTS Bug 1505] Port over Ethertype configuration test suite to new DTS.
https://bugs.dpdk.org/show_bug.cgi?id=1505 Bug ID: 1505 Summary: Port over Ethertype configuration test suite to new DTS. Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: DTS Assignee: dev@dpdk.org Reporter: npra...@iol.unh.edu CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu Target Milestone: --- See the general test plan from the old DTS repo below (its recreation is based on the test cases found in this document): https://git.dpdk.org/tools/dts/tree/test_plans/vlan_ethertype_config_test_plan.rst -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v2] net/gve: Fix TX/RX queue setup and stop
Acked-by: Joshua Washington
RE: [PATCH] eal: add support for TRNG with Arm RNG feature
> > Without a rationale why rte_csrand() functionality is something that should be > in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(), > it doesn't really matter how the patch set looks like. > > I've repeatedly asked for this information, and you've repeatedly ignored it. > This does not further your cause. > I don't want to get into a debate on what's more superior because DPDK already have similar Setups, take OpenSSL and Marvell's security accelerator for instance. Rationale is simple it boils down to freedom of choice. I have been reiterating that I'm ready to make Kernel getrandom() the default in rte_csrand() and HW RNG (not limited Arm) a build time option along with your other demands for various optimizations. Having a build time option to enable HW CSRNG doesn't hinder your freedom to choose a CSRNG implementation of your linking. Neither you nor I are in a place to decide what's right for others; the best we can do is to collaborate on providing them with options. Leave the decision to users, application developers, and integrators. I believe that the coexistence of support for OpenSSL and other HW security accelerators in DPDK already establishes rationale and precedent.
Re: [PATCH] eal: add support for TRNG with Arm RNG feature
On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote: Without a rationale why rte_csrand() functionality is something that should be in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(), it doesn't really matter how the patch set looks like. I've repeatedly asked for this information, and you've repeatedly ignored it. This does not further your cause. I don't want to get into a debate on what's more superior because DPDK already have similar Setups, take OpenSSL and Marvell's security accelerator for instance. Rationale is simple it boils down to freedom of choice. I have been reiterating that I'm ready to make Kernel getrandom() the default in rte_csrand() and HW RNG (not limited Arm) a build time option along with your other demands for various optimizations. Having a build time option to enable HW CSRNG doesn't hinder your freedom to choose a CSRNG implementation of your linking. Neither you nor I are in a place to decide what's right for others; the best we can do is to collaborate on providing them with options. Leave the decision to users, application developers, and integrators. I believe that the coexistence of support for OpenSSL and other HW security accelerators in DPDK already establishes rationale and precedent. I feel no obligation to offer (potentially relatively uninformed) DPDK users with options which I suspect have no benefits, only drawbacks. In the x86_64 HW RNG case, I think it's fair to say we *know* it's bad idea to use it as a high-performance CSRNG. In the ARM case, you choose to leave us in the dark, so I can only assume it looks similar there. The typical networking SoC's crypto-related hardware offload can pretty much always demonstrate benefits.
Re: [PATCH v5 6/6] vhost: optimize memcpy routines when cc memcpy is used
On 2024-07-29 13:00, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
Sent: Wednesday, 24 July 2024 09.54
Which packet mix was used for your tests? Synthetic IMIX, or some live data?
I used the same test as was being done when the performance regression
was demonstrated (i.e., 2x testpmd with fixed packet size).
+/* The code generated by GCC (and to a lesser extent, clang) with just
+ * a straight memcpy() to copy packets is less than optimal on Intel
+ * P-cores, for small packets. Thus the need of this specialized
+ * memcpy() in builds where use_cc_memcpy is set to true.
+ */
+#if defined(RTE_USE_CC_MEMCPY) && defined(RTE_ARCH_X86_64)
+static __rte_always_inline void
+pktcpy(void *restrict in_dst, const void *restrict in_src, size_t len)
+{
+ void *dst = __builtin_assume_aligned(in_dst, 16);
+ const void *src = __builtin_assume_aligned(in_src, 16);
+
+ if (len <= 256) {
+ size_t left;
+
+ for (left = len; left >= 32; left -= 32) {
+ memcpy(dst, src, 32);
+ dst = RTE_PTR_ADD(dst, 32);
+ src = RTE_PTR_ADD(src, 32);
+ }
+
+ memcpy(dst, src, left);
+ } else
Although the packets within a burst often have similar size, I'm not sure you
can rely on the dynamic branch predictor here.
I agree that the pktcpy() routine will likely often suffer a
size-related branch mispredict with real packet size mix. A benchmark
with a real packet mix would be much better than the tests I've run.
This needs to be compared, of course, with the overhead imposed by
conditionals included in other pktcpy() implementations.
Looking at the ethdev packet size counters at an ISP (at the core of their
Layer 3 network), 71 % are 256 byte or larger [1].
For static branch prediction, I would consider > 256 more likely and swap the two
branches, i.e. compare (len > 256) instead of (len <= 256).
OK, I'll add likely() instead, to make it more explicit.
But again: I don't know how the dynamic branch predictor behaves here. Perhaps
my suggested change makes no difference.
I think it will, but it will be tiny. From what I understand, even when
the branch prediction guessed correctly, one receive a slight benefit if
the branch is not taken.
+ memcpy(dst, src, len);
+}
With or without suggested change,
Acked-by: Morten Brørup
[1]: Details (incl. one VLAN tag)
tx_size_64_packets1,1 %
tx_size_65_to_127_packets25,7 %
tx_size_128_to_255_packets2,6 %
tx_size_256_to_511_packets1,4 %
tx_size_512_to_1023_packets 1,7 %
tx_size_1024_to_1522_packets 67,6 %
RE: [PATCH] eal: add support for TRNG with Arm RNG feature
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Monday, 29 July 2024 21.12 > > On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote: > >> > >> Without a rationale why rte_csrand() functionality is something that > should be > >> in DPDK, and a rationale why the ARM CPU CSRNG is superior to > getentropy(), > >> it doesn't really matter how the patch set looks like. > >> > >> I've repeatedly asked for this information, and you've repeatedly > ignored it. > >> This does not further your cause. > >> > > > > I don't want to get into a debate on what's more superior because DPDK > already have similar > > Setups, take OpenSSL and Marvell's security accelerator for instance. > Rationale is simple it boils > > down to freedom of choice. > > > > I have been reiterating that I'm ready to make Kernel getrandom() the > default in rte_csrand() > > and HW RNG (not limited Arm) a build time option along with your other > demands for various > > optimizations. Having a build time option to enable HW CSRNG doesn't > hinder your freedom to > > choose a CSRNG implementation of your linking. > > Neither you nor I are in a place to decide what's right for others; > the best we can do is to > > collaborate on providing them with options. Leave the decision to > users, application developers, > > and integrators. > > > > I believe that the coexistence of support for OpenSSL and other HW > security accelerators in > > DPDK already establishes rationale and precedent. > > > > > > I feel no obligation to offer (potentially relatively uninformed) DPDK > users with options which I suspect have no benefits, only drawbacks. In > the x86_64 HW RNG case, I think it's fair to say we *know* it's bad idea > to use it as a high-performance CSRNG. In the ARM case, you choose to > leave us in the dark, so I can only assume it looks similar there. > > The typical networking SoC's crypto-related hardware offload can pretty > much always demonstrate benefits. I have been following this discussion, and tend to agree with Mattias and Stephen. However, I'll take another view at it from a different angle. DPDK already offers other crypto functions through the crypto drivers. So DPDK is already in the crypto space. getentropy() is not available on Windows, so adding a cross-platform cryptographically secure random number generator function to DPDK could be useful. However, the rte_random functions in the EAL is for high-speed pseudo-random number generation, not for crypto use. No crypto functions - not even true random number generation - belong in the EAL, but in a crypto library. Repeat: No crypto in EAL! So, either add the new true random number generator as some sort of crypto driver, or add a new crypto library for true random number generation. Regarding the API, having a 64 bit true random number generator is useless for crypto purposes; the function needs to generate a sequence of random bytes for crypto initialization vectors and similar. It could have an API resembling this: int rte_crypto_random(char * const buf, size_t num); However, as Mattias mentions, the underlying implementation must support typical networking SoC's crypto-related hardware offload to be practically useful. In other words: It is not as simple as we wish for. It seems some sort of "true random generator" driver infrastructure might be required for such SoC hardware offloads.
Re: [PATCH] doc: Fix some typos in mbuf_lib.rst and net/cnxk comments.
18/04/2024 08:20, Mao YingMing: > From: maoyingming > > Fixes: 2542ad53d8 (doc: add description of the offload API) > Fixes: ae2c2cb606 (net/cnxk: avoid command copy from Tx queue) > > Reviewed-by: lishuo02 > Signed-off-by: maoyingming Applied, thanks.
Re: [PATCH] doc: clarify mempool striding optimisation on Arm
15/07/2024 16:44, Jack Bond-Preston: > The mempool memory channel striding optimisation is not necessary on > Arm platforms. > Update the Programmer's Guide's mempool section to clarify this. > > Signed-off-by: Jack Bond-Preston > Reviewed-by: Wathsala Vithanage > --- > +.. note:: > + > +This feature is not present for Arm systems. Modern Arm Interconnects > choose the SN-F (memory > +channel) using a hash of memory address bits. As a result, the load is > distributed evenly in all > +cases, including the above described, rendering this feature unnecessary. Applied with indentation changes, thanks.
RE: [PATCH v5 6/6] vhost: optimize memcpy routines when cc memcpy is used
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: Monday, 29 July 2024 21.27
>
> On 2024-07-29 13:00, Morten Brørup wrote:
> >> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> >> Sent: Wednesday, 24 July 2024 09.54
> >
> > Which packet mix was used for your tests? Synthetic IMIX, or some live
> data?
> >
>
> I used the same test as was being done when the performance regression
> was demonstrated (i.e., 2x testpmd with fixed packet size).
>
> >> +/* The code generated by GCC (and to a lesser extent, clang) with
> just
> >> + * a straight memcpy() to copy packets is less than optimal on Intel
> >> + * P-cores, for small packets. Thus the need of this specialized
> >> + * memcpy() in builds where use_cc_memcpy is set to true.
> >> + */
> >> +#if defined(RTE_USE_CC_MEMCPY) && defined(RTE_ARCH_X86_64)
> >> +static __rte_always_inline void
> >> +pktcpy(void *restrict in_dst, const void *restrict in_src, size_t
> len)
> >> +{
> >> + void *dst = __builtin_assume_aligned(in_dst, 16);
> >> + const void *src = __builtin_assume_aligned(in_src, 16);
> >> +
> >> + if (len <= 256) {
> >> + size_t left;
> >> +
> >> + for (left = len; left >= 32; left -= 32) {
> >> + memcpy(dst, src, 32);
> >> + dst = RTE_PTR_ADD(dst, 32);
> >> + src = RTE_PTR_ADD(src, 32);
> >> + }
> >> +
> >> + memcpy(dst, src, left);
> >> + } else
> >
> > Although the packets within a burst often have similar size, I'm not
> sure you can rely on the dynamic branch predictor here.
> >
>
> I agree that the pktcpy() routine will likely often suffer a
> size-related branch mispredict with real packet size mix. A benchmark
> with a real packet mix would be much better than the tests I've run.
>
> This needs to be compared, of course, with the overhead imposed by
> conditionals included in other pktcpy() implementations.
If testing with fixed packet size, only one of the branches will be taken -
always!
And thus the branch predictor will always predict it correctly - in the test.
So, if this code performs better than simple memcpy(), I can conclude that you
are testing with packet size <= 256.
>
> > Looking at the ethdev packet size counters at an ISP (at the core of
> their Layer 3 network), 71 % are 256 byte or larger [1].
> >
> > For static branch prediction, I would consider > 256 more likely and
> swap the two branches, i.e. compare (len > 256) instead of (len <= 256).
> >
>
> OK, I'll add likely() instead, to make it more explicit.
>
> > But again: I don't know how the dynamic branch predictor behaves here.
> Perhaps my suggested change makes no difference.
> >
>
> I think it will, but it will be tiny. From what I understand, even when
> the branch prediction guessed correctly, one receive a slight benefit if
> the branch is not taken.
>
> >> + memcpy(dst, src, len);
> >> +}
> >
> > With or without suggested change,
> > Acked-by: Morten Brørup
> >
> >
> > [1]: Details (incl. one VLAN tag)
> > tx_size_64_packets1,1 %
> > tx_size_65_to_127_packets25,7 %
> > tx_size_128_to_255_packets2,6 %
> > tx_size_256_to_511_packets1,4 %
> > tx_size_512_to_1023_packets 1,7 %
> > tx_size_1024_to_1522_packets 67,6 %
> >
Re: [PATCH 1/2] doc: add note about CPU 0
18/07/2024 20:43, Stephen Hemminger: > On Linux (and probably BSD), CPU 0 can not be fully isolated > because it receives timer interrupts and is used for other > kernel related functions. The DPDK documentation should > be updated to tell users to avoid polling on that CPU. > > Signed-off-by: Stephen Hemminger > --- > +.. note:: > + > +It is not recommended to use CPU core 0 for DPDK polling applications > +because it can not be isolated from other system and kernel activity. Indent should be 3 spaces. > For example, if a given CPU has 0-7 cores > -and DPDK applications are to run on logical cores 2, 4 and 6, > -the following should be added to the kernel parameter list: > +and DPDK applications are to run on logical cores 2, 4 and 6. > +The following should be added to the kernel parameter list: I think it was better as 1 sentence with the comma.
Re: [PATCH] doc: update minimum Linux kernel version
16/02/2024 18:42, Stephen Hemminger: > On Fri, 16 Feb 2024 09:29:47 +0100 > Morten Brørup wrote: > > > The system requirements in the Getting Started Guide [1] says: > > > > Kernel version >= 4.14 > > The kernel version required is based on the oldest long term stable kernel > > available at kernel.org when the DPDK version is in development. > > Compatibility for recent distribution kernels will be kept, notably > > RHEL/CentOS 7. > > > > [1]: https://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#system-software > > > > If we consider it API breakage to change that, we have to wait until the > > 24.11 release. > > For future DPDK LTS releases, we should be more careful about what we claim > > to support. And again: If we claim to support something, people expect it > > to be tested in CI. > > > > Disregarding the API breakage by stopping support for a system we claim to > > support... RHEL7 testing was changed to LTS only [2], that should probably > > have been applied to CentOS 7 too. > > > > [2]: > > https://inbox.dpdk.org/dev/CAJvnSUBcq3gznQD4k=krQ+gu2OxTxA2YJBc=J=ltidfxqgg...@mail.gmail.com/ > > > > This patch is too late for 24.03 release, by the time the next one happens, > we can drop CentOS 7 as well as the old kernel. Applied this kernel minimum bump. Please send another patch for dropping RHEL/CentOS 7.
Re: [PATCH] doc: update AMD Linux guide
13/07/2024 13:08, Vipin Varghese: > Introduce sections into AMD Linux getting start guide for > 1. MAX LCORE > 2. CPU power > > Signed-off-by: Vipin Varghese Applied with minor improvements.
Re: [PATCH] doc: add power uncore API documentation
30/04/2024 20:57, Ferruh Yigit:
> Add missing power uncore API documenttation.
>
> Fixes: ac1edcb6621a ("power: refactor uncore power management API")
> Cc: sta...@dpdk.org
>
> Reported-by: Vipin Varghese
> Signed-off-by: Ferruh Yigit
Applied, thanks
[PATCH v1 0/1] dts: testpmd verbose parser
From: Jeremy Spewock This series adds a new text parser that is able to extract all verbose messages from testpmd output into a more organized data structure. Jeremy Spewock (1): dts: add text parser for testpmd verbose output dts/framework/parser.py | 30 dts/framework/remote_session/testpmd_shell.py | 146 +- dts/framework/utils.py| 1 + 3 files changed, 175 insertions(+), 2 deletions(-) -- 2.45.2
[PATCH v1 1/1] dts: add text parser for testpmd verbose output
From: Jeremy Spewock Multiple test suites from the old DTS framework rely on being able to consume and interpret the verbose output of testpmd. The new framework doesn't have an elegant way for handling the verbose output, but test suites are starting to be written that rely on it. This patch creates a TextParser class that can be used to extract the verbose information from any testpmd output and also adjusts the `stop` method of the shell to return all output that it collected. Signed-off-by: Jeremy Spewock --- One thing to note here is I don't love the regex in extract_verbose_output(). It works great when there is a bunch of verbose output in a row, but any chunk that isn't followed by another piece of verbose output will contain everything that comes after it in the match group. This could be solved by changing the regex to look ahead only for the next port X/queue Y line instead of also including the end of the string, and then having another alternate route which is solely dedicated to the last block of verbose output which greedily consumes everything until the end of ol_flags, but I didn't want to over complicate the regex since the text parser will extract the specific information it needs anyways. For reference, I was thinking it could be something like this: r"(port \d+/queue \d+:.*?(?=port \d+/queue \d+)|port \d+/queue \d+:.*ol_flags: [\w ]+)" but this has a lot of repition (some of which that could be ripped out with a simple variable) and it is a little more confusing to read I think. dts/framework/parser.py | 30 dts/framework/remote_session/testpmd_shell.py | 146 +- dts/framework/utils.py| 1 + 3 files changed, 175 insertions(+), 2 deletions(-) diff --git a/dts/framework/parser.py b/dts/framework/parser.py index 741dfff821..0b39025a48 100644 --- a/dts/framework/parser.py +++ b/dts/framework/parser.py @@ -160,6 +160,36 @@ def _find(text: str) -> Any: return ParserFn(TextParser_fn=_find) +@staticmethod +def find_all( +pattern: str | re.Pattern[str], +flags: re.RegexFlag = re.RegexFlag(0), +) -> ParserFn: +"""Makes a parser function that finds all of the regular expression matches in the text. + +If there are no matches found in the text than None will be returned, otherwise a list +containing all matches will be returned. Patterns that contain multiple groups will pack +the matches for each group into a tuple. + +Args: +pattern: The regular expression pattern. +flags: The regular expression flags. Ignored if the given pattern is already compiled. + +Returns: +A :class:`ParserFn` that can be used as metadata for a dataclass field. +""" +if isinstance(pattern, str): +pattern = re.compile(pattern, flags) + +def _find_all(text: str) -> list[str] | None: +m = pattern.findall(text) +if len(m) == 0: +return None + +return m + +return ParserFn(TextParser_fn=_find_all) + @staticmethod def find_int( pattern: str | re.Pattern[str], diff --git a/dts/framework/remote_session/testpmd_shell.py b/dts/framework/remote_session/testpmd_shell.py index 43e9f56517..9f09a98490 100644 --- a/dts/framework/remote_session/testpmd_shell.py +++ b/dts/framework/remote_session/testpmd_shell.py @@ -31,7 +31,7 @@ from framework.settings import SETTINGS from framework.testbed_model.cpu import LogicalCoreCount, LogicalCoreList from framework.testbed_model.sut_node import SutNode -from framework.utils import StrEnum +from framework.utils import REGEX_FOR_MAC_ADDRESS, StrEnum class TestPmdDevice: @@ -577,6 +577,128 @@ class TestPmdPortStats(TextParser): tx_bps: int = field(metadata=TextParser.find_int(r"Tx-bps:\s+(\d+)")) +class VerboseOLFlag(Flag): +"""Flag representing the OL flags of a packet from Testpmd verbose output.""" + +#: +RTE_MBUF_F_RX_RSS_HASH = auto() + +#: +RTE_MBUF_F_RX_L4_CKSUM_GOOD = auto() +#: +RTE_MBUF_F_RX_L4_CKSUM_BAD = auto() +#: +RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN = auto() + +#: +RTE_MBUF_F_RX_IP_CKSUM_GOOD = auto() +#: +RTE_MBUF_F_RX_IP_CKSUM_BAD = auto() +#: +RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN = auto() + +#: +RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD = auto() +#: +RTE_MBUF_F_RX_OUTER_L4_CKSUM_BAD = auto() +#: +RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN = auto() + +@classmethod +def from_str_list(cls, arr: list[str]) -> Self: +"""Makes an instance from a list containing the flag members. + +Args: +arr: A list of strings containing ol_flag values. + +Returns: +A new instance of the flag. +""" +flag = cls(0) +for name in cls.__members__: +if name in arr: +flag |= cls[name] +return flag + +
Re: release candidate 24.07-rc3
IBM - Power Systems Testing DPDK v24.07-rc3-0-g82c47f005b * Build CI on Fedora 37,39,40 container images for ppc64le * Basic PF on Mellanox: No issue found * Performance: not tested. * OS:- RHEL 9.4 kernel: 5.14.0-427.13.1.el9_4.ppc64le with gcc version 11.4.1 20231218 (Red Hat 11.4.1-3) - RHEL 9.2 kernel: 5.14.0-284.52.1.el9_2.ppc64le with gcc version 11.3.1 20221121 (Red Hat 11.3.1-4) (GCC) - SLES 15-SP5 ppc64le kernel: 5.14.21-150500.55.44-default with gcc version 12.3.0 (SUSE Linux) Systems tested: - LPARs on IBM Power10 CHRP IBM,9105-22A NICs: - Mellanox Mellanox Technologies MT2894 Family [ConnectX-6 Lx] - firmware version: 26.41.1000 - MLNX_OFED_LINUX-24.04-0.6.6.5 Regards, Thinh On 7/23/2024 6:03 PM, Thomas Monjalon wrote: A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v24.07-rc3 There are 100 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_24_07.html As usual, you can report any issue on https://bugs.dpdk.org Only documentation and critical bug fixes should be accepted at this stage. There is only one week remaining before the end of the month. DPDK 24.07-rc4 should be the last release candidate. Thank you everyone
Re: [PATCH v2] doc: document mlx5 HWS actions order
24/07/2024 09:36, Maayan Kashani:
> Add actions order supported in mlx5 PMD when HW steering flow engine
> is used.
> This limitation existed since HW Steering flow engine was introduced.
>
> Fixes: 22681deead3e ("net/mlx5/hws: enable hardware steering")
> Cc: sta...@dpdk.org
> Signed-off-by: Maayan Kashani
> Acked-by: Dariusz Sosnowski
Applied, thanks.
Re: [PATCH] doc: fix dma perf typo
25/07/2024 19:47, Amit Prakash Shukla:
> Fixing typo in command line arguments for dma perf application.
>
> Fixes: 623dc9364dc6 ("app/dma-perf: introduce DMA performance test")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Amit Prakash Shukla
Applied, thanks.
Re: [PATCH] doc: documentation update for idxd driver
27/06/2024 17:04, Stephen Hemminger: > On Thu, 27 Jun 2024 04:42:14 + > Shaiq Wani wrote: > > > Added a note to avoid usage errors by end user. > > > > Signed-off-by: Shaiq Wani > > If it is going in the documentation, it needs more explanation as to what > that parameters do. I would prefer not having such driver-specific requirement.
Re: [PATCH] doc: fix description of maximum rx queues per lcore option
13/06/2023 18:15, Stephen Hemminger: > Several commands have a -q option but the description in > the documentation was unclear. It is the upper limit on > the number of queues per lcore. > > Suggested-by: Vipin Varghese > Signed-off-by: Stephen Hemminger Applied, thanks.
Re: [PATCH] doc/sample_app_ug: add baseline mode
16/04/2024 15:20, Karen Kelly:
> Updating PMD Power Management Mode section of the l3fwd-power
> sample app to add baseline option as this was missing from the
> original commit.
>
> Fixes: a9ea60702ecb ("examples/l3fwd-power: add baseline PMD management mode")
>
> Signed-off-by: Karen Kelly
Applied, thanks.
release candidate 24.07-rc4
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v24.07-rc4 There are only 17 patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_24_07.html As usual, you can report any issue on https://bugs.dpdk.org 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. The final release will happen on the last day of the month. Please think about sharing your roadmap now for DPDK 24.11. Thank you everyone
RE: release candidate 24.07-rc3
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, July 24, 2024 7:03 AM > To: annou...@dpdk.org > Subject: release candidate 24.07-rc3 > > A new DPDK release candidate is ready for testing: > https://git.dpdk.org/dpdk/tag/?id=v24.07-rc3 > > There are 100 new patches in this snapshot. > > Release notes: > https://doc.dpdk.org/guides/rel_notes/release_24_07.html > > As usual, you can report any issue on https://bugs.dpdk.org > > Only documentation and critical bug fixes should be accepted at this stage. > > There is only one week remaining before the end of the month. > DPDK 24.07-rc4 should be the last release candidate. > > Thank you everyone > Update the test status for Intel part. dpdk24.07-rc3 all test is done. found two new issues. New issues: 1. Bug 1502 - [dpdk-24.07] l3fwdacl/l3fwdacl_acl_rule: core dump when receiving packets -> not fix yet 2. ieee1588/ieee1588_enable: obtained incorrect timestamp -> Intel dev is under investigating # Basic Intel(R) NIC testing * Build or compile: *Build: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu22.04.4, Ubuntu24.04, Fedora40, RHEL9.3/9.4, FreeBSD14.0, SUSE15.5, OpenAnolis8.8, CBL-Mariner2.0 etc. - All test passed. *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu24..04 and RHEL9.4. - All test passed with latest dpdk. * PF/VF(i40e, ixgbe): test scenarios including PF/VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All test case is done. No new issue is found. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - Execution rate is done. found the 1&2 issue. * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, RFC2544 Zero packet loss performance test, etc. - Execution rate is done. No new issue is found. * Power and IPsec: * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc. - Execution rate is done. No new issue is found. * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - Execution rate is done. No new issue is found. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 8.0U1, etc. - Execution rate is done. No new issue is found. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - Execution rate is done. No new issue is found. *Performance test: test scenarios including Throughput Performance /Cryptodev Latency, etc. - Execution rate is done. No performance drop. Regards, Xu, Hailin
[PATCH v1] net/cpfl: fix cpfl parser issue
CPFL parser was incorrectly parsing the mask value of the
next_proto_id field as a string instead of unsigned integer.
This patch will fix this issue.
Fixes: 41f20298ee8c ("net/cpfl: parse flow offloading hint from JSON")
Cc: sta...@dpdk.org
Signed-off-by: Praveen Shetty
---
drivers/net/cpfl/cpfl_flow_parser.c | 31 -
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/net/cpfl/cpfl_flow_parser.c
b/drivers/net/cpfl/cpfl_flow_parser.c
index 40569ddc6f..9845bd1ad3 100644
--- a/drivers/net/cpfl/cpfl_flow_parser.c
+++ b/drivers/net/cpfl/cpfl_flow_parser.c
@@ -213,16 +213,29 @@ cpfl_flow_js_pattern_key_proto_field(json_t *ob_fields,
if (js_field->type == RTE_FLOW_ITEM_TYPE_ETH ||
js_field->type == RTE_FLOW_ITEM_TYPE_IPV4) {
- mask = cpfl_json_t_to_string(object, "mask");
- if (!mask) {
- PMD_DRV_LOG(ERR, "Can not parse string
'mask'.");
- goto err;
- }
- if (strlen(mask) > CPFL_JS_STR_SIZE - 1) {
- PMD_DRV_LOG(ERR, "The 'mask' is too long.");
- goto err;
+ /* Added a check for parsing mask value of the
next_proto_id field. */
+ if (strcmp(name, "next_proto_id") == 0) {
+ uint32_t mask_32b;
+ int ret;
+ ret = cpfl_json_t_to_uint32(object, "mask",
&mask_32b);
+ if (ret < 0) {
+ PMD_DRV_LOG(ERR, "Can not parse uint32
'mask'.");
+ goto err;
+ }
+ js_field->fields[i].mask_32b = mask_32b;
+ } else {
+ mask = cpfl_json_t_to_string(object, "mask");
+ if (!mask) {
+ PMD_DRV_LOG(ERR, "Can not parse string
'mask'.");
+ goto err;
+ }
+ if (strlen(mask) > CPFL_JS_STR_SIZE - 1) {
+ PMD_DRV_LOG(ERR, "The 'mask' is too
long.");
+ goto err;
+ }
+ rte_strscpy(js_field->fields[i].mask, mask,
CPFL_JS_STR_SIZE - 1);
}
- strncpy(js_field->fields[i].mask, mask,
CPFL_JS_STR_SIZE - 1);
+
} else {
uint32_t mask_32b;
int ret;
--
2.34.1
Re: Regarding port numbers assigned by DPDK for PCI devices
On Mon, 29 Jul 2024 at 23:13, Dmitry Kozlyuk wrote: > 2024-07-29 22:18 (UTC+0530), Prashant Upadhyaya: > > Hi, > > > > I have 4 ethernet interfaces available as PCI devices. > > The PCI addresses are known. > > When I start my DPDK application, it starts up properly and assigns the > > port numbers to them as 0, 1, 2, 3 expectedly. > > > > However, is there a way I can force that a particular PCI address should > be > > identified as port 0 by DPDK, another one as port 1 and so forth ? > > Does passing the arguments like -a -a to > rte_eal_init > > ensure that, or is there any other way, or is there no way ? > > > > I am on 24.03 > > > > Regards > > -Prashant > > Hi, > > Why do you need specific port numbers assigned to devices? > > If you're going to use devices for different purposes, > you'd better have an application-level configuration > to specify PCI addresses to use for each purpose. > Iterate devices to match the address and find the port number. > > It is also possible to disable automatic probing with "-a 0:0.0", > then to use rte_dev_probe() + rte_dev_event_callback_register() > to add devices and to get their port numbers. > However, this API, strictly speaking, does not guarantee > that the numbers will be assigned sequentially. > One advantage of using hot-plug is that you can build devargs > from within the application (or from configuration). > > Refer to "rte_dev.h" in any case. > Multiple "-a" don't work the way you've described. > Thanks Dmitry. Ok, so if I have the port number with me, and I know it corresponds to a PCI device, how do I find out the PCI address of this device corresponding to this port number. I believe I can do rte_eth_dev_info_get to get the struct rte_eth_dev_info and from there the rte_device, but what after that ? I saw some references to RTE_DEV_TO_PCI but that macro isn't available for compilation after DPDK is installed as it is an internal header file and thus not a macro for application usage and wouldn't compile at application level. Regards -Prashant
