[Bug 1248] Hi
https://bugs.dpdk.org/show_bug.cgi?id=1248 Bug ID: 1248 Summary: Hi Product: DPDK Version: 22.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: eventdev Assignee: dev@dpdk.org Reporter: emma.megan1...@gmail.com Target Milestone: --- If you're interested in sharing your knowledge and expertise with a wider audience, Write for us guest post to a blog or website is a great way to do so. When you write for us, you have the opportunity to showcase your writing style and connect with a new audience. Read More: https://technologicz.com/ -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH] bus/vdev: add warning for duplicated vdev name
On Thu, 29 Nov 2018 15:16:08 +0800
Yahui Cao wrote:
> If duplicated vdev name is detected, print out a warning message.
>
> Signed-off-by: Yahui Cao
> ---
> drivers/bus/vdev/vdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
> index 9c66bdc78..ff2db7d3f 100644
> --- a/drivers/bus/vdev/vdev.c
> +++ b/drivers/bus/vdev/vdev.c
> @@ -462,6 +462,8 @@ vdev_scan(void)
> if (find_vdev(devargs->name)) {
> rte_spinlock_recursive_unlock(&vdev_device_list_lock);
> free(dev);
> + VDEV_LOG(WARNING, "duplicated vdev name %s detected!",
> + devargs->name);
> continue;
> }
>
Do you have an example of this?
It should be an error and have the scan fail.
[Bug 1248] Hi
https://bugs.dpdk.org/show_bug.cgi?id=1248 Thomas Monjalon (tho...@monjalon.net) changed: What|Removed |Added CC||tho...@monjalon.net Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Thomas Monjalon (tho...@monjalon.net) --- SPAM -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v3 04/11] net/bnxt: update Truflow core
04/05/2023 19:36, Ajit Khaparde: > From: Randy Schacher > > Update TruFlow core code to: > - Add shared session management > - Add SRAM session management > - Add dynamic TCAM management > - Add shared TCAM session management > - Add Hot Upgrade support > - Update copyright year I suppose you can update the date in the previous patch for the whole driver. Also this patch is removing some blank lines out of Truflow. And I don't understand the need for removing the blank lines before the last #ifdef of the file. More important, you are doing huge update of many different things in one patch. It looks like you don't want the community to follow what you are doing. For info, there are other things to fix in this patchset: Error: Incorrect indent at drivers/net/bnxt/tf_ulp/generic_templates/meson.build rte_flow doc out of sync for bnxt action set_mac_dst action set_mac_src You can run the following script to catch these issues: devtools/check-meson.py devtools/check-doc-vs-code.sh
Re: [PATCH v2 8/8] crypto/ipsec_mb: set and use session ID
16/05/2023 17:24, Ciara Power: > From: Pablo de Lara > > When creating a session, get the session ID that > defines the fixed session parameters and store it in the private data. > When retrieving IMB_JOB's, if their internal session ID matches > the one in the private session data, these fixed session parameters > do not need to be filled again. > > Signed-off-by: Pablo de Lara > Signed-off-by: Ciara Power [...] > +#if IMB_VERSION(1, 3, 0) < IMB_VERSION_NUM > + sess->session_id = imb_set_session(mb_mgr, &sess->template_job); > +#endif For info, this does not compile with https://git.gitlab.arm.com/arm-reference-solutions/ipsec-mb.git because Arm did not merge Intel's code correctly, and imb_set_session() is missing while version is 1.4.0-dev. Anyway I hate this situation having 2 repos for the same thing. Please merge Arm code in the original repository from Intel.
[PATCH v5] lib/net: add MPLS insert and strip functionality
None of the foundational NICs currently supports MPLS insertion and
stripping, this functionality can help users who rely on MPLS in their
network application.
Signed-off-by: Tanzeel Ahmed
---
This patch is new version of [PATCH] lib/net: added push MPLS header API.
I have also added the MPLS strip functionality to address the question
asked in last patch.
> To be honest, I have some doubts about the usefulness of the patch,
> especially the function that strips all the MPLS headers.
I believe it serves a practical purpose, in scenarios involving tapped traffic
where MPLS headers
have not been stripped.
While some headers in the lib/net folder have well-defined functions, others
are limited to their
structure alone. It would be advantageous to have basic functions available for
all headers.
> I think the function should only strip the first MPLS header, it is
> symmetric with the previous function, and more flexible.
You are right, stripping one header is more flexible.
I updated the function to return 1, in case of stripping last MPLS header.
v5:
* Updated the MPLS strip function to strip one header at a time.
* Added the unit test cases.
v4:
* Removed extra void cast.
* rte_pktmbuf_append/mtod now return void*.
The memmove result is casted to rte_ether_hdr*.
v3:
* fixed patch check failure issue
v2:
* marked experimental
* coding style fixed
* changed rte_memcpy to memcpy
* mpls header marked as const in parameter
* added MPLS stripping functionality
---
app/test/meson.build | 2 +
app/test/test_mpls.c | 180 +++
lib/net/rte_mpls.h | 106 +
3 files changed, 288 insertions(+)
create mode 100644 app/test/test_mpls.c
diff --git a/app/test/meson.build b/app/test/meson.build
index f34d19e3c3..548349399f 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -95,6 +95,7 @@ test_sources = files(
'test_meter.c',
'test_mcslock.c',
'test_mp_secondary.c',
+'test_mpls.c',
'test_per_lcore.c',
'test_pflock.c',
'test_pmd_perf.c',
@@ -205,6 +206,7 @@ fast_tests = [
['mempool_autotest', false, true],
['memzone_autotest', false, true],
['meter_autotest', true, true],
+['mpls_autotest', false, true],
['multiprocess_autotest', false, false],
['per_lcore_autotest', true, true],
['pflock_autotest', true, true],
diff --git a/app/test/test_mpls.c b/app/test/test_mpls.c
new file mode 100644
index 00..8ff701f6e0
--- /dev/null
+++ b/app/test/test_mpls.c
@@ -0,0 +1,180 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include "test.h"
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MEMPOOL_CACHE_SIZE 32
+#define MBUF_DATA_SIZE 2048
+#define NB_MBUF 128
+
+static int
+test_mpls_fail_push(struct rte_mbuf *m)
+{
+ struct rte_mpls_hdr mpls;
+
+ /* create dummy MPLS header */
+ mpls.tag_msb = 1;
+ mpls.tag_lsb = 2;
+ mpls.bs = 1;
+ mpls.tc = 1;
+ mpls.ttl = 255;
+
+ /* push first MPLS header */
+ if (rte_mpls_push_over_l2(m, &mpls) != 0)
+ return 0;
+ return -1;
+}
+
+static int
+test_mpls_push(struct rte_mbuf *m)
+{
+ struct rte_mpls_hdr mpls;
+
+ /* create dummy MPLS header */
+ mpls.tag_msb = 1;
+ mpls.tag_lsb = 2;
+ mpls.bs = 1;
+ mpls.tc = 1;
+ mpls.ttl = 255;
+
+ /* push first MPLS header */
+ if (rte_mpls_push_over_l2(m, &mpls) != 0) {
+ printf("Failed to insert mpls 1\n");
+ return -1;
+ }
+ if (rte_pktmbuf_pkt_len(m) != RTE_ETHER_HDR_LEN + RTE_MPLS_HLEN) {
+ printf("Bad pkt length after inserting first mpls header\n");
+ return -1;
+ }
+
+ /* push second MPLS header*/
+ if (rte_mpls_push_over_l2(m, &mpls) != 0) {
+ printf("failed to insert mpls 1\n");
+ return -1;
+ }
+ if (rte_pktmbuf_pkt_len(m) != RTE_ETHER_HDR_LEN + RTE_MPLS_HLEN * 2) {
+ printf("bad pkt length after inserting second mpls header\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int
+test_mpls_fail_strip(struct rte_mbuf *m)
+{
+ /* strip MPLS headers */
+ if (rte_mpls_strip_over_l2(m) != 0)
+ return 0;
+ return -1;
+}
+
+static int
+test_mpls_strip(struct rte_mbuf *m)
+{
+ /* strip MPLS headers */
+ return rte_mpls_strip_over_l2(m);
+}
+
+static int
+test_mpls(void)
+{
+ int ret = -1;
+ struct rte_mempool *pktmbuf_pool = NULL;
+ struct rte_mbuf *m = NULL;
+ char *data;
+ struct rte_ether_hdr eh;
+
+ /* create pktmbuf pool */
+ pktmbuf_pool = rte_pktmbuf_pool_create("test_mpls_pool",
+
Re: [PATCH v6 06/21] pdcp: add pre and post process for UL
Hello,
I'm sorry to inform you that I see a compilation failure
when cross-compiling for PPC64:
err_mb is seen as potentially unitialized when calling rte_memcpy().
30/05/2023 12:01, Anoob Joseph:
> +static uint16_t
> +pdcp_post_process_ul(const struct rte_pdcp_entity *entity,
> + struct rte_mbuf *in_mb[], struct rte_mbuf *out_mb[],
> + uint16_t num, uint16_t *nb_err_ret)
> +{
> + struct entity_priv *en_priv = entity_priv_get(entity);
> + const uint32_t hdr_trim_sz = en_priv->aad_sz;
> + int i, nb_success = 0, nb_err = 0;
> + struct rte_mbuf *mb, *err_mb[num];
> +
I need to add a workaround here to make GCC happy:
#ifdef RTE_ARCH_PPC_64
err_mb[0] = NULL; /* workaround PPC-GCC bug */
#endif
> + for (i = 0; i < num; i++) {
> + mb = in_mb[i];
> + if (unlikely(mb->ol_flags & RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED)) {
> + err_mb[nb_err++] = mb;
> + continue;
> + }
> +
> + if (hdr_trim_sz)
> + rte_pktmbuf_adj(mb, hdr_trim_sz);
> +
> + out_mb[nb_success++] = mb;
> + }
> +
> + if (unlikely(nb_err != 0))
> + rte_memcpy(&out_mb[nb_success], err_mb, nb_err * sizeof(struct
> rte_mbuf *));
> +
> + *nb_err_ret = nb_err;
> + return nb_success;
> +}
I've added the workaround in 3 places while pulling next-crypto tree.
Feel free to improve it with a new patch, thanks.
Re: [dpdk-dev] [PATCH] Improve the shaper accuracy for large packets
On Mon, 8 Apr 2019 13:36:14 + "Dumitrescu, Cristian" wrote: > > -Original Message- > > From: Yigit, Ferruh > > Sent: Friday, April 5, 2019 4:54 PM > > To: Dumitrescu, Cristian > > Cc: alanrobertson...@gmail.com; dev@dpdk.org; Alan Robertson > > ; Alan Robertson ; Thomas > > Monjalon > > Subject: Re: [dpdk-dev] [PATCH] Improve the shaper accuracy for large > > packets > > > > On 2/9/2018 10:38 AM, alanrobertson...@gmail.com wrote: > > > From: Alan Robertson > > > > > > There were 2 issues, the first was time could be lost whilst updating > > > the traffic-class period, the second was a frame could be delayed if > > > not enough tokens were available for the full frame. By allowing the > > > shaper to borrow credit from the next period the throughput is improved. > > > > > > Signed-off-by: Alan Robertson > > > > > > Hi Cristian, > > > > Another 'librte_sched' patch waiting for a review for almost a year now, do > > you > > know status of this patch? > > > > Thanks, > > ferruh > > As previously announced, we are planning to do some improvements on this part > of the code [1] and we are planning improve this behavior in a way that is > less intrusive and has slightly better performance (due to no branches). > > Regards, > Cristian > > [1] https://mails.dpdk.org/archives/dev/2018-November/120035.html > This patch is quite old. It looks the original issue was that rte_sched_port_dequeue is racy if port is shared by multiple lcore's. The only update to port->time happens in rte_sched_port_time_resync() frin rte_sched_port_dequeue(). The warnings about thread safety in qos_framework.rst could be improved, but that is something for another patch in future.
Re: [dpdk-dev] [PATCH 1/3] eal: remove useless checks for already probed device
On Wed, 13 Mar 2019 13:46:01 + "Zhang, Qi Z" wrote: > > -Original Message- > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > Sent: Saturday, March 2, 2019 10:43 AM > > To: dev@dpdk.org > > Cc: Stojaczyk, Dariusz ; Zhang, Qi Z > > ; sta...@dpdk.org > > Subject: [PATCH 1/3] eal: remove useless checks for already probed device > > > > The function eal_dev_hotplug_request_to_secondary() never returns -EEXIST > > result. The case of already probed device is filtered out. > > > > The test in __handle_secondary_request() was always true. > > The test in rte_dev_probe() was never true, and that's fine not returning > > -EEXIST > > if device is already attached in secondary processes. > > I didn't get this. > eal_dev_hotplug_request_to_secondary() never return -EEXIST, but req->result > could be -EEXIST. > > This happens when secondary try to attach an already attached device > (__handle_primary_request --> local_dev_probe --> dev->bus->plug ) This seems to be the outstanding question on this old patch. Is this possible? If so then the original code is ok, and patch is not required.
