Acked-by: Abdullah Sevincer
That part below was intended for continuation of the above code sample.
Remember there was a DLB2 related information below I removed that.
But, It looks like it is thought to be an orphan section I will remove it in
the next patch set.
>+The below section does not have any code. It is an orphan
>+This commit should after "[PATCH v10 2/3] eventdev: add support for
>independent enqueue"
>+because this commit use the macro which defined in later commit. Suggest
>order:
>+1. lib's commit
>+2. driver's commits
Thanks this is addressed with v12
>+The above line will remove when DPDK 24.11 r
>+The overall outlook is OK. Send next version with release note changes from
>24.07 to 24.11.
Thanks Jerin, I sent the new version patch v10.
Thanks Mattias,
Hi Jerin,
Are you okay with the changes so far?
Hi Mattias,
I will update patch tomorrow with updated suggestion from Pravin, If I don’t
hear from you I guess you are okay?
Hi Folks,
Any chance to look at the patches? Don’t want to lose the window for API
changes again 😊
Thanks,
I have addressed the documentation changes with patch set v8. If it all looks
good let me know.
Hi Jerin my responses below:
>+# Is this feature or limitation?
This is a new feature to enable enqueuing to PMD in any order when the
underlined hardware device needs enqueues in a strict dequeue order.
>+# What is the use case for this feature?
This is needed by the applications which processes
>++ @Richardson, Bruce @Thomas Monjalon @David Marchand @Ferruh Yigit
>+It is not allowed to add PMD specific build options in generic DPDK build
>options. Please check with Bruce.
>+You may use scheme like
>+>+https://patches.dpdk.org/project/dpdk/patch/20240522192139.3016-1-pbhagavat...@ma
>+OK. At least, slowpath code you can remove ifdef and use only in fastpath.
Hi Jerrin
All of these compilation flags are under fastpath. All other reviews are
addressed at v5. There is one CI issue complain about spelling which is a
struct field, num_hist_list_entries.
That’s been there before
>+This new patch is full of compilation flags clutter, can you make it runtime?
Thanks for the reviews Jerin, we can make it run time but it will cost more
cycles and new APIs in the PMD to set those run time params. The reason we do
it this way is to save cycles also not to make cli params lon
>+Hi Abdullah,
>+Couple of small asks/tips when sending new versions of a patchset:
>+1) When sending v2, v3, v4 using git-send-email, include
>+ "--in-reply-to " in the command. This will
>+ ensure all copies of the patches get put in the same email thread, rather
>+than having different vers
>+uint32_t *credit_pool[DLB2_NUM_QUEUE_TYPES]; /* use __atomic builtins */
Spell check complains here you can add a space after the '*' if you don’t want
that complaint. (e.g. uint32_t * credit_pool).
> case nb_events_limit:
> return dlb2->new_event_limit;
> case infl
Acked-by: Abdullah Sevincer
Hi Stephen,
Are all rte_memcpy functions now be replaced by memcpy and no more use of
rte_memcpy?
>+I don't understand why you would say that.
>+The message already will get a single newline and your change would add a
>second one.
>+Log messages are not supposed to be double spaced, it confuses syslog.
>+If you want to change the overall format of log messages and how it displays
>the fun
>+ DLB2_LOG_INFO("Ignoring unsupported parameters when
>creating device '%s'",
name);
Hi Stephen can you modify above like this:
DLB2_LOG_INFO(": Ignoring unsupported parameters when creating device '%s'\n",
name);
It looks better this
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
>+I don’t know about the details, so it means for different devices that
>support PASID, they have different offsets?
>+Btw, Is this cap still not exposed to user space in latest kernel?
Yes, may be different offsets for different devices.
As of now it is not exposed to user. Bruce's test was o
I have pushed another patch addressing David's comments.
https://patches.dpdk.org/project/dpdk/patch/20231113172759.3529518-1-abdullah.sevin...@intel.com/
>+Ok, that is indeed an issue.
>+I found some patches exposing this capability with vfio-pci but I am not sure
>what is the latest work on the topic.
That's right, some kernels may expose the capability some not. We realized it
when Bruce reported my earlier patch with the api rte_pci_find_ext_
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
>+I don't see much point in providing a wrapper that does nothing more than
>call rte_pci_write_config() and let the driver pass the right offsets.
>+If anything, can't this wrapper find out about the pasid offset itself?
>+There is a extended capability for this, so I would expect it can be use
>+Is PASID now part of PCIe spec? This APIs should both work for x86/arm?
>+Not sure ARM is OK with the naming, previously they are calling it more as
>Sub Stream ID (SSID)
For reference, Look for PASID definitions in the PCIe spec.
The API takes in offset which might be different for other devic
>+Looks like you missed my comments at
>+https://patches.dpdk.org/project/dpdk/patch/20231103170347.2790525-1-abdullah.sevin...@intel.com/
Yes, all comments, upstream happened at the same time 😊 will address them and
push another patch.
>+> WDYT, Jerin, Abdullah.
It is a good idea to make it internal, I will work on that and upstream a new
one.
>++ PCIe maintainers.
>+I will leave this up to @David Marchand / @Thomas as this patch has common
>code changes and needs to come via main tree.
>+Also in this case, The comment was given very early(Back in June 7) for the
>same.
>+https://patches.dpdk.org/project/dpdk/patch/20230607210050.1
> +This patch can be splited as two,
> +1) Generic PCIe function to enable/disable PASID
> +2) Call generic function to disable PASID in drivers/event/dlb2/. Also
> mention which Linux kernel commit is introducing this issue in the git commit
> log.
Hi Jerrin,
I think I need to provide more inf
>+We will work on this proposal, it is not finalized yet.
>+Its not DLB2 specific as commenters say, we are looking into if there is
>another way doing it.
>+If it will end up common and not DLB specific for other drivers as well we
>will add function to pci common.
As far as we know this prob
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
Acked-by: Abdullah Sevincer
Mattias,
Yes that’s correct.
-Original Message-
From: Mattias Rönnblom
Sent: Friday, September 8, 2023 12:28 AM
To: Sevincer, Abdullah ; Stephen Hemminger
; Thomas Monjalon
Cc: dev@dpdk.org; Tyler Retzlaff
Subject: Re: quick thread in DLB2
On 2023-09-08 00:09, Sevincer, Abdullah
Hi Stephen,
It is probing ports for best CPU. Yes it collects cycles. We may rework in the
future.
Open to suggestions.
-Original Message-
From: Stephen Hemminger
Sent: Wednesday, September 6, 2023 12:45 PM
To: Thomas Monjalon
Cc: Sevincer, Abdullah ; dev@dpdk.org; Tyler
Retzlaff
Hi Thomas,
That's right we need to create threads on specific CPUs.
From: Thomas Monjalon
Sent: Friday, September 1, 2023 7:09 AM
To: Sevincer, Abdullah
Cc: dev@dpdk.org ; Tyler Retzlaff
Subject: quick thread in DLB2
Hello Abdullah,
In the DLB2 code, I
Sorry folks this has been waiting for long.
I heard Tim is retiring. Will it be okay to get ack from Bruce?
-Original Message-
From: Sevincer, Abdullah
Sent: Monday, July 10, 2023 12:52 PM
To: Thomas Monjalon
Cc: dev@dpdk.org; jer...@marvell.com; Richardson, Bruce
Subject: RE: [PATCH
>+Is anybody looking into reworking this proposal and moving this code to the
>pci bus driver?
>+Cc: pci bus maintainers.
>+--
>+David Marchand
We will work on this proposal, it is not finalized yet.
Its not DLB2 specific as commenters say, we are looking into if there is
another way doing it
Hi Thomas,
There is one patch needs review, we can remove it if it gets merged.
http://patches.dpdk.org/project/dpdk/patch/20230627132421.1946338-1-abdullah.sevin...@intel.com/
-Original Message-
From: Thomas Monjalon
Sent: Monday, July 31, 2023 7:17 AM
To: Mcnamara, John ; Sevincer
>+Would you be able to get an ack from Timothy?
Thanks Thomas, requested ack from Timothy.
>+Has new coverity issue.
>+The reason is the boolean is set every time because it gets every time.
>+Looks like code goes over eventdev_var[] even if no eventdevs are present.
>+Should only look for the number of eventdevs
Thanks Stephen, I will add a condition at the top of the function like:
>+Acked-by: Reshma Pattan
>+Acked-by: Stephen Hemminger
Reminder!
What's the plan to merge this patch?
>+ I was thinking of helper function and using const strings.
>+ Don't need to panic on invalid eventdev.
>+ Also the flags could be just bitfield to save some space.
>+ Something like this. Untested since I have no hardware with
>+ eventdevs.
Thanks Stephen,
Let me revise more with your sugge
> +The cast will cause truncation of large values, so this might be a nop.
> +If you really want to check, then something like:
> + unsigned long evdev_id;
> + char *endp;
> + evdev_id = strtoul(list, &endp, 0);
> + if (!*list || !*endp || evdev_id >= RTE_EVENT_MAX_DEVS) {
> +
Acked-by: Abdullah Sevincer
-Original Message-
From: Chengwen Feng
Sent: Monday, March 20, 2023 2:21 AM
To: tho...@monjalon.net; ferruh.yi...@amd.com; McDaniel, Timothy
; Sevincer, Abdullah
Cc: dev@dpdk.org
Subject: [PATCH v2 38/44] event/dlb2: fix segment fault when parse devargs
>+Having structure like suggested not only help-s simple data handling but also
>would help for the cases like below , where you need to maintain different
>event ids in the code.
>+With the current patch version the below scenario is not possible as you have
>only one global variable for t
> -Original Message-
> From: Sevincer, Abdullah
> +static uint8_t evdev_id;
> +static uint8_t num_ports;
> +static uint8_t ports[MAX_PORTS_QUEUES];
>+static uint8_t num_queues;
> +static uint8_t queues[MAX_PORTS_QUEUES]; static uint32_t
> +enable_shw_all
+>How about keeping a struct to maintain all the data together that way you
know on which all ports and queues of eventdev we have requested display.
+>You can refer the existing code "struct desc_param" to see how this is done
Then you can declare global variables of type struct eventdev_pa
> +static void
> +get_eventdev_xstats(uint8_t dev_id,
>+You can separate this function (basically the code inside this function) into
>3 functions, one for reset and one for display stats values.
>+And move the common code(stats storage calculation logic and getting stats
>name logic) to a
From: Pattan, Reshma
Sent: Wednesday, March 15, 2023 4:57 AM
To: Sevincer, Abdullah ; dev@dpdk.org
Cc: jer...@marvell.com
Subject: RE: [PATCH v8] app/procinfo: display eventdev xstats
->Why do we need to restrict to only eventdev 0? .I guess you should support
displaying stats for
> >
> > +/* Note: Port_queue_id in xstats APIs is 8 bits, so we have a
> > +maximum of
> > + * 256 ports and queues for event_Dev */ #define MAX_PORTS_QUEUES
> > +256
> > +
>
> >There is a goal of removing the per-queue stats part in generic stats.
> >And in the process removing that limit
From: Stephen Hemminger
Sent: Thursday, March 9, 2023 12:32 PM
To: Sevincer, Abdullah
Cc: dev@dpdk.org; jer...@marvell.com; Pattan, Reshma
Subject: Re: [PATCH v7] app/procinfo: display eventdev xstats
On Thu, 9 Mar 2023 12:27:58 -0600
Abdullah Sevincer wrote:
>
> +/
member the format instead passing
a name. I agree there is too much command in proc-info now. I will try to
simplify command and code also considering something easy to remember from the
users perspective.
Thanks.
-Original Message-
From: Pattan, Reshma
Sent: Friday, March 3, 2023 2:58
:33 AM
To: Sevincer, Abdullah
Cc: dev@dpdk.org; jer...@marvell.com
Subject: Re: [PATCH v3] app/procinfo: display eventdev xstats for PMD data
On Fri, 17 Feb 2023 15:58:52 +
"Sevincer, Abdullah" wrote:
> From: Sevincer, Abdullah
> Sent: Sunday, February 12, 2023 11:44
Hi folks,
Any chance to look at this commit? Any other feedback before I push V6? (will
remove extra line there below in the commit)
-Original Message-
From: Sevincer, Abdullah
Sent: Sunday, February 12, 2023 11:44 AM
To: Stephen Hemminger
Cc: dev@dpdk.org; jer...@marvell.com
opposition.
Thanks,
Abdullah.
-Original Message-
From: Stephen Hemminger
Sent: Monday, February 6, 2023 4:22 PM
To: Sevincer, Abdullah
Cc: dev@dpdk.org; jer...@marvell.com
Subject: Re: [PATCH v3] app/procinfo: display eventdev xstats for PMD data
On Mon, 6 Feb 2023 17:05:05 -0600
Acked: by abdullah.sevin...@intel.com
-Original Message-
From: Morten Brørup
Sent: Thursday, February 9, 2023 8:51 AM
To: dev@dpdk.org; roret...@linux.microsoft.com; rm...@marvell.com; McDaniel,
Timothy ; ma...@nvidia.com; viachesl...@nvidia.com
Cc: ruifeng.w...@arm.com; zhou...@loongso
Not sure these are failing now in RHEL platform, seems fail is unrelated to the
commit, I will check and resubmit new version.
-Original Message-
From: Sevincer, Abdullah
Sent: Wednesday, September 28, 2022 6:33 PM
To: dev@dpdk.org
Cc: jer...@marvell.com; Sevincer, Abdullah
Subject
63 matches
Mail list logo
