Re: [PATCH v1] doc: update release notes for 23.07
21/07/2023 17:24, John McNamara: > Fix grammar, spelling and formatting of DPDK 23.07 release notes. > > Signed-off-by: John McNamara Removed the comments and applied, thanks.
RE: [PATCH v3 0/3] announce bonding macro and function change
A gentle ping~ Could anyone kindly enough give us a 4th 'Acked-by' to make it can be merged into v23.07? Thanks very much! > -Original Message- > From: Chaoyong He > Sent: Tuesday, July 18, 2023 4:29 PM > To: dev@dpdk.org > Cc: oss-drivers ; Niklas Soderlund > ; Chaoyong He > > Subject: [PATCH v3 0/3] announce bonding macro and function change > > In order to support inclusive naming, some of the macro and function in DPDK > will need to be renamed. Do this through deprecation process now for 23.07. > > --- > v3: > * Adjust the statement in 'deprecation.rst' document. > v2: > * Drop the rename of function and data struct in the logics. > --- > > Chaoyong He (2): > doc: announce bonding data change > doc: announce bonding function change > > Long Wu (1): > doc: announce bonding macro change > > app/test-pmd/testpmd.c | 2 +- > doc/guides/rel_notes/deprecation.rst | 17 + > drivers/net/bonding/rte_eth_bond_api.c | 6 +++--- > lib/ethdev/rte_ethdev.h| 5 +++-- > 4 files changed, 24 insertions(+), 6 deletions(-) > > -- > 2.39.1
RE: [PATCH] tap: fix build of tap_bpf_program
> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> > The tap_bpf_program.c is not built as part of normal DPDK
> > EAL environment. It is intended to be built standalone
> > and does not use rte_common.h.
> >
> > This reverts the related change from
> > commit ef5baf3486e0 ("replace packed attributes")
> >
> > Note: this patch will cause expected warnings from checkpatch
> > because the code involved is not used directly in DPDK environment.
> >
> > Signed-off-by: Stephen Hemminger
> >
>
> Agree, this seems done by mistake as part of batch update,
>
> Acked-by: Ferruh Yigit
>
>
> But I can't update the bpf file at all, if I am not missing something I
> >>>
> >>> * I can't *compile* the bpf file ...
> >>>
> am not sure if we should get just this update or have a patch/patchset
> that fixes the build.
>
> @Ophir, how the bpf file is compiled? And did you test it recently?
>
> I am using command from the documentation:
> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> -filetype=obj -o tap_bpf_program.o`
> >>
> >> It looks like this won't work because it was expecting to be able
> >> to find header files from older version of iproute2. These are not
> >> distributed, and the change to support libbpf in iproute2 makes the
> >> current versions not work.
> >>
> >> As a stopgap, will look back in history and see what version of header
> >> files will at least get a working build.
> >>
> >> From there, need to replace how the conversion of .o to array works.
> >> Would prefer to use dlopen() to read the ELF file rather than expecting
> >> developers to hack together their own tools.
> >>
> >> Not sure how much effort is really needed here. This is only being
> >> used for the case of rte_flow with multiq RSS. Probably, no one ever
> >> used it.
> >>
> >
> > Should we remove the file, instead of fixing '__rte_packed'?
> >
>
> +Long, and af_xdp maintainers,
>
> @Long, do you know if this bfp code is still in use somewhere, if so is
> the user interested in fixing/maintaining the code?
>
>
> @Ciara, @Qi, do you see any benefit to keep/extend this kind of bfp file
> usage? Do you think is this something to invest more?
If the code is still being used I would agree with Stephen that using dlopen or
libbpf to load the eBPF code would be preferable. The current steps are
difficult to follow.
RE: [PATCH v3 1/3] doc: announce bonding macro change
> From: Chaoyong He [mailto:chaoyong...@corigine.com] > Sent: Tuesday, 18 July 2023 10.29 > > From: Long Wu > > In order to support inclusive naming, some of the macro in DPDK will > need to be renamed. Do this through deprecation process now for 23.07. > > Signed-off-by: Long Wu > Reviewed-by: Chaoyong He > --- > app/test-pmd/testpmd.c | 2 +- > doc/guides/rel_notes/deprecation.rst | 4 > drivers/net/bonding/rte_eth_bond_api.c | 6 +++--- > lib/ethdev/rte_ethdev.h| 5 +++-- > 4 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c > index c6ad9b18bf..938ca035d4 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -4248,7 +4248,7 @@ uint8_t port_is_bonding_slave(portid_t slave_pid) > slave_pid); We might want to get rid of the term "slave" in function, parameter and variable names in testpmd too. This is not important now, and can be postponed to a later patch. > return 0; > } > - if ((*dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) || (port- > >slave_flag == 1)) > + if ((*dev_info.dev_flags & RTE_ETH_DEV_BONDING_MEMBER) || (port- > >slave_flag == 1)) Can we please standardize on using only "bond" and "BOND" everywhere in this driver, instead of both "bond" (in function names) and "BONDING" (in enum values)? The source code file are also named "rte_eth_bond...", while the directory name is /drivers/net/bonding/. We are about to rename anyway, so let's do it as good as we can. Also, are the bonding and balancing modes defined in /drivers/net/bonding/rte_eth_bond.h missing the RTE_ prefix, or are they private? PS: Sorry about joining the discussion late (and possibly ignoring previous discussions on this). I reacted to the poll for ACKs to this series.
Re: [PATCH] doc: announce changes to event device structures
On Wed, Jul 26, 2023 at 4:35 AM wrote: > > From: Pavan Nikhilesh Please add all eventdev driver and subsystem mainainters. > > The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will be > modified to add new elements to support link profiles. Please describe what profile means here. Meaning the usage model. > > A new field ``max_profiles_per_port`` will be added to > ``rte_event_dev_info`` and ``switch_profile`` will be added to > ``rte_event_fp_ops``. > Two new experimental APIs will be added, one to associate one to > associate an set of event queues with a profile which can be linked > to a event port and another to switch the profile which would > affect the next dequeue call. > > Signed-off-by: Pavan Nikhilesh > --- > 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 fb771a0305..2b1fcf52ca 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -161,3 +161,11 @@ Deprecation Notices >The new port library API (functions rte_swx_port_*) >will gradually transition from experimental to stable status >starting with DPDK 23.07 release. > + > +* eventdev: The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will > be > + modified to add new elements to support link profiles.A new field > + ``max_profiles_per_port`` will be added to ``rte_event_dev_info`` and > + ``switch_profile`` will be added to ``rte_event_fp_ops``. > + Two new experimental APIs will be added, one to associate an set of event > + queues with a profile which can be linked to a event port and an other to > + switch the profile which would affect the next dequeue call. New API additions does not need to mention here. > -- > 2.25.1 >
Re: [PATCH v2] doc: announce single-event enqueue/dequeue ABI change
On Wed, Jul 5, 2023 at 6:30 PM Jerin Jacob wrote: > > On Wed, Jul 5, 2023 at 4:48 PM Mattias Rönnblom > wrote: > > > > Announce the removal of the single-event enqueue and dequeue > > operations from the eventdev ABI. > > > > Signed-off-by: Mattias Rönnblom > > Acked-by: Jerin Jacob + Techboard for review > > > > > > --- > > PATCH v2: Fix commit subject prefix. > > --- > > 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 66431789b0..ca192d838d 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -153,3 +153,11 @@ Deprecation Notices > >The new port library API (functions rte_swx_port_*) > >will gradually transition from experimental to stable status > >starting with DPDK 23.07 release. > > + > > +* eventdev: The single-event (non-burst) enqueue and dequeue > > + operations, used by static inline burst enqueue and dequeue > > + functions in , will be removed in DPDK 23.11. This > > + simplification includes changing the layout and potentially also the > > + size of the public rte_event_fp_ops struct, breaking the ABI. Since > > + these functions are not called directly by the application, the API > > + remains unaffected. > > -- > > 2.34.1 > >
[PATCH v2] doc: announce changes to event device structures
From: Pavan Nikhilesh The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will be modified to add new elements to support link profiles. A new field ``max_profiles_per_port`` will be added to ``rte_event_dev_info`` and ``switch_profile`` will be added to ``rte_event_fp_ops``. A profile is a unique identifier for a set of event queues linked to an event port. The unique identifier spans from 0 to the value advertised in ``rte_event_dev_info.max_profiles_per_port`` - 1. Two new experimental APIs will be added, one to associate a set of event queues with a profile which can be linked to an event port and another to switch the profile which would affect the next dequeue call. Signed-off-by: Pavan Nikhilesh --- v2 Changes: - Add more description to commit log. - Remove experimental API description from deprication.rst. 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 fb771a0305..1c52159673 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -161,3 +161,8 @@ Deprecation Notices The new port library API (functions rte_swx_port_*) will gradually transition from experimental to stable status starting with DPDK 23.07 release. + +* eventdev: The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will be + modified to add new elements to support link profiles.A new field + ``max_profiles_per_port`` will be added to ``rte_event_dev_info`` and + ``switch_profile`` will be added to ``rte_event_fp_ops``. -- 2.25.1
Re: [PATCH v3] tap: fix build of TAP BPF program
On Thu, 20 Jul 2023 16:25:49 -0700
Stephen Hemminger wrote:
> Move the BPF program related code into a subdirectory.
> And add a Makefile for building it.
>
> The code was depending on old versions of headers from iproute2.
> Include those headers here so that build works.
>
> The standalone build was also broken because by
> commit ef5baf3486e0 ("replace packed attributes")
> which introduced __rte_packed into this code.
>
> Add a python program to extract the resulting BPF into
> a format that can be consumed by the TAP driver.
>
> Update the documentation.
>
> Signed-off-by: Stephen Hemminger
Some backstory notes:
0. No longer work for Microsoft, so don't have Azure/Failsafe/TAP setup.
Therefore compile tested only.
1. Went down this rabbit hole while trying to clear some of the DPDK
patch backlog, and ran into this one fix for RSS on fragmented packets
https://patchwork.dpdk.org/project/dpdk/patch/20220420112400.2271-1-madhuker.myt...@oracle.com/
2. This version of patch only makes the BPF program build.
It does not change the BPF program used currently by TAP device.
3. Doing build will change the bpf program since clang is probably
optimizing more now.
Bottom line:
Merging the patch won't fix the RSS bug, it won't change the current TAP
device behavior (same BPF). But it will allow for easier later fix in next
release.
Reminder - DPDK Dublin Summit Registration - Sep. 12-13, 2023
Good afternoon, September 12-13, 2023 we will have the DPDK Summit at the Gibson Hotel in Point Square in Dublin. Once again, registration and attendance for this event are *free!* We have the schedule posted here: https://events.linuxfoundation.org/dpdk-summit/program/schedule/ If you have not already registered for the event, please do so now. *You may do so here:* https://events.linuxfoundation.org/dpdk-userspace-summit/ I would also encourage those who are traveling to Dublin but have not booked flights or accommodations to do so now. Any questions let us know. Thanks, Nathan Nathan C. Southern, Project Coordinator Data Plane Development Kit The Linux Foundation 248.835.4812 (mobile) nsouth...@linuxfoundation.org
[PATCH] net/netvsc: increase VSP response timeout to 60 seconds
From: Long Li The current timeout is set to 5 seconds. In Azure, tests show that it may take up to 15 seconds for VSP to respond on busy nodes. The VSP schedules unbounded work to process VSC resquest, there is no upper limit on how long it takes to send response back to VSC. In the NETVSC kernel mode driver, it waits forever for VSP response. While in DPDK we can't wait forever, setting the timeout to 60 seconds. Cc: sta...@dpdk.org Signed-off-by: Long Li --- drivers/net/netvsc/hn_rndis.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/netvsc/hn_rndis.c b/drivers/net/netvsc/hn_rndis.c index e6f1f28768..7e9abce8d0 100644 --- a/drivers/net/netvsc/hn_rndis.c +++ b/drivers/net/netvsc/hn_rndis.c @@ -35,7 +35,7 @@ #include "hn_rndis.h" #include "ndis.h" -#define RNDIS_TIMEOUT_SEC 5 +#define RNDIS_TIMEOUT_SEC 60 #define RNDIS_DELAY_MS10 #define HN_RNDIS_XFER_SIZE 0x4000 -- 2.17.1
