Re: [PATCH] net/cnxk: fix error when compiled for x86
On Thu, Mar 10, 2022 at 7:06 AM Jiang, YuX wrote:
>
> Hi maintainers,
>
> Who can give acked-by for this patch?
> May I know this patch can be merged into 22.03 or not?
Acked-by: Jerin Jacob
Updated the git commit as follows and applied to
dpdk-next-net-mrvl/for-next-net. Thanks
net/cnxk: fix build error with optimization
Fix the following build error seen with --optimization=1 and
GCC 10.3.0.
../drivers/net/cnxk/cnxk_ethdev_mtr.c: In function
‘cnxk_nix_mtr_policy_validate’:
../lib/ethdev/rte_mtr_driver.h:188:10: error: ‘str’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
../drivers/net/cnxk/cn10k_rx.h:149:2 error: ‘frag_ptr’ may be
used uninitialized in this function
Bugzilla ID: 939
Fixes: b526599020ef ("net/cnxk: fix build with GCC 12")
Cc: sta...@dpdk.org
Reported-by: Ferruh Yigit
Signed-off-by: Rakesh Kudurumalla
Tested-by: Daxue Gao
Acked-by: Jerin Jacob
>
> > -Original Message-
> > From: Rakesh Kudurumalla
> > Sent: 2022年3月4日 22:24
> > To: Nithin Dabilpuram ; Kiran Kumar K
> > ; Sunil Kumar Kori ; Satha
> > Rao
> > Cc: dev@dpdk.org; jer...@marvell.com; Rakesh Kudurumalla
> > ; sta...@dpdk.org; Yigit, Ferruh
> >
> > Subject: [PATCH] net/cnxk: fix error when compiled for x86
> >
> > fix error when compiled for x86 platform when compiled with optimization
> > flag enabled
> > error: ‘str’ may be used uninitialized in this function
> > error: ‘frag_ptr’ may be used uninitialized in this function
> >
> > Bugzilla ID: 939
> > Fixes: b526599020ef ("net/cnxk: fix build with GCC 12")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Ferruh Yigit
> > Signed-off-by: Rakesh Kudurumalla
> > ---
RE: [PATCH] net/af_xdp: fix custom program loading with multiple queues
> When the PMD is configured to load a custom XDP program, it sets
> XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag to prevent libbpf from
> loading its default XDP program. However, when queue_count is set to
> greater than 1, this flag is only set for the first XSK socket but not
> for subsequent XSK sockets. This causes XSK socket creation failure.
>
> This commit ensures that XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag is
> set for all XSK socket creations when custom XDP program is being used.
>
> Fixes: 01fa83c94d7e ("net/af_xdp: workaround custom program loading")
>
> Signed-off-by: Junxiao Shi
Thanks for the patch!
It's probably too late to make it into 22.03 but cc-ing stable as it should be
backported to 21.11.x.
Acked-by: Ciara Loftus
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index 65479138d3..9920f49870 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -1307,18 +1307,19 @@ xsk_configure(struct pmd_internals *internals,
> struct pkt_rx_queue *rxq,
> cfg.bind_flags |= XDP_USE_NEED_WAKEUP;
> #endif
>
> - if (strnlen(internals->prog_path, PATH_MAX) &&
> - !internals->custom_prog_configured) {
> - ret = load_custom_xdp_prog(internals->prog_path,
> -internals->if_index,
> -&internals->map);
> - if (ret) {
> - AF_XDP_LOG(ERR, "Failed to load custom XDP
> program %s\n",
> - internals->prog_path);
> - goto out_umem;
> + if (strnlen(internals->prog_path, PATH_MAX)) {
> + if (!internals->custom_prog_configured) {
> + ret = load_custom_xdp_prog(internals->prog_path,
> + internals->if_index,
> + &internals->map);
> + if (ret) {
> + AF_XDP_LOG(ERR, "Failed to load custom
> XDP program %s\n",
> + internals->prog_path);
> + goto out_umem;
> + }
> + internals->custom_prog_configured = 1;
> }
> - internals->custom_prog_configured = 1;
> - cfg.libbpf_flags =
> XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD;
> + cfg.libbpf_flags |=
> XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD;
> }
>
> if (internals->shared_umem)
> --
> 2.17.1
Re: [PATCH 1/3] net/qede: fix Tx callback completion routine
10/03/2022 08:40, Jerin Jacob: > Updated the git commits as follows and applied series to > dpdk-next-net-mrvl/for-next-net. Thanks What is the intent? Do you want to get them in 22.03? Is it validated enough for a last minute merge?
RE: release candidate 22.03-rc3
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, March 9, 2022 7:44 AM > To: annou...@dpdk.org > Subject: release candidate 22.03-rc3 > > A new DPDK release candidate is ready for testing: > https://git.dpdk.org/dpdk/tag/?id=v22.03-rc3 > > There are 102 new patches in this snapshot. > > Release notes: > https://doc.dpdk.org/guides/rel_notes/release_22_03.html > > This should be the last release candidate. > Only documentation and critical bug fixes are accepted until the release. > > Please test and report issues on bugs.dpdk.org. > You may share some release validation results by replying to this message at > dev@dpdk.org. > > Please think about sharing your roadmap now for DPDK 22.07. > > Thank you everyone > Update the test status for Intel part. Till now dpdk22.03-rc3 test execution rate is 60%. No critical issue is found. There are three bugs which have fix but not been merged into rc3, please review and merge if possible. Bug1, Known issue: https://bugs.dpdk.org/show_bug.cgi?id=939 >It has fix but not merged into rc3, patch is delegate to "Jerin Jacob". Please review and merge if possible. > http://patchwork.dpdk.org/project/dpdk/patch/20220304142337.911828-1-rkuduruma...@marvell.com/ Bug2, Known issue about "dpdk_gso_lib/test_vhost_gso_with_vxlan: VM can't send ICMP packet to host namespace". > it has fix but not merged into rc3, patch is delegate to "Ferruh Yigit". > Please review and merge if possible. > http://patchwork.dpdk.org/project/dpdk/patch/20211229093702.1930214-3-kevinx@intel.com/ Bug3, Known issue about "GRO/GSO feature test need to modify dpdk code" > It has fix but not merged into rc3, patch is delegated to "Maxime Coquelin". > Please review and merge if possible. > https://patches.dpdk.org/project/dpdk/patch/20220217151628.441165-1-wenwux...@intel.com/ # Basic Intel(R) NIC testing * Build or compile: *Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, RHEL8.5 etc. - All test passed. - One known issue https://bugs.dpdk.org/show_bug.cgi?id=928, use "meson setup -Ddisable_drivers=event/cnxk" to build. *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu20.04 and RHEL8.4. - All test done. One known issue is Bug1. * PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - Execution rate is 40%. No new issue is found. * VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - Execution rate is 40%. 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 80%. No new issue is found. * 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 50%. No big performance drop. # 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 7.0u3, etc. - All test done. Two known bugs: Bug2 and Bug3. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - Execution rate is 20%. Two known issues, Intel dev is investigating. *Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. - Execution rate is 20%.
RE: [EXT] Re: [PATCH 1/3] net/qede: fix Tx callback completion routine
> -Original Message- > From: Thomas Monjalon > Sent: Thursday, March 10, 2022 2:26 PM > To: Devendra Singh Rawat ; Jerin Jacob > > Cc: dpdk-dev ; Jerin Jacob Kollanukkaran > ; Ferruh Yigit ; Rasesh Mody > ; Alok Prasad ; dpdk stable > > Subject: [EXT] Re: [PATCH 1/3] net/qede: fix Tx callback completion routine > > External Email > > -- > 10/03/2022 08:40, Jerin Jacob: > > Updated the git commits as follows and applied series to > > dpdk-next-net-mrvl/for-next-net. Thanks > > What is the intent? Do you want to get them in 22.03? > Is it validated enough for a last minute merge? > These are fixes for regressions introduced by few past commits. They are critical for receiving and transmitting traffic on Marvell FastLinQ adapters. We do want them in 22.03. We have completed testing cycles on our end and believe they are good enough to be merged. Thanks, Devendra
RE: [PATCH v4] crypto/ipsec_mb: fix coverity issue
>-Original Message-
>From: Piotr Bronowski
>Sent: Wednesday 9 March 2022 18:02
>To: dev@dpdk.org
>Cc: Zhang, Roy Fan ; tho...@monjalon.net;
>gak...@marvell.com; Yigit, Ferruh ; Doherty, Declan
>; Bronowski, PiotrX
>; sta...@dpdk.org
>Subject: [PATCH v4] crypto/ipsec_mb: fix coverity issue
>
>This patch removes coverity defect CID 375828:
>Untrusted value as argument (TAINTED_SCALAR)
>
>Coverity issue: CID 375828
>
>Fixes: ceb863938708 ("crypto/aesni_gcm: support all truncated digest sizes")
>
>Signed-off-by: Piotr Bronowski
>
>Cc: sta...@dpdk.org
>
>---
>v4: commit message corrected
>---
> drivers/crypto/ipsec_mb/pmd_aesni_gcm.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
Acked-by: Ciara Power
RE: [PATCH] net/mlx5: fix push VLAN action validation
Hi,
> -Original Message-
> From: Dariusz Sosnowski
> Sent: Wednesday, March 9, 2022 11:39 AM
> To: Matan Azrad ; Slava Ovsiienko
> ; Bill Zhou
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix push VLAN action validation
>
> Flow domain and direction was validated when OF_PUSH_VLAN action
> appears in flow actions. Flow was rejected whenever this action:
>
> - was used in NIC domain, in ingress direction;
> - was used in FDB domain, in ingress direction, on ConnectX-5.
>
> This validation logic rejected a valid case when the OF_PUSH_VLAN
> action was used when directing traffic to the hairpin queue,
> configured in TX implicit mode.
>
> This patch moves code responsible for OF_PUSH_VLAN validation of
> domain and direction from flow_dv_validate_push_vlan() to
> flow_dv_validate(). Domain and direction are now validated when either
> non-hairpin queue is used or hairpin queue is configured in Tx explicit
> mode.
>
> Fixes: 96f85ec489db ("net/mlx5: check VLAN push/pop support")
> Cc: dongz...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dariusz Sosnowski
> Acked-by: Viacheslav Ovsiienko
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH] net/mlx5: fix the sample flow failure on the trusted device
Hi,
> -Original Message-
> From: Jiawei(Jonny) Wang
> Sent: Wednesday, March 9, 2022 12:20 PM
> To: Slava Ovsiienko ; Matan Azrad
> ; Ori Kam
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the sample flow failure on the trusted device
>
> The flow with sample action will be split into two sub flows,
> and a tag action was added implicitly in the sample prefix sub flow,
> the reserved metadata regC index was used for this tag action.
>
> The reserved metadata regC was shared with metering action,
> for Connect-5 trusted device(VF/SF), the reserved metadata regC was
> invalid since PF only supported the legacy metering.
>
> This patch adds the checking for the tag index and back to use the
> application tag if a failure happened.
>
> Fixes: a9b6ea45bed6 ("net/mlx5: fix tag ID conflict with sample action")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jiawei Wang
> Acked-by: Viacheslav Ovsiienko
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH v1] net/mlx5: disallow multiple ASO actions in a single flow
Hi,
> -Original Message-
> From: Rongwei Liu
> Sent: Wednesday, March 9, 2022 2:08 PM
> To: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Michael Baum
>
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org; Jack Min
> Subject: [PATCH v1] net/mlx5: disallow multiple ASO actions in a single flow
>
> For now, only one ASO action is supported in a single flow.
> Flow with more than one ASO action should be rejected in the
> validation stage.
>
> Flow with action non-shared AGE and COUNT together should be
> treated as non-ASO because AGE will fall back to use HW counter,
> not ASO hit object.
>
> Group 0 will use HW counter for AGE action even if no COUNT action.
>
> This commit will reject patterns (no matter which group if transfer)
> like:
> 1. group 1 pattern... / end actions age / meter / end
> 2. group 1 pattern... / end actions conntrack / meter / end
> 3. group 1 pattern... / end actions age / conntrack... / end
>
> If AGE comes together with COUNT in the above patterns, it's allowed.
>
> Fixes: daed4b6e ("net/mlx5: use aging by counter when counter exists")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Rongwei Liu
> Acked-by: Xiaoyu Min
> Acked-by: Matan Azrad
> ---
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH v2] doc: fix modify field action description for mlx5
Hi,
> -Original Message-
> From: Slava Ovsiienko
> Sent: Thursday, February 24, 2022 6:02 PM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; Xueming(Steven) Li ;
> Raslan Darawsheh ; Matan Azrad
> ; sta...@dpdk.org
> Subject: [PATCH v2] doc: fix modify field action description for mlx5
>
> This patch adds mlx5 specifics description about handling the Ethernet type
> by modify field action for VLAN-ed traffic.
>
> Fixes: 641dbe4fb053 ("net/mlx5: support modify field flow action")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation
Hi, Thinh
the line: "v2: change patch description, no code change"
should not be in commit message body, it should be after "---"
Besides this:
Acked-by: Viacheslav Ovsiienko
With best regards,
Slava
> -Original Message-
> From: Thinh Tran
> Sent: Wednesday, March 9, 2022 21:49
> To: dev@dpdk.org
> Cc: d...@linux.vnet.ibm.com; Slava Ovsiienko ;
> Raslan Darawsheh ; Dmitry Kozlyuk
> ; Thinh Tran ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation
>
> The default CPU socket ID was used while creating the Rx queue and this
> caused creation failure in case if hardware was not resided on the default
> socket.
>
> The patch sets the correct CPU socket ID for the mlx5_rxq_ctrl before calling
> the mlx5_rxq_create_devx_rq_resources() which eventually calls
> mlx5_devx_rq_create() with correct CPU socket ID.
>
> v2: change patch description, no code change
>
> Fixes: bc5bee028ebc ("net/mlx5: create drop queue using DevX")
> Cc: sta...@dpdk.org
>
>
> Signed-off-by: Thinh Tran
> Reviewed-by: David Christensen
>
> ---
> drivers/net/mlx5/mlx5_devx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/mlx5/mlx5_devx.c b/drivers/net/mlx5/mlx5_devx.c
> index af106bda50..5ab092a259 100644
> --- a/drivers/net/mlx5/mlx5_devx.c
> +++ b/drivers/net/mlx5/mlx5_devx.c
> @@ -947,6 +947,8 @@ mlx5_rxq_devx_obj_drop_create(struct rte_eth_dev
> *dev)
> rte_errno = ENOMEM;
> goto error;
> }
> + /* set the CPU socket ID where the rxq_ctrl was allocated */
> + rxq_ctrl->socket = socket_id;
> rxq_obj->rxq_ctrl = rxq_ctrl;
> rxq_ctrl->is_hairpin = false;
> rxq_ctrl->sh = priv->sh;
> --
> 2.27.0
RE: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation
Hi, > -Original Message- > From: Slava Ovsiienko > Sent: Thursday, March 10, 2022 11:23 AM > To: Thinh Tran ; dev@dpdk.org > Cc: d...@linux.vnet.ibm.com; Raslan Darawsheh ; > Dmitry Kozlyuk ; sta...@dpdk.org > Subject: RE: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation > > Hi, Thinh > > the line: "v2: change patch description, no code change" > should not be in commit message body, it should be after "---" I'll handle this before integration, It's also missing the Ack from Matan from the previous version, I'll add it as well. > Besides this: > Acked-by: Viacheslav Ovsiienko > > With best regards, > Slava > Kindest regards Raslan Darawsheh
RE: [PATCH] examples/vm_power: replace list foreach with while loop
> -Original Message- > From: Thomas Monjalon > 01/03/2022 15:53, Shibin Koikkara Reeny: > > Linux header files don't support LIST_FOREACH_SAFE so replacing > > LIST_FOREACH with while loop. > > What is the original issue you are trying to solve? Asan tool reported LIST_FOREACH should be replaced with LIST_FOREACH_SAFE but Linux don't have LIST_FOREACH_SAFE API. So replacing it with while loop. Regards, Shibin
RE: [EXT] Re: [PATCH] examples/l3fwd: resolve stack buffer overflow issue
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, March 10, 2022 12:37 AM
> To: Rahul Bhansali
> Cc: dev@dpdk.org; david.march...@redhat.com; Conor Walsh
>
> Subject: Re: [EXT] Re: [PATCH] examples/l3fwd: resolve stack buffer overflow
> issue
>
> 09/03/2022 16:24, Rahul Bhansali:
> > Hi Thomas,
> >
> > From: Thomas Monjalon
> > > 11/01/2022 13:50, Rahul Bhansali:
> > > > /* copy rest of the packets into the TX buffer. */
> > > > len = num - n;
> > > > + if (len == 0)
> > > > + goto exit;
> > > > +
> > >
> > > I don't understand how it can fix something.
> > > There is already "while (j < len)" with j and len being 0, the loop
> > > should not be effective in this case.
> >
> > This Switch will execute Case statement first even before considering the
> > while
> condition or anything else before case statement. While condition will be
> executed only after all switch cases are executed.
>
> I don't know this construct. Is it part of the C standard?
> We learn something everyday :)
Yeah, this is new learning for me as well 😊
It’s the way switch works and make it faster than If-else conditions executions
by directly transferring control to respective case first and then do rest of
the things.
Ref document:
https://docs.microsoft.com/en-us/cpp/c-language/switch-statement-c?view=msvc-170
>
> > Hence in case of len = 0 and n > 28, it is throwing stack buffer overflow
> > error.
> >
> > Below is sample code to simulate the while loop behavior inside switch.
> Checked it for both x86 and arm64.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__godbolt.org_z_4Ke
> > cqbsde&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=bm7kwlFq6L5uO69sS-
> 08RKSWPEU
> > tAQMUQjqHDFDtmpY&m=3GLnWHKqJB7pB5Jc36-gFYv-q-
> 3lyEtAFIK3Zt_TMRHhsAGJPIM
> > sAYTAunXt-TCf&s=L93OhPE9w3nl-Tf16rsvJ_OIC9Jar3Q7Be6vX9KfKfc&e=
> >
> > >
> > > > j = 0;
> > > > switch (len % FWDSTEP) {
> > > > while (j < len) {
>
>
>
>
Re: [PATCH] examples/vm_power: replace list foreach with while loop
10/03/2022 10:32, Koikkara Reeny, Shibin: > > -Original Message- > > From: Thomas Monjalon > > 01/03/2022 15:53, Shibin Koikkara Reeny: > > > Linux header files don't support LIST_FOREACH_SAFE so replacing > > > LIST_FOREACH with while loop. > > > > What is the original issue you are trying to solve? > Asan tool reported LIST_FOREACH should be replaced with LIST_FOREACH_SAFE but > Linux don't have LIST_FOREACH_SAFE API. So replacing it with while loop. This explanation should be in the commit log please.
Re: [PATCH] net/af_xdp: fix custom program loading with multiple queues
Hi Ciara/Junxiao,,
On 10/03/2022 08:49, Loftus, Ciara wrote:
When the PMD is configured to load a custom XDP program, it sets
XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag to prevent libbpf from
loading its default XDP program. However, when queue_count is set to
greater than 1, this flag is only set for the first XSK socket but not
for subsequent XSK sockets. This causes XSK socket creation failure.
This commit ensures that XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD flag is
set for all XSK socket creations when custom XDP program is being used.
Fixes: 01fa83c94d7e ("net/af_xdp: workaround custom program loading")
Signed-off-by: Junxiao Shi
Thanks for the patch!
It's probably too late to make it into 22.03 but cc-ing stable as it should be
backported to 21.11.x.
21.11.1 will take backports from 22.03. So it will be in a later 21.11.x
release if it doesn't make 22.03. Please add the 'Cc: sta...@dpdk.com'
tag in the commit message.
Kevin.
Acked-by: Ciara Loftus
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 65479138d3..9920f49870 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -1307,18 +1307,19 @@ xsk_configure(struct pmd_internals *internals,
struct pkt_rx_queue *rxq,
cfg.bind_flags |= XDP_USE_NEED_WAKEUP;
#endif
- if (strnlen(internals->prog_path, PATH_MAX) &&
- !internals->custom_prog_configured) {
- ret = load_custom_xdp_prog(internals->prog_path,
- internals->if_index,
- &internals->map);
- if (ret) {
- AF_XDP_LOG(ERR, "Failed to load custom XDP
program %s\n",
- internals->prog_path);
- goto out_umem;
+ if (strnlen(internals->prog_path, PATH_MAX)) {
+ if (!internals->custom_prog_configured) {
+ ret = load_custom_xdp_prog(internals->prog_path,
+ internals->if_index,
+ &internals->map);
+ if (ret) {
+ AF_XDP_LOG(ERR, "Failed to load custom
XDP program %s\n",
+ internals->prog_path);
+ goto out_umem;
+ }
+ internals->custom_prog_configured = 1;
}
- internals->custom_prog_configured = 1;
- cfg.libbpf_flags =
XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD;
+ cfg.libbpf_flags |=
XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD;
}
if (internals->shared_umem)
--
2.17.1
[PATCH V1] doc: add tested Intel platforms with Intel NICs
Add tested Intel platforms with Intel NICs to v22.03 release note. Signed-off-by: Lingli Chen --- doc/guides/rel_notes/release_22_03.rst | 97 ++ 1 file changed, 97 insertions(+) diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst index 60e5b4f9aa..e33605288a 100644 --- a/doc/guides/rel_notes/release_22_03.rst +++ b/doc/guides/rel_notes/release_22_03.rst @@ -332,3 +332,100 @@ Tested Platforms This section is a comment. Do not overwrite or remove it. Also, make sure to start the actual text at the margin. === + + * Intel\ |reg| platforms with Intel\ |reg| NICs combinations + + * CPU + + * Intel\ |reg| Atom\ |trade| CPU C3758 @ 2.20GHz + * Intel\ |reg| Xeon\ |reg| CPU D-1553N @ 2.30GHz + * Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz + * Intel\ |reg| Xeon\ |reg| CPU E5-2699 v3 @ 2.30GHz + * Intel\ |reg| Xeon\ |reg| CPU E5-2699 v4 @ 2.20GHz + * Intel\ |reg| Xeon\ |reg| Gold 6139 CPU @ 2.30GHz + * Intel\ |reg| Xeon\ |reg| Gold 6140M CPU @ 2.30GHz + * Intel\ |reg| Xeon\ |reg| Gold 6252N CPU @ 2.30GHz + * Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz + * Intel\ |reg| Xeon\ |reg| Platinum 8180 CPU @ 2.50GHz + * Intel\ |reg| Xeon\ |reg| Platinum 8180M CPU @ 2.50GHz + * Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz + * Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz + + * OS: + + * Fedora 35 + * OpenWRT 21.02.1 + * FreeBSD 13.0 + * Red Hat Enterprise Linux Server release 8.4 + * Red Hat Enterprise Linux Server release 8.5 + * Suse 15 SP3 + * Ubuntu 20.04.3 + * Ubuntu 21.10 + + * NICs: + + * Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) + + * Firmware version: 3.22 0x8000d83c 1.3146.0 + * Device id (pf/vf): 8086:1593 / 8086:1889 + * Driver version: 1.8.3_2_g5c2ff303 (ice) + * OS Default DDP: 1.3.28.0 + * COMMS DDP: 1.3.35.0 + * Wireless Edge DDP: 1.3.8.0 + + * Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) + + * Firmware version: 3.20 0x8000d83e 1.3146.0 + * Device id (pf/vf): 8086:1592 / 8086:1889 + * Driver version: 1.8.3_2_g5c2ff303 (ice) + * OS Default DDP: 1.3.28.0 + * COMMS DDP: 1.3.35.0 + * Wireless Edge DDP: 1.3.8.0 + + * Intel\ |reg| 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x61bf0001 + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version(in-tree): 5.1.0-k (ixgbe) + * Driver version(out-tree): 5.13.4 (ixgbe) + + * Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version(PF): 8.30 0x8000a49d 1.2926.0 + * Firmware version(VF): 8.50 0x8000b6d9 1.3082.0 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 2.17.15 (i40e) + + * Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (2x10G) + + * Firmware version: 5.50 0x80003327 1.3082.0 + * Device id (pf/vf): 8086:37d0 / 8086:37cd + * Driver version(out-tree): 2.17.15 (i40e) + * Driver version(in-tree): 2.8.20-k (i40e) + + * Intel\ |reg| Corporation Ethernet Connection X722 for 10GBASE-T + + * Firmware version: 5.50 0x800032e0 1.2935.0 + * Device id (pf/vf): 8086:37d2 / 8086:37cd + * Driver version(out-tree): 2.17.15 (i40e) + * Driver version(in-tree): 2.8.20-k (i40e) + + * Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) + + * Firmware version(PF): 8.30 0x8000a483 1.2926.0 + * Firmware version(VF): 8.50 0x8000b703 1.3082.0 + * Device id (pf/vf): 8086:158b / 8086:154c + * Driver version: 2.17.15 (i40e) + + * Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + * Firmware version(PF): 8.30 0x8000a4ae 1.2926.0 + * Firmware version(VF): 8.50 0x8000b6c7 1.3082.0 + * Device id (pf/vf): 8086:1583 / 8086:154c + * Driver version: 2.17.15 (i40e) + + * Intel\ |reg| Ethernet Converged Network Adapter X710-T2L + + * Firmware version: 8.30 0x8000a489 1.2879.0 + * Device id (pf): 8086:15ff + * Driver version: 2.17.15 (i40e) -- 2.25.1
Re: [PATCH v2] app/testpmd : fix testpmd quit error
On 3/9/2022 10:10 AM, Wu, WenxuanX wrote:
-Original Message-
From: Yigit, Ferruh
Sent: 2022年3月5日 0:19
To: Wu, WenxuanX ; Yang, Qiming
; Zhang, Qi Z ; Li, Xiaoyun
; Singh, Aman Deep ;
Zhang, Yuying
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] app/testpmd : fix testpmd quit error
On 3/4/2022 2:37 AM, wenxuanx...@intel.com wrote:
From: wenxuan wu
When testpmd use func get_eth_dev_info() while related resource had
been released.
Is 'eth_dev_info_get_print_err()' fails at this stage?
What resource is released, the 'slave_port' itself?
Yeah, 1PF ,2VF_repr.
Close port pf ,ok.
Close port vf , error.
In port_close() func,
Is_bonding_slave() call eth_dev_info_get_print_err() to confirm whether it
is a slave or not , but when port is a vf port ,and pf had been released, this
eth_dev_info_get_print_err(vf_id) would read a freed memory ,result in this bug.
I see the intention now, as rephrase:
When PF closed first, ethdev calls to VFs will fail,
in this case 'eth_dev_info_get_print_err()' fails
if it is called for VF when its PF is closed.
I think this approach is hack, more proper option can be
PF port refuse to close when there are outstanding VF ports
but this is more work.
For quick fix perhaps we can continue with first version
of your patch, which closes the ports in reverse order.
It has its shortcomings as we have discussed in that version,
but better than this approach and it cover most of the cases
properly.
But please add comment for intention of the change
and that it may not fix all cases clearly in the code.
And there may be another logic wrong, it shouldn't try to detect if a released
port is bonding port or not.
Change the logic of func port_is_bonding_slave, this func
eth_dev_info_get_print_err while pf is released would result in this
error. Use ports instead to avoid this bug.
This relies to application level stored value to decide about port, not sure if
this is reliable.
Fixes: 0a0821bcf312 ("app/testpmd: remove most uses of internal ethdev
array")
Cc: sta...@dpdk.org
Signed-off-by: wenxuan wu
---
app/test-pmd/testpmd.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
e1da961311..37038c9183 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3824,19 +3824,9 @@ void clear_port_slave_flag(portid_t slave_pid)
uint8_t port_is_bonding_slave(portid_t slave_pid)
{
struct rte_port *port;
- struct rte_eth_dev_info dev_info;
- int ret;
port = &ports[slave_pid];
- ret = eth_dev_info_get_print_err(slave_pid, &dev_info);
- if (ret != 0) {
- TESTPMD_LOG(ERR,
- "Failed to get device info for port id %d,"
- "cannot determine if the port is a bonded slave",
- slave_pid);
- return 0;
- }
- if ((*dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) || (port-
slave_flag == 1))
+ if ((*port->dev_info.dev_flags & RTE_ETH_DEV_BONDED_SLAVE) ||
+(port->slave_flag == 1))
return 1;
return 0;
}
RE: [PATCH v4 0/3] ixgbe SFP handling fixes
> -Original Message- > From: Jeff Daly > Sent: Monday, February 28, 2022 11:30 PM > To: dev@dpdk.org > Subject: [PATCH v4 0/3] ixgbe SFP handling fixes > > Hello all, > > We have several platforms based on Intel's C3000 series of SoCs that have > integrated ixgbe devices (X550EM) operating in the "Native SFI" > mode (the 0x15c4 device ID). > > This set of patches address issues with detection and hotplug of SPFs. This > is the > first of a series of patches to refactor the initial work that Stephen Douthit > submitted last year, splitting the issues into separate logical series. > > --- > v3: > * Moved code back out of base. > > v4: > * Revert accidental tabification > > Jeff Daly (2): > net/ixgbe: Limit SDP3 check of TX_DISABLE to appropriate devices > net/ixgbe: Fix SFP detection and linking on hotplug For the above 2 patches, some internal investigation is still ongoing, have to defer them to the next release. > > Stephen Douthit (1): > net/ixgbe: Fix ixgbe_is_sfp() to return valid result for X550EM_a devs > > drivers/net/ixgbe/ixgbe_ethdev.c | 516 --- > drivers/net/ixgbe/ixgbe_ethdev.h | 14 +- > 2 files changed, 408 insertions(+), 122 deletions(-) > > -- > 2.25.1
[PATCH v2 0/8] Linux GSG doc updates
This patchset contains a number of small documentation improvements for the linux GSG, spread across a few sections. V2: Include additional patches removing or shortening content from the "Enabling Additional Functionality" section Bruce Richardson (8): doc/linux_gsg: add driver guides to document list doc/linux_gsg: drop note about old chipset doc/linux_gsg: remove duplicated note doc/linux_gsg: merge requirements section for app building doc/linux_gsg: expand list of directories doc/linux_gsg: shorten details on HPET use doc/linux_gsg: drop reference to KNI doc/linux_gsg: remove section on IOMMU pass-through doc/guides/linux_gsg/build_dpdk.rst| 13 +++- doc/guides/linux_gsg/enable_func.rst | 102 ++--- doc/guides/linux_gsg/intro.rst | 25 ++ doc/guides/linux_gsg/linux_drivers.rst | 2 +- doc/guides/linux_gsg/sys_reqs.rst | 38 +++-- 5 files changed, 70 insertions(+), 110 deletions(-) -- 2.32.0
[PATCH v2 1/8] doc/linux_gsg: add driver guides to document list
The document roadmap section was missing any mention of the individual drivers guides which are important for users. Add them to list. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/intro.rst | 25 + 1 file changed, 25 insertions(+) diff --git a/doc/guides/linux_gsg/intro.rst b/doc/guides/linux_gsg/intro.rst index 890169e97f..ea98ac7425 100644 --- a/doc/guides/linux_gsg/intro.rst +++ b/doc/guides/linux_gsg/intro.rst @@ -34,3 +34,28 @@ The following is a list of DPDK documents in the suggested reading order: * Sample Applications User Guide: Describes a set of sample applications. Each chapter describes a sample application that showcases specific functionality and provides instructions on how to compile, run and use the sample application. + +* Driver Reference Guides: Provides details on each driver inside a particular category. +Separate guides exist for each of: + +* Baseband devices + +* Compression devices + +* Cryptographic accelerator devices + +* DMA devices + +* Event-based scheduling devices + +* General purpose GPU devices + +* Mempool drivers + +* Network (NIC) devices + +* "Raw" devices i.e. those not fitting into any other category + +* Regular expression devices + +* vDPA (vhost data path acceleration) devices \ No newline at end of file -- 2.32.0
[PATCH v2 2/8] doc/linux_gsg: drop note about old chipset
The chipsets referenced in the note[1] were all launched in 2012 and are now discontinued, so we can drop the note about them at this stage. [1] https://ark.intel.com/content/www/us/en/ark/products/codename/44946/products-formerly-cave-creek.html Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 5 - 1 file changed, 5 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index 9dccd54d9c..6f8799504a 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -8,11 +8,6 @@ System Requirements This chapter describes the packages required to compile the DPDK. -.. note:: - -If the DPDK is being used on an Intel\ |reg| Communications Chipset 89xx Series platform, -please consult the *Intel\ |reg| Communications Chipset 89xx Series Software for Linux Getting Started Guide*. - BIOS Setting Prerequisite on x86 -- 2.32.0
[PATCH v2 3/8] doc/linux_gsg: remove duplicated note
A note about secure boot not allowing uio is present in both the system requirements section and the driver binding section. This fits better in the driver binding section, so the copy in system requirements can be removed. The document in general now also emphasises vfio over uio more than when this note was first added, reducing the need for this warning to be repeated. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index 6f8799504a..df367742cc 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -17,13 +17,6 @@ and high performance of small packets, BIOS setting changes may be needed. Consult the section on :ref:`Enabling Additional Functionality ` for more information on the required changes. -.. note:: - - If UEFI secure boot is enabled, the Linux kernel may disallow the use of - UIO on the system. Therefore, devices for use by DPDK should be bound to the - ``vfio-pci`` kernel module rather than ``igb_uio`` or ``uio_pci_generic``. - For more details see :ref:`linux_gsg_binding_kernel`. - Compilation of the DPDK --- -- 2.32.0
[PATCH v2 4/8] doc/linux_gsg: merge requirements section for app building
When building end-applications linked with DPDK, the only additional tool needed is pkg-config/pkgconf. However, the standard development tools meta-packages on most distro's include this as standard, meaning it does not really require its own section. The one outlier in the existing text is "alpine" where it is not present when using "libc-dev" target. However, changing "gcc" and "libc-dev" to "alpine-sdk" metapackage aligns alpine with the other distros in this regard. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/sys_reqs.rst | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index df367742cc..08d45898f0 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -27,11 +27,19 @@ Compilation of the DPDK The setup commands and installed packages needed on various systems may be different. For details on Linux distributions and the versions tested, please consult the DPDK Release Notes. -* General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+). +* General development tools including a supported C compiler such as gcc (version 4.9+) or clang (version 3.4+), +and ``pkg-config`` or ``pkgconf`` to be used when building end-user binaries against DPDK. * For RHEL/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"`` * For Ubuntu/Debian systems these can be installed using ``apt install build-essential`` -* For Alpine Linux, ``apk add gcc libc-dev bsd-compat-headers libexecinfo-dev`` +* For Alpine Linux, ``apk add alpine-sdk bsd-compat-headers libexecinfo-dev`` + +.. note:: + + pkg-config 0.27, supplied with RHEL-7, + does not process the Libs.private section correctly, + resulting in statically linked applications not being linked properly. + Use an updated version of ``pkg-config`` or ``pkgconf`` instead when building applications * Python 3.5 or later. @@ -87,20 +95,6 @@ For poll-mode drivers, the additional dependencies for each driver can be found in that driver's documentation in the relevant DPDK guide document, e.g. :doc:`../nics/index` - -Building DPDK Applications --- - -The tool pkg-config or pkgconf, integrated in most build systems, -must be used to parse options and dependencies from libdpdk.pc. - -.. note:: - - pkg-config 0.27, supplied with RHEL-7, - does not process the Libs.private section correctly, - resulting in statically linked applications not being linked properly. - - Running DPDK Applications - -- 2.32.0
[PATCH v2 5/8] doc/linux_gsg: expand list of directories
Not all directories were given in the GSG document, but many of those omitted would be of interest to users, e.g. "doc", "license" and "usertools" directories. Adding these leaves only "devtools", and "kernel" as the only undocumented directories, so add them in too for completeness. When updating the section, add "including" to the line leading up to the directory list, indicating that, while the list is currently complete, it is not guaranteed to always be. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/build_dpdk.rst | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst index 0b08492ca2..4f2def15ed 100644 --- a/doc/guides/linux_gsg/build_dpdk.rst +++ b/doc/guides/linux_gsg/build_dpdk.rst @@ -16,7 +16,11 @@ First, uncompress the archive and move to the uncompressed DPDK source directory tar xJf dpdk-.tar.xz cd dpdk- -The DPDK is composed of several directories: +The DPDK is composed of several directories, including: + +* doc: DPDK Documentation + +* license: DPDK license information * lib: Source code of DPDK libraries @@ -28,6 +32,13 @@ The DPDK is composed of several directories: * config, buildtools: Framework-related scripts and configuration +* usertools: Utility scripts for end-users of DPDK applications + +* devtools: Scripts for use by DPDK developers + +* kernel: Kernel modules needed for some operating systems + + Compiling and Installing DPDK System-wide - -- 2.32.0
[PATCH v2 6/8] doc/linux_gsg: shorten details on HPET use
As best we can tell, the HPET timers are not commonly used, so there is little need to give extensive detail and commentry on them in the Linux GSG. As such, we can reduce the GSG section to just a single subsection and also move it down the page below items which are likely of greater importance. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/enable_func.rst | 80 ++-- 1 file changed, 27 insertions(+), 53 deletions(-) diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst index b5c4c652d7..0036c542f5 100644 --- a/doc/guides/linux_gsg/enable_func.rst +++ b/doc/guides/linux_gsg/enable_func.rst @@ -8,59 +8,6 @@ Enabling Additional Functionality = -.. _High_Precision_Event_Timer: - -High Precision Event Timer (HPET) Functionality - -BIOS Support - - -The High Precision Timer (HPET) must be enabled in the platform BIOS if the HPET is to be used. -Otherwise, the Time Stamp Counter (TSC) is used by default. -The BIOS is typically accessed by pressing F2 while the platform is starting up. -The user can then navigate to the HPET option. On the Crystal Forest platform BIOS, the path is: -**Advanced -> PCH-IO Configuration -> High Precision Timer ->** (Change from Disabled to Enabled if necessary). - -On a system that has already booted, the following command can be issued to check if HPET is enabled:: - - grep hpet /proc/timer_list - -If no entries are returned, HPET must be enabled in the BIOS (as per the instructions above) and the system rebooted. - -Linux Kernel Support - - -The DPDK makes use of the platform HPET timer by mapping the timer counter into the process address space, and as such, -requires that the ``HPET_MMAP`` kernel configuration option be enabled. - -.. warning:: - -On Fedora, and other common distributions such as Ubuntu, the ``HPET_MMAP`` kernel option is not enabled by default. -To recompile the Linux kernel with this option enabled, please consult the distributions documentation for the relevant instructions. - -Enabling HPET in the DPDK - - -By default, HPET support is disabled in the DPDK build configuration files. -To use HPET, use the following meson build option which will enable the HPET settings at compile time:: - - meson configure -Duse_hpet=true - -For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls, -and optionally to make the HPET the default time source for the rte_timer library, -the new ``rte_eal_hpet_init()`` API call should be called at application initialization. -This API call will ensure that the HPET is accessible, returning an error to the application if it is not, -for example, if ``HPET_MMAP`` is not enabled in the kernel. -The application can then determine what action to take, if any, if the HPET is not available at run-time. - -.. note:: - -For applications that require timing APIs, but not the HPET timer specifically, -it is recommended that the ``rte_get_timer_cycles()`` and ``rte_get_timer_hz()`` API calls be used instead of the HPET-specific APIs. -These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to ``rte_eal_hpet_init()``, -if any, and on what is available on the system at runtime. - .. _Running_Without_Root_Privileges: Running DPDK Applications Without Root Privileges @@ -154,6 +101,33 @@ the following should be added to the kernel parameter list: isolcpus=2,4,6 +.. _High_Precision_Event_Timer: + +High Precision Event Timer (HPET) Functionality +--- + +DPDK can support the system HPET as a timer source rather than the system default timers, +such as the core Time-Stamp Counter (TSC) on x86 systems. +To enable HPET support in DPDK: + +1. Ensure that HPET is enabled in BIOS settings. +2. Enable ``HPET_MMAP`` support in kernel configuration. + Note that this my involve doing a kernel rebuild, + as many common linux distributions do *not* have this setting enabled by default in their kernel builds. +3. Enable DPDK support for HPET by using the build-time meson option ``use_hpet``, + for example, ``meson configure -Duse_hpet=true`` + +For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls, +and optionally to make the HPET the default time source for the rte_timer library, +the ``rte_eal_hpet_init()`` API call should be called at application initialization. +This API call will ensure that the HPET is accessible, returning an error to the application if it is not. + +For applications that require timing APIs, but not the HPET timer specifically, +it is recommended that the ``rte_get_timer_cycles()`` and ``rte_get_timer_hz()`` API calls be used instead of the HPET-specific APIs. +These g
[PATCH v2 7/8] doc/linux_gsg: drop reference to KNI
The KNI library is disabled by default in DPDK and is already documented in the programmers guide and also in the sample application guide. There are also in-kernel alternatives to it. Therefore, we can drop the (already fairly minimal) reference to it from the Linux GSG. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/enable_func.rst | 13 - 1 file changed, 13 deletions(-) diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst index 0036c542f5..1f19842ddc 100644 --- a/doc/guides/linux_gsg/enable_func.rst +++ b/doc/guides/linux_gsg/enable_func.rst @@ -128,19 +128,6 @@ These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to ``rte_eal_hpet_init()``, if any, and on what is available on the system at runtime. -Loading the DPDK KNI Kernel Module --- - -To run the DPDK Kernel NIC Interface (KNI) sample application, an extra kernel module (the kni module) must be loaded into the running kernel. -The module is found in the kernel/linux sub-directory of the DPDK build directory. -It should be loaded using the insmod command:: - - insmod /kernel/linux/kni/rte_kni.ko - -.. note:: - - See the "Kernel NIC Interface Sample Application" chapter in the *DPDK Sample Applications User Guide* for more details. - Using Linux IOMMU Pass-Through to Run DPDK with Intel\ |reg| VT-d -- -- 2.32.0
[PATCH v2 8/8] doc/linux_gsg: remove section on IOMMU pass-through
The "Linux Drivers" section of the GSG already notes that, for use of UIO, the IOMMU must be disabled or put into pass-through mode. Therefore, there is no need to duplicate this information in the "additional functionality" section. Also the kernel configuration options documented in the section are enabled as standard on all common distro kernels, so the information should not be needed in a GSG doc. Signed-off-by: Bruce Richardson --- doc/guides/linux_gsg/enable_func.rst | 19 --- doc/guides/linux_gsg/linux_drivers.rst | 2 +- 2 files changed, 1 insertion(+), 20 deletions(-) diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst index 1f19842ddc..338c33290b 100644 --- a/doc/guides/linux_gsg/enable_func.rst +++ b/doc/guides/linux_gsg/enable_func.rst @@ -127,22 +127,3 @@ it is recommended that the ``rte_get_timer_cycles()`` and ``rte_get_timer_hz()`` These generic APIs can work with either TSC or HPET time sources, depending on what is requested by an application call to ``rte_eal_hpet_init()``, if any, and on what is available on the system at runtime. - -Using Linux IOMMU Pass-Through to Run DPDK with Intel\ |reg| VT-d --- - -To enable Intel\ |reg| VT-d in a Linux kernel, a number of kernel configuration options must be set. These include: - -* ``IOMMU_SUPPORT`` - -* ``IOMMU_API`` - -* ``INTEL_IOMMU`` - -In addition, to run the DPDK with Intel\ |reg| VT-d, the ``iommu=pt`` kernel parameter must be used when using ``igb_uio`` driver. -This results in pass-through of the DMAR (DMA Remapping) lookup in the host. -Also, if ``INTEL_IOMMU_DEFAULT_ON`` is not set in the kernel, the ``intel_iommu=on`` kernel parameter must be used too. -This ensures that the Intel IOMMU is being initialized as expected. - -Please note that while using ``iommu=pt`` is compulsory for ``igb_uio`` driver, -the ``vfio-pci`` driver can actually work with both ``iommu=pt`` and ``iommu=on``. diff --git a/doc/guides/linux_gsg/linux_drivers.rst b/doc/guides/linux_gsg/linux_drivers.rst index 03cf264a0a..2e4c80ebd3 100644 --- a/doc/guides/linux_gsg/linux_drivers.rst +++ b/doc/guides/linux_gsg/linux_drivers.rst @@ -367,7 +367,7 @@ It can be loaded as shown below: .. note:: - If the devices used for DPDK are bound to the ``uio_pci_generic`` kernel module, + If the devices used for DPDK are bound to a UIO-based kernel module, please make sure that the IOMMU is disabled or is in passthrough mode. One can add ``intel_iommu=off`` or ``amd_iommu=off`` or ``intel_iommu=on iommu=pt`` in GRUB command line on x86_64 systems, -- 2.32.0
[PATCH 1/2] vhost: fix queue number check when setting inflight FD
From: Chenbo Xia
In function vhost_user_set_inflight_fd, queue number in inflight
message is used to access virtqueue. However, queue number could
be larger than VHOST_MAX_VRING and cause write OOB as this number
will be used to write inflight info in virtqueue structure. This
patch checks the queue number to avoid the issue and also make
sure virtqueues are allocated before setting inflight information.
Fixes: ad0a4ae491fe ("vhost: checkout resubmit inflight information")
Cc: sta...@dpdk.org
Reported-by: Wenxiang Qian
Signed-off-by: Chenbo Xia
---
lib/vhost/vhost_user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 589b950458..1ec4357bee 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2883,6 +2883,9 @@ vhost_user_check_and_alloc_queue_pair(struct virtio_net
*dev,
case VHOST_USER_SET_VRING_ADDR:
vring_idx = ctx->msg.payload.addr.index;
break;
+ case VHOST_USER_SET_INFLIGHT_FD:
+ vring_idx = ctx->msg.payload.inflight.num_queues - 1;
+ break;
default:
return 0;
}
--
2.23.0
[PATCH 2/2] vhost: fix FD leak with inflight messages
Even if unlikely, a buggy vhost-user master might attach fds to inflight
messages. Add checks like for other types of vhost-user messages.
Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
lib/vhost/vhost_user.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 1ec4357bee..1d390677fa 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -1602,6 +1602,9 @@ vhost_user_get_inflight_fd(struct virtio_net **pdev,
int numa_node = SOCKET_ID_ANY;
void *addr;
+ if (validate_msg_fds(dev, ctx, 0) != 0)
+ return RTE_VHOST_MSG_RESULT_ERR;
+
if (ctx->msg.size != sizeof(ctx->msg.payload.inflight)) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid get_inflight_fd message
size is %d\n",
dev->ifname, ctx->msg.size);
@@ -1699,6 +1702,9 @@ vhost_user_set_inflight_fd(struct virtio_net **pdev,
int fd, i;
int numa_node = SOCKET_ID_ANY;
+ if (validate_msg_fds(dev, ctx, 1) != 0)
+ return RTE_VHOST_MSG_RESULT_ERR;
+
fd = ctx->fds[0];
if (ctx->msg.size != sizeof(ctx->msg.payload.inflight) || fd < 0) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid set_inflight_fd message
size is %d,fd is %d\n",
--
2.23.0
UDP-GRO not working
Hi , I tried using the UDP GRO feature in DPDK recently and it did not see working. I understand the GRO for UDP is applicable only for fragmented packets, there is the following check in gro_udp4.c /* * Don't process non-fragment packet. */ if (!is_ipv4_fragment(ipv4_hdr)) return -1; There looks to be some conflict in the definition of RTE_PTYPE in rte_mbuf_ptype.h and the usage of this in GRO layer, rte_gro.c The below are the definitions, #define RTE_PTYPE_L4_TCP0x0100 #define RTE_PTYPE_L4_UDP0x0200 #define RTE_PTYPE_L4_FRAG 0x0300 Below is the check in GRO layer, #define IS_IPV4_TCP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ ((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP) && \ (RTE_ETH_IS_TUNNEL_PKT(ptype) == 0)) #define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP) && \ (RTE_ETH_IS_TUNNEL_PKT(ptype) == 0)) So, for a fragmented UDP packet both RTE_PTYPE_L4_TCP & RTE_PTYPE_L4_UDP would be set and the GRO layer would be unable to interpret the packet type correctly. I am using rte_net_get_ptype API before the packet is being sent to the GRO subsystem as the DPDK PMD for the NIC I am using would not set the packet types as required by the GRO subsystem. I would like to contribute a patch for this bug if this indeed is an issue, I was thinking if the GRO subsystem is L4 fragmented then in the GRO layer invoked the appropriate handler, either gro_tcp4_reassemble or gro_ud4_reassemble. Please let me know if I am missing something here. Thanks, Param.
Re: [PATCH 2/2] vhost: fix FD leak with inflight messages
On 3/10/22 13:50, David Marchand wrote:
Even if unlikely, a buggy vhost-user master might attach fds to inflight
messages. Add checks like for other types of vhost-user messages.
Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
lib/vhost/vhost_user.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 1ec4357bee..1d390677fa 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -1602,6 +1602,9 @@ vhost_user_get_inflight_fd(struct virtio_net **pdev,
int numa_node = SOCKET_ID_ANY;
void *addr;
+ if (validate_msg_fds(dev, ctx, 0) != 0)
+ return RTE_VHOST_MSG_RESULT_ERR;
+
if (ctx->msg.size != sizeof(ctx->msg.payload.inflight)) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid get_inflight_fd message size is
%d\n",
dev->ifname, ctx->msg.size);
@@ -1699,6 +1702,9 @@ vhost_user_set_inflight_fd(struct virtio_net **pdev,
int fd, i;
int numa_node = SOCKET_ID_ANY;
+ if (validate_msg_fds(dev, ctx, 1) != 0)
+ return RTE_VHOST_MSG_RESULT_ERR;
+
fd = ctx->fds[0];
if (ctx->msg.size != sizeof(ctx->msg.payload.inflight) || fd < 0) {
VHOST_LOG_CONFIG(ERR, "(%s) invalid set_inflight_fd message size is
%d,fd is %d\n",
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [PATCH 1/2] vhost: fix queue number check when setting inflight FD
On 3/10/22 13:50, David Marchand wrote:
From: Chenbo Xia
In function vhost_user_set_inflight_fd, queue number in inflight
message is used to access virtqueue. However, queue number could
be larger than VHOST_MAX_VRING and cause write OOB as this number
will be used to write inflight info in virtqueue structure. This
patch checks the queue number to avoid the issue and also make
sure virtqueues are allocated before setting inflight information.
Fixes: ad0a4ae491fe ("vhost: checkout resubmit inflight information")
Cc: sta...@dpdk.org
Reported-by: Wenxiang Qian
Signed-off-by: Chenbo Xia
---
lib/vhost/vhost_user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 589b950458..1ec4357bee 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2883,6 +2883,9 @@ vhost_user_check_and_alloc_queue_pair(struct virtio_net
*dev,
case VHOST_USER_SET_VRING_ADDR:
vring_idx = ctx->msg.payload.addr.index;
break;
+ case VHOST_USER_SET_INFLIGHT_FD:
+ vring_idx = ctx->msg.payload.inflight.num_queues - 1;
+ break;
default:
return 0;
}
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
[PATCH] net/mlx5: fix FD configuration for Rx interrupt
The mlx5_rx_intr_vec_enable() function allocates queue vector and fill
FD list for Rx interrupts.
The driver wrongly configured the FD with a non-blocking flag which
prevent waiting on this FD.
This patch removes O_NONBLOCK flag adding.
Fixes: 3c7d44af252a ("net/mlx5: support user space Rx interrupt event")
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_rxq.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index f16795bac3..b38505b85c 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1075,7 +1075,6 @@ mlx5_rx_intr_vec_enable(struct rte_eth_dev *dev)
/* This rxq obj must not be released in this function. */
struct mlx5_rxq_priv *rxq = mlx5_rxq_get(dev, i);
struct mlx5_rxq_obj *rxq_obj = rxq ? rxq->ctrl->obj : NULL;
- int rc;
/* Skip queues that cannot request interrupts. */
if (!rxq_obj || (!rxq_obj->ibv_channel &&
@@ -1097,23 +1096,10 @@ mlx5_rx_intr_vec_enable(struct rte_eth_dev *dev)
rte_errno = ENOMEM;
return -rte_errno;
}
- rc = mlx5_os_set_nonblock_channel_fd(rxq_obj->fd);
- if (rc < 0) {
- rte_errno = errno;
- DRV_LOG(ERR,
- "port %u failed to make Rx interrupt file"
- " descriptor %d non-blocking for queue index"
- " %d",
- dev->data->port_id, rxq_obj->fd, i);
- mlx5_rx_intr_vec_disable(dev);
- return -rte_errno;
- }
-
if (rte_intr_vec_list_index_set(intr_handle, i,
RTE_INTR_VEC_RXTX_OFFSET + count))
return -rte_errno;
- if (rte_intr_efds_index_set(intr_handle, count,
- rxq_obj->fd))
+ if (rte_intr_efds_index_set(intr_handle, count, rxq_obj->fd))
return -rte_errno;
count++;
}
--
2.25.1
RE: release candidate 22.03-rc3
Hi, > -Original Message- > From: NBU-Contact-Thomas Monjalon (EXTERNAL) > Sent: Wednesday, March 9, 2022 1:44 AM > To: annou...@dpdk.org > Subject: release candidate 22.03-rc3 > > A new DPDK release candidate is ready for testing: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F > %2Fgit.dpdk.org%2Fdpdk%2Ftag%2F%3Fid%3Dv22.03- > rc3&data=04%7C01%7Calialnu%40nvidia.com%7C500a9ec12575481ac7e5 > 08da015d861a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637823 > 798456345595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EB4Z > nNB%2BC2CF9kY9VtAKuUxHtv%2FE1%2ByRnhweHevzHY0%3D&reserve > d=0 > > There are 102 new patches in this snapshot. > > Release notes: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F > %2Fdoc.dpdk.org%2Fguides%2Frel_notes%2Frelease_22_03.html&data > =04%7C01%7Calialnu%40nvidia.com%7C500a9ec12575481ac7e508da015d861a > %7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637823798456345595 > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sZg27gOt6uYlXJFrgK > NG451JsrgsHYEtMb9rU%2F%2FaLVs%3D&reserved=0 > > This should be the last release candidate. > Only documentation and critical bug fixes are accepted until the release. > > Please test and report issues on bugs.dpdk.org. > You may share some release validation results by replying to this message at > dev@dpdk.org. > > Please think about sharing your roadmap now for DPDK 22.07. > > Thank you everyone > The following is a list of tests that we ran on NVIDIA hardware this release: - Basic functionality: Send and receive multiple types of traffic. - testpmd xstats counter test. - testpmd timestamp test. - Changing/checking link status through testpmd. - RTE flow tests: Items: - conntrack - ecpri - eth - flex - geneve - geneve_opt - gre - gre_key - gre_option - gtp - gtp_psc - icmp - icmp6 - integrity - ipv4 - ipv6 - ipv6_frag_ext - mark - meta - mpls - nvgre - phy_port - port_id - tag - tcp - udp - vlan - vxlan - vxlan_gpe Actions: - age - conntrack - count - dec_tcp_ack - dec_tcp_seq - dec_ttl - drop - flag - inc_tcp_ack - inc_tcp_seq - jump - mark - meter - modify_field - nvgre_decap - nvgre_encap - of_pop_vlan - of_push_vlan - of_set_vlan_pcp - of_set_vlan_vid - port_id - queue - raw_decap - raw_encap - represented_port - rss - sample - set_ipv4_dscp - set_ipv4_dst - set_ipv4_src - set_ipv6_dscp - set_ipv6_dst - set_ipv6_src - set_mac_dst - set_mac_src - set_meta - set_tag - set_tp_dst - set_tp_src - set_ttl - vxlan_decap - vxlan_encap - Some RSS tests. - VLAN filtering, stripping and insertion tests. - Checksum and TSO tests. - ptype tests. - link_status_interrupt example application tests. - l3fwd-power example application tests. - Multi-process example applications tests. - Hardware LRO tests. - Regex application tests. - Buffer Split tests. - Tx scheduling tests. - One known issue: https://bugs.dpdk.org/show_bug.cgi?id=938 [TAP] testpmd crashed after stopping ports PS: We are internally investigating a few test failures, and we'll send fixes if necessary. Thanks, Wael Abualrub
[PATCH] app/testpmd: fix GTP header parsing in csum FWD engine
GTP header can be followed by an optional 32 bits extension.
GTP notifies about the extension presence through the E, S or PN
header bits.
Csum GTP header parser did not check the extension bits value.
The patch updates GTP header length if header extension bits are set.
Cc: sta...@dpdk.org
Fixes: d8e5e69f3a9b ("app/testpmd: add GTP parsing and Tx checksum offload")
Signed-off-by: Gregory Etelson
---
app/test-pmd/csumonly.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 5274d498ee..f8abcded2b 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -223,15 +223,14 @@ parse_gtp(struct rte_udp_hdr *udp_hdr,
gtp_hdr = (struct rte_gtp_hdr *)((char *)udp_hdr +
sizeof(struct rte_udp_hdr));
-
+ if (gtp_hdr->e || gtp_hdr->s || gtp_hdr->pn)
+ gtp_len += sizeof(struct rte_gtp_hdr_ext_word);
/*
* Check message type. If message type is 0xff, it is
* a GTP data packet. If not, it is a GTP control packet
*/
if (gtp_hdr->msg_type == 0xff) {
- ip_ver = *(uint8_t *)((char *)udp_hdr +
-sizeof(struct rte_udp_hdr) +
-sizeof(struct rte_gtp_hdr));
+ ip_ver = *(uint8_t *)((char *)gtp_hdr + gtp_len);
ip_ver = (ip_ver) & 0xf0;
if (ip_ver == RTE_GTP_TYPE_IPV4) {
--
2.35.1
RE: [PATCH v7] eal: fix rte_memcpy strict aliasing/alignment bugs
> Calls to rte_memcpy for 1 < n < 16 could result in unaligned
> loads/stores, which is undefined behaviour according to the C
> standard, and strict aliasing violations.
>
> The code was changed to use a packed structure that allows aliasing
> (using the __may_alias__ attribute) to perform the load/store
> operations. This results in code that has the same performance as the
> original code and that is also C standards-compliant.
>
> Fixes: d35cc1fe6a7a ("eal/x86: revert select optimized memcpy at run-time")
> Cc: Xiaoyun Li
> Cc: sta...@dpdk.org
>
> Signed-off-by: Luc Pelletier
> ---
> v7:
> * Fix coding style issue by adding new __rte_may_alias macro rather
> than directly use __attribute__
>
> v6:
> * Refocus to fix strict aliasing problems discovered following
> discussions in this thread.
> * Modified the code to use __may_alias__ and packed structure. This fixes
> both the undefined behaviour of unaligned access (which is not the main
> concern), and also fixes the strict aliasing violations (which can cause
> major bugs, as demonstrated in a previous message in this thread).
> * Renamed new function from rte_mov15_or_less_unaligned to
> rte_mov15_or_less.
> * Modified code that copies <= 15 bytes to call rte_mov15_or_less.
>
> v5:
> * Replaced assembly with pure C code that uses a packed structure to make
> unaligned loads conform to C standard.
>
> v4:
> * Added volatile to asm statements, which is required under gcc.
>
> v3:
> * Removed for loop and went back to using assembly.
>
> v2:
> * Replaced assembly with a regular for loop that copies bytes one by
> one.
>
> v1:
> * Fix undefined behaviour of unaligned stores/loads by using assembly
> to perform stores/loads.
LGTM, thanks for highlighting and fixing the problem.
Acked-by: Konstantin Ananyev
Tested-by: Konstantin Ananyev
As a side note, we probably need to check other similar places in DPDK code.
Re: [PATCH] net/mlx5: fix FD configuration for Rx interrupt
On Thu, Mar 10, 2022 at 2:19 PM Michael Baum wrote: > > The mlx5_rx_intr_vec_enable() function allocates queue vector and fill > FD list for Rx interrupts. > > The driver wrongly configured the FD with a non-blocking flag which > prevent waiting on this FD. > > This patch removes O_NONBLOCK flag adding. - Maybe I deserve a Reported-by: credit on this issue. I sent a proposal to make use of Rx interrupts in OVS https://patchwork.ozlabs.org/project/openvswitch/patch/20220304161132.22065-1-david.march...@redhat.com/. And that's when I noticed that mlx5 rx fds were waking OVS too often and reported it to mlx5 maintainers. - Testing this patch by starting dpdk-l3fwd-power example (and no traffic sent at all): # strace -r -f ./dpdk-dir/v21.11/examples/dpdk-l3fwd-power --lcores 0@3,1@5 -a :82:00.0 --in-memory -- -p 0x1 -P --config '(0,0,1)' ... [pid 534983] 0.000348 epoll_wait(26, [], 1, 10) = 0 [pid 534983] 0.010082 read(24, For some reason, there is an event available for fd 18 right away (which is the issue in the first place). When reading this fd, read() blocks until an actual packet is received. Then, I send exactly one packet: [pid 534983] 0.010082 read(24, "@\217:\370\21\0\0\0", 136) = 8 [pid 534983] 9.228478 epoll_wait(26, [], 1, 10) = 0 [pid 534983] 0.010082 read(24, That makes mlx5 rx interrupts unusable for an application that does more than just polling one rxq. -- David Marchand
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Lingli Chen > Sent: Thursday, March 10, 2022 5:46 PM > To: dev@dpdk.org > Cc: Chen, LingliX > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > Add tested Intel platforms with Intel NICs to v22.03 release note. > > Signed-off-by: Lingli Chen Acked-by: Xueqin Lin
Re: [PATCH 2/2] vhost: fix FD leak with inflight messages
On Thu, Mar 10, 2022 at 2:00 PM Maxime Coquelin
wrote:
> On 3/10/22 13:50, David Marchand wrote:
> > Even if unlikely, a buggy vhost-user master might attach fds to inflight
> > messages. Add checks like for other types of vhost-user messages.
> >
> > Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
> Reviewed-by: Maxime Coquelin
Series applied, thanks.
--
David Marchand
RE: [PATCH] net/mlx5: fix the port match in sample flow
Hi,
> -Original Message-
> From: Jiawei(Jonny) Wang
> Sent: Monday, March 7, 2022 4:11 AM
> To: Slava Ovsiienko ; Matan Azrad
> ; Ori Kam
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the port match in sample flow
>
> If there are an explicit port match and sample action in the same flow,
> mlx5 PMD pushes the explicit port match in the prefix subflow, and uses the
> tag item match in the suffix subflow.
>
> The explicit port match was translated into source vport match so the sample
> suffix subflow lost this match after flow split.
>
> This patch copies the explicit port match to the sample suffix subflow, and
> the latter gets the correct source vport value in the flow matcher.
>
> Fixes: b4c0ddbfcc58 ("net/mlx5: split sample flow into two sub-flows")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jiawei Wang
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation
Hi,
> -Original Message-
> From: Thinh Tran
> Sent: Wednesday, March 9, 2022 9:49 PM
> To: dev@dpdk.org
> Cc: d...@linux.vnet.ibm.com; Slava Ovsiienko ;
> Raslan Darawsheh ; Dmitry Kozlyuk
> ; Thinh Tran ;
> sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix CPU socket ID for Rx queue creation
>
> The default CPU socket ID was used while creating the Rx queue and this
> caused creation failure in case if hardware was not resided on the default
> socket.
>
> The patch sets the correct CPU socket ID for the mlx5_rxq_ctrl before calling
> the mlx5_rxq_create_devx_rq_resources() which eventually calls
> mlx5_devx_rq_create() with correct CPU socket ID.
>
> v2: change patch description, no code change
Removed this part,
>
> Fixes: bc5bee028ebc ("net/mlx5: create drop queue using DevX")
> Cc: sta...@dpdk.org
>
>
> Signed-off-by: Thinh Tran
> Reviewed-by: David Christensen
Added missing Ack from V1 from Matan,
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH] net/mlx5: fix the implicit tag insertion in sample flow
Hi,
> -Original Message-
> From: Jiawei(Jonny) Wang
> Sent: Thursday, March 10, 2022 6:00 AM
> To: Slava Ovsiienko ; Matan Azrad
> ; Ori Kam
> Cc: dev@dpdk.org; Raslan Darawsheh ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the implicit tag insertion in sample flow
>
> The flow with sample action was split into two sub-flows,
> and the implicit tag action with unique id was added in the prefix
> sub-flow, the suffix sub-flow used the tag item to match with that
> unique id, and the implicit set tag action was inserted next to
> the sample action.
>
> While there's either PUSH VLAN action or ENCAP action preceding the
> sample action, implicit set tag action was added after PUSH VLAN or
> ENCAP actions, causing flow creation failure due to rdma-core
> does not support this action order.
>
> This patch ensures the implicit set tag action is inserted before
> either PUSH VLAN or encap action (if any) in the prefix sub-flow.
>
> Fixes: 6a951567c159 ("net/mlx5: support E-Switch mirroring and jump in one
> flow")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jiawei Wang
> Acked-by: Viacheslav Ovsiienko
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [PATCH] net/mlx5: fix FD configuration for Rx interrupt
10/03/2022 16:12, David Marchand: > On Thu, Mar 10, 2022 at 2:19 PM Michael Baum wrote: > > > > The mlx5_rx_intr_vec_enable() function allocates queue vector and fill > > FD list for Rx interrupts. > > > > The driver wrongly configured the FD with a non-blocking flag which > > prevent waiting on this FD. > > > > This patch removes O_NONBLOCK flag adding. > > - Maybe I deserve a Reported-by: credit on this issue. > I sent a proposal to make use of Rx interrupts in OVS > https://patchwork.ozlabs.org/project/openvswitch/patch/20220304161132.22065-1-david.march...@redhat.com/. > And that's when I noticed that mlx5 rx fds were waking OVS too often > and reported it to mlx5 maintainers. > > > - Testing this patch by starting dpdk-l3fwd-power example (and no > traffic sent at all): > > # strace -r -f ./dpdk-dir/v21.11/examples/dpdk-l3fwd-power --lcores > 0@3,1@5 -a :82:00.0 --in-memory -- -p 0x1 -P --config '(0,0,1)' > ... > [pid 534983] 0.000348 epoll_wait(26, [], 1, 10) = 0 > [pid 534983] 0.010082 read(24, > > For some reason, there is an event available for fd 18 right away > (which is the issue in the first place). > When reading this fd, read() blocks until an actual packet is received. > > Then, I send exactly one packet: > [pid 534983] 0.010082 read(24, "@\217:\370\21\0\0\0", 136) = 8 > [pid 534983] 9.228478 epoll_wait(26, [], 1, 10) = 0 > [pid 534983] 0.010082 read(24, > > That makes mlx5 rx interrupts unusable for an application that does > more than just polling one rxq. Excuse me, I don't understand this trace. What is the first read? Having a second read after epoll_wait is normal if a packet is received, isn't it?
Re: [PATCH] eal/windows: fix data race when creating threads
Hi Tyler,
2022-03-09 23:35 (UTC-0800), Tyler Retzlaff:
> create lcore worker threads suspended and then subsequently resume to
> allow &lcore_config[i].thread_id be stored before eal_thread_loop
> execution.
>
> Fixes: 53ffd9f080fc ("eal/windows: add minimum viable code")
> Cc: anand.ra...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Tyler Retzlaff
Acked-by: Dmitry Kozlyuk
It takes some effort to correlate &lcore_config[i].thread_id
with the code in the patch and knowledge of CreateThread()
to understand the root cause.
I suggest prepending an explanation to your commit message:
eal_thread_loop() uses lcore_config[i].thread_id,
which is stored upon the return from CreateThread().
Per documentation, eal_thread_loop() can start
before CreateThread() returns and the ID is stored.
> ---
> lib/eal/windows/eal_thread.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/lib/eal/windows/eal_thread.c b/lib/eal/windows/eal_thread.c
> index 54fa93f..ff84cb4 100644
> --- a/lib/eal/windows/eal_thread.c
> +++ b/lib/eal/windows/eal_thread.c
> @@ -150,13 +150,18 @@
>
> th = CreateThread(NULL, 0,
> (LPTHREAD_START_ROUTINE)(ULONG_PTR)eal_thread_loop,
> - NULL, 0, (LPDWORD)thread);
> + NULL, CREATE_SUSPENDED,
> (LPDWORD)thread);
> if (!th)
> return -1;
>
> SetPriorityClass(GetCurrentProcess(), NORMAL_PRIORITY_CLASS);
> SetThreadPriority(th, THREAD_PRIORITY_NORMAL);
>
> + if (ResumeThread(th) == (DWORD)-1) {
> + (void)CloseHandle(th);
> + return -1;
> + }
> +
> return 0;
> }
>
RE: [PATCH] net/mlx5: fix FD configuration for Rx interrupt
On Thu, Mar 10, 2022 at 6:16 PM Thomas Monjalon wrote: > > 10/03/2022 16:12, David Marchand: > > On Thu, Mar 10, 2022 at 2:19 PM Michael Baum > wrote: > > > > > > The mlx5_rx_intr_vec_enable() function allocates queue vector and > > > fill FD list for Rx interrupts. > > > > > > The driver wrongly configured the FD with a non-blocking flag which > > > prevent waiting on this FD. > > > > > > This patch removes O_NONBLOCK flag adding. > > > > - Maybe I deserve a Reported-by: credit on this issue. Hi David, You are right, you should have get the credit. > > I sent a proposal to make use of Rx interrupts in OVS > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > hwork.ozlabs.org%2Fproject%2Fopenvswitch%2Fpatch%2F20220304161132.2 > 2065-1- > david.marchand%40redhat.com%2F&data=04%7C01%7Cmichaelba%40n > vidia.com%7C3679e1e70986425d465b08da02b14b34%7C43083d15727340c1b7 > db39efd9ccc17a%7C0%7C0%7C637825257758477604%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C3000&sdata=LamFMZTLgZzQoUDBYAGn2aL9z7RWylWCkn > q2SGFuKOY%3D&reserved=0. > > And that's when I noticed that mlx5 rx fds were waking OVS too often > > and reported it to mlx5 maintainers. > > > > > > - Testing this patch by starting dpdk-l3fwd-power example (and no > > traffic sent at all): > > > > # strace -r -f ./dpdk-dir/v21.11/examples/dpdk-l3fwd-power --lcores > > 0@3,1@5 -a :82:00.0 --in-memory -- -p 0x1 -P --config '(0,0,1)' > > ... > > [pid 534983] 0.000348 epoll_wait(26, [], 1, 10) = 0 > > [pid 534983] 0.010082 read(24, > > > > For some reason, there is an event available for fd 18 right away > > (which is the issue in the first place). I don't understand who is FD 18, I cannot see it in your log > > When reading this fd, read() blocks until an actual packet is received. > > > > Then, I send exactly one packet: > > [pid 534983] 0.010082 read(24, "@\217:\370\21\0\0\0", 136) = 8 > > [pid 534983] 9.228478 epoll_wait(26, [], 1, 10) = 0 > > [pid 534983] 0.010082 read(24, > > > > That makes mlx5 rx interrupts unusable for an application that does > > more than just polling one rxq. > > Excuse me, I don't understand this trace. > What is the first read? > Having a second read after epoll_wait is normal if a packet is received, > isn't it? >
Re: [PATCH] examples/vm_power: replace list foreach with while loop
On Thu, 10 Mar 2022 09:32:08 + "Koikkara Reeny, Shibin" wrote: > > -Original Message- > > From: Thomas Monjalon > > 01/03/2022 15:53, Shibin Koikkara Reeny: > > > Linux header files don't support LIST_FOREACH_SAFE so replacing > > > LIST_FOREACH with while loop. > > > > What is the original issue you are trying to solve? > Asan tool reported LIST_FOREACH should be replaced with LIST_FOREACH_SAFE but > Linux don't have LIST_FOREACH_SAFE API. So replacing it with while loop. > > Regards, > Shibin Why not just clone LIST_FOREACH_SAFE from BSD? That is what RTE_TAILQ does. It might be generally useful.
Re: [PATCH V1] doc: add tested Intel platforms with Intel NICs
On Thu, 10 Mar 2022 17:46:19 +0800 Lingli Chen wrote: > Add tested Intel platforms with Intel NICs to v22.03 release note. > > Signed-off-by: Lingli Chen Ok, but this kind of list gets stale and grows geometrically.
[PATCH] app/testpmd: fixed using strtoull with 64-bit variables
Replaced using strtoul with strtoull when converting to
64-bit mask field.
In Windows strtoul returns 32-bit values which cause an
issue with show RSS reta.
Fixes: 66c594904ac ("ethdev: support multiple sizes of redirection table")
Cc: sta...@dpdk.org
Signed-off-by: Adham Masarwah
---
app/test-pmd/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b4ba8da2b0..efa02bd301 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3127,7 +3127,7 @@ showport_parse_reta_config(struct
rte_eth_rss_reta_entry64 *conf,
return -1;
}
for (i = 0; i < ret; i++)
- conf[i].mask = (uint64_t)strtoul(str_fld[i], &end, 0);
+ conf[i].mask = (uint64_t)strtoull(str_fld[i], &end, 0);
return 0;
}
--
2.16.1.windows.4
[PATCH] app/testpmd: fixed using strtoull with 64-bit variables
Replaced using strtoul with strtoull when converting to
64-bit mask field.
In Windows strtoul returns 32-bit values which cause an
issue with show RSS reta.
Fixes: 66c594904ac ("ethdev: support multiple sizes of redirection table")
Cc: sta...@dpdk.org
Signed-off-by: Adham Masarwah
---
app/test-pmd/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b4ba8da2b0..efa02bd301 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3127,7 +3127,7 @@ showport_parse_reta_config(struct
rte_eth_rss_reta_entry64 *conf,
return -1;
}
for (i = 0; i < ret; i++)
- conf[i].mask = (uint64_t)strtoul(str_fld[i], &end, 0);
+ conf[i].mask = (uint64_t)strtoull(str_fld[i], &end, 0);
return 0;
}
--
2.16.1.windows.4
[PATCH] doc: relax requirement on commit messages of security fixes
From: Luca Boccassi Allow more flexibility with embargo lifting by not requiring mentions of CVEs in commit messages if the lift date allows it. Signed-off-by: Luca Boccassi --- doc/guides/contributing/vulnerability.rst | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/guides/contributing/vulnerability.rst b/doc/guides/contributing/vulnerability.rst index b6300252ad..fc60e02e37 100644 --- a/doc/guides/contributing/vulnerability.rst +++ b/doc/guides/contributing/vulnerability.rst @@ -170,7 +170,10 @@ The patches fixing the vulnerability are developed and reviewed by the security team and by elected area experts that agree to maintain confidentiality. -The CVE id and the bug id must be referenced in the patch. +The CVE id and the bug id must be referenced in the patch if there is no +embargo, or if there is an embargo, but it will be lifted when the release +including the patch is published. If the embargo is going to be lifted after the +release, then the CVE and bug ids must be omitted from the commit message. Backports to the identified affected versions are done once the fix is ready. -- 2.34.1
[PATCH] bpf: fix build with some libpcap version on FreeBSD
This is something caught in UNH FreeBSD env.
For some reason [1], the pcap/bpf.h header started to define _BPF_H_.
It happens that the bpf_impl.h internal DPDK header uses this define as
an internal guard.
This triggers a build failure in bpf_convert.c which can't find
RTE_BPF_LOG macro.
Fix the include guard to use the filename and remove _.
1: https://github.com/the-tcpdump-group/libpcap/pull/1074
Fixes: 94972f35a02e ("bpf: add BPF loading and execution framework")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
lib/bpf/bpf_impl.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
index 26d165ad5c..b4d8e87c6d 100644
--- a/lib/bpf/bpf_impl.h
+++ b/lib/bpf/bpf_impl.h
@@ -2,8 +2,8 @@
* Copyright(c) 2018 Intel Corporation
*/
-#ifndef _BPF_H_
-#define _BPF_H_
+#ifndef BPF_IMPL_H
+#define BPF_IMPL_H
#include
#include
@@ -43,4 +43,4 @@ bpf_size(uint32_t bpf_op_sz)
return 0;
}
-#endif /* _BPF_H_ */
+#endif /* BPF_IMPL_H */
--
2.23.0
Re: [PATCH] bpf: fix build with some libpcap version on FreeBSD
On Thu, 10 Mar 2022 19:30:40 +0100
David Marchand wrote:
> This is something caught in UNH FreeBSD env.
>
> For some reason [1], the pcap/bpf.h header started to define _BPF_H_.
>
> It happens that the bpf_impl.h internal DPDK header uses this define as
> an internal guard.
> This triggers a build failure in bpf_convert.c which can't find
> RTE_BPF_LOG macro.
>
> Fix the include guard to use the filename and remove _.
>
> 1: https://github.com/the-tcpdump-group/libpcap/pull/1074
>
> Fixes: 94972f35a02e ("bpf: add BPF loading and execution framework")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Acked-by: Stephen Hemminger
[PATCH v1] sched: enable/disable TC OV at runtime
Added new API to enable or disable TC over subscription for best
effort traffic class at subport level.
By default TC OV is disabled for subport.
Signed-off-by: Megha Ajmera
---
lib/sched/rte_sched.c | 182 +++---
lib/sched/rte_sched.h | 18 +
lib/sched/version.map | 3 +
3 files changed, 172 insertions(+), 31 deletions(-)
diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
index ec74bee939..1d05089d00 100644
--- a/lib/sched/rte_sched.c
+++ b/lib/sched/rte_sched.c
@@ -155,6 +155,7 @@ struct rte_sched_subport {
uint64_t tc_credits[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
/* TC oversubscription */
+ uint8_t is_tc_ov_enabled;
uint64_t tc_ov_wm;
uint64_t tc_ov_wm_min;
uint64_t tc_ov_wm_max;
@@ -1165,6 +1166,45 @@ rte_sched_cman_config(struct rte_sched_port *port,
}
#endif
+int
+rte_sched_subport_tc_ov_config(struct rte_sched_port *port,
+ uint32_t subport_id,
+ bool tc_ov_enable)
+{
+ struct rte_sched_subport *s;
+ struct rte_sched_subport_profile *profile;
+
+ if (port == NULL) {
+ RTE_LOG(ERR, SCHED,
+ "%s: Incorrect value for parameter port\n", __func__);
+ return -EINVAL;
+ }
+
+ if (subport_id >= port->n_subports_per_port) {
+ RTE_LOG(ERR, SCHED,
+ "%s: Incorrect value for parameter subport id\n",
__func__);
+ return -EINVAL;
+ }
+
+ s = port->subports[subport_id];
+ s->is_tc_ov_enabled = tc_ov_enable;
+
+ if (s->is_tc_ov_enabled) {
+ /* TC oversubscription */
+ s->tc_ov_wm_min = port->mtu;
+ s->tc_ov_period_id = 0;
+ s->tc_ov = 0;
+ s->tc_ov_n = 0;
+ s->tc_ov_rate = 0;
+
+ profile = port->subport_profiles + s->profile;
+ s->tc_ov_wm_max = rte_sched_time_ms_to_bytes(profile->tc_period,
+ s->pipe_tc_be_rate_max);
+ s->tc_ov_wm = s->tc_ov_wm_max;
+ }
+ return 0;
+}
+
int
rte_sched_subport_config(struct rte_sched_port *port,
uint32_t subport_id,
@@ -1317,12 +1357,8 @@ rte_sched_subport_config(struct rte_sched_port *port,
for (i = 0; i < RTE_SCHED_PORT_N_GRINDERS; i++)
s->grinder_base_bmp_pos[i] = RTE_SCHED_PIPE_INVALID;
- /* TC oversubscription */
- s->tc_ov_wm_min = port->mtu;
- s->tc_ov_period_id = 0;
- s->tc_ov = 0;
- s->tc_ov_n = 0;
- s->tc_ov_rate = 0;
+ /* TC over-subscription is disabled by default */
+ s->is_tc_ov_enabled = 0;
}
{
@@ -1342,9 +1378,6 @@ rte_sched_subport_config(struct rte_sched_port *port,
else
profile->tc_credits_per_period[i] = 0;
- s->tc_ov_wm_max = rte_sched_time_ms_to_bytes(profile->tc_period,
- s->pipe_tc_be_rate_max);
- s->tc_ov_wm = s->tc_ov_wm_max;
s->profile = subport_profile_id;
}
@@ -1417,17 +1450,20 @@ rte_sched_pipe_config(struct rte_sched_port *port,
double pipe_tc_be_rate =
(double)
params->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
/ (double) params->tc_period;
- uint32_t tc_be_ov = s->tc_ov;
- /* Unplug pipe from its subport */
- s->tc_ov_n -= params->tc_ov_weight;
- s->tc_ov_rate -= pipe_tc_be_rate;
- s->tc_ov = s->tc_ov_rate > subport_tc_be_rate;
+ if (s->is_tc_ov_enabled) {
+ uint32_t tc_be_ov = s->tc_ov;
- if (s->tc_ov != tc_be_ov) {
- RTE_LOG(DEBUG, SCHED,
- "Subport %u Best-effort TC oversubscription is
OFF (%.4lf >= %.4lf)\n",
- subport_id, subport_tc_be_rate, s->tc_ov_rate);
+ /* Unplug pipe from its subport */
+ s->tc_ov_n -= params->tc_ov_weight;
+ s->tc_ov_rate -= pipe_tc_be_rate;
+ s->tc_ov = s->tc_ov_rate > subport_tc_be_rate;
+
+ if (s->tc_ov != tc_be_ov) {
+ RTE_LOG(DEBUG, SCHED,
+ "Subport %u Best-effort TC
oversubscription is OFF (%.4lf >= %.4lf)\n",
+ subport_id, subport_tc_be_rate,
s->tc_ov_rate);
+ }
}
/* Reset the pipe */
@@ -1460,19 +1496,22 @@ rte_sched_pipe_config(struct rte_sched_port *port,
double pipe_tc_be_rate =
(double)
params->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
Re: [PATCH v1] gpu/cuda: set unused gdrcopy functions arguments
10/03/2022 01:06, eagost...@nvidia.com:
> From: Elena Agostini
>
> Without enabling gdrcopy, dpdk build has warnings about
> unused gdrcopy functions input parameters.
As developers we should test with --werror option given to meson,
so we don't miss such details.
This is what the script devtools/test-meson-builds.sh does.
> This patch set them to __rte_unused .
>
> Fixes: 24c7759 ("gpu/cuda: map GPU memory with GDRCopy")
Let's keep this casing of GDRCopy in the new title.
> Signed-off-by: Elena Agostini
> ---
> int
> -gdrcopy_pin(gdr_t *gdrc_h, __rte_unused gdr_mh_t *mh, uint64_t d_addr,
> size_t size, void **h_addr)
> +gdrcopy_pin(__rte_unused gdr_t *gdrc_h, __rte_unused gdr_mh_t *mh,
> __rte_unused uint64_t d_addr, __rte_unused size_t size, __rte_unused void
> **h_addr)
While at it, break the too long line.
It seems my compiler is smart enough to not require the unused attribute
for parameters used in another branch of #ifdef.
But it is probably required for some old compilers.
Applied, thanks.
Re: [PATCH v1] sched: enable/disable TC OV at runtime
On Thu, 10 Mar 2022 19:54:26 +
Megha Ajmera wrote:
> diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c
> index ec74bee939..1d05089d00 100644
> --- a/lib/sched/rte_sched.c
> +++ b/lib/sched/rte_sched.c
> @@ -155,6 +155,7 @@ struct rte_sched_subport {
> uint64_t tc_credits[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
>
> /* TC oversubscription */
> + uint8_t is_tc_ov_enabled;
> uint64_t tc_ov_wm;
> uint64_t tc_ov_wm_min;
> uint64_t tc_ov_wm_max;
Putting the field there creates a hole in the structure.
Put it after tc_ov and fill an existing hole.
This is pahole of current code, looks like this struct could
use some work to be better packed and aligned.
struct rte_sched_port {
uint32_t n_subports_per_port; /* 0 4 */
uint32_t n_pipes_per_subport; /* 4 4 */
uint32_t n_pipes_per_subport_log2; /* 8 4 */
uint16_t pipe_queue[13]; /*1226 */
uint8_tpipe_tc[16]; /*3816 */
uint8_ttc_queue[16]; /*5416 */
/* XXX 2 bytes hole, try to pack */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
uint32_t n_subport_profiles; /*72 4 */
uint32_t n_max_subport_profiles; /*76 4 */
uint64_t rate; /*80 8 */
uint32_t mtu; /*88 4 */
uint32_t frame_overhead; /*92 4 */
intsocket; /*96 4 */
/* XXX 4 bytes hole, try to pack */
uint64_t time_cpu_cycles; /* 104 8 */
uint64_t time_cpu_bytes; /* 112 8 */
uint64_t time; /* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
struct rte_reciprocal inv_cycles_per_byte; /* 128 8 */
/* XXX last struct has 2 bytes of padding */
uint64_t cycles_per_byte; /* 136 8 */
struct rte_mbuf * *pkts_out; /* 144 8 */
uint32_t n_pkts_out; /* 152 4 */
uint32_t subport_id; /* 156 4 */
struct rte_sched_subport_profile * subport_profiles; /* 160 8 */
/* XXX 24 bytes hole, try to pack */
/* --- cacheline 3 boundary (192 bytes) --- */
struct rte_sched_subport * subports[] __attribute__((__aligned__(64)));
/* 192 0 */
/* size: 192, cachelines: 3, members: 22 */
/* sum members: 162, holes: 3, sum holes: 30 */
/* paddings: 1, sum paddings: 2 */
/* forced alignments: 1, forced holes: 1, sum forced holes: 24 */
} __attribute__((__aligned__(64)));
DPDK Release Status Meeting 2022-03-10
Release status meeting minutes 2022-03-10 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * ARM * Debian * Intel * Marvell * Nvidia * Red Hat Release Dates - The following are the proposed dates for 22.03 (note, the slight extension of the release date): * 22.03 RC42022-03-14 * 22.03 Release2022-03-16 Updated dates are posted shortly after they are changed at: http://core.dpdk.org/roadmap/#dates Here are some provisional dates for the subsequent releases: * 22.07 V1 2022-04-10 * 22.07 Merge 2022-05-30 * 22.07 Release2022-07-13 * 22.11 V1 2022-09-14 * 22.11 Merge 2022-10-03 * 22.11 Release2022-11-16 Subtrees * next-net * Tree merged to RC3 * Some testpmd fixes outstanding - new reviews or change requests required * I40e build error from ARM - fix available * Fixes should now go to main repo directly * next-net-intel * Some fixes to be pulled * next-net-mlx * Around 8 new patches for fixes since RC3 * next-net-brcm * No update * next-net-mrvl * Some patches/fixes merged to subtree * next-eventdev * No outstanding patches * next-virtio * PR ready * next-crypto * Regression in vhost crypto - Fix completed and merged * main * Release candidate 22.03-rc3 released on 2022-03-08 * Some CI build failures on Ubuntu 21.04 and 21.10 * Still quite a few fixes to be merged * Will collect fixes into RC4 for release/testing on Monday 2022-03-14 * Will target full release for Wednesday 2022-03-16 LTS --- * 21.11.1 * Backporting progressing * 20.11.5 * Backporting progressing * 19.11.12 * Backporting progressing * Distros * v20.11 in Debian 11 * 22.04 will contain 21.11 Defects --- * Bugzilla links, 'Bugs', added for hosted projects * https://www.dpdk.org/hosted-projects/ Opens - * None DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on every Thursday at 9:30 UTC. on https://meet.jit.si/DPDK If you wish to attend just send an email to "John McNamara john.mcnam...@intel.com" for the invite.
[PATCH] net/mlx5: handle MPRQ incompatibility with external buffers
Multi-Packet Rx queue uses PMD-managed buffers to store packets.
These buffers are externally attached to user mbufs.
This conflicts with the feature that allows using user-managed
externally attached buffers in an application.
Fall back to SPRQ in case external buffers mempool is configured.
Add the corresponding limitation to MLX5 documentation that MPRQ
and external data buffers cannot be used together.
Signed-off-by: Alexander Kozyrev
---
doc/guides/nics/mlx5.rst| 4 +++-
drivers/net/mlx5/mlx5_rx.h | 2 +-
drivers/net/mlx5/mlx5_rxq.c | 22 ++
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 679481bed5..4799875263 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -260,7 +260,9 @@ Limitations
ol_flags. As the mempool for the external buffer is managed by PMD, all the
Rx mbufs must be freed before the device is closed. Otherwise, the mempool of
the external buffers will be freed by PMD and the application which still
- holds the external buffers may be corrupted.
+ holds the external buffers may be corrupted. User-managed mempools with
+ external pinned data buffers cannot be used in conjunction with MPRQ
+ since packets may be already attached to PMD-managed external buffers.
- If Multi-Packet Rx queue is configured (``mprq_en``) and Rx CQE compression
is
enabled (``rxq_cqe_comp_en``) at the same time, RSS hash result is not fully
diff --git a/drivers/net/mlx5/mlx5_rx.h b/drivers/net/mlx5/mlx5_rx.h
index acebe3348c..5bf88b6181 100644
--- a/drivers/net/mlx5/mlx5_rx.h
+++ b/drivers/net/mlx5/mlx5_rx.h
@@ -209,7 +209,7 @@ struct mlx5_rxq_ctrl *mlx5_rxq_new(struct rte_eth_dev *dev,
uint16_t idx,
uint16_t desc, unsigned int socket,
const struct rte_eth_rxconf *conf,
const struct rte_eth_rxseg_split *rx_seg,
- uint16_t n_seg);
+ uint16_t n_seg, bool is_extmem);
struct mlx5_rxq_ctrl *mlx5_rxq_hairpin_new
(struct rte_eth_dev *dev, struct mlx5_rxq_priv *rxq, uint16_t desc,
const struct rte_eth_hairpin_conf *hairpin_conf);
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index f16795bac3..4f58b90cfe 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -840,6 +840,8 @@ mlx5_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
int res;
uint64_t offloads = conf->offloads |
dev->data->dev_conf.rxmode.offloads;
+ bool is_extmem = rte_pktmbuf_priv_flags(mp) &
+RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF;
if (mp) {
/*
@@ -912,7 +914,7 @@ mlx5_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
}
if (rxq_ctrl == NULL) {
rxq_ctrl = mlx5_rxq_new(dev, idx, desc, socket, conf, rx_seg,
- n_seg);
+ n_seg, is_extmem);
if (rxq_ctrl == NULL) {
DRV_LOG(ERR, "port %u unable to allocate rx queue index
%u",
dev->data->port_id, idx);
@@ -1548,7 +1550,8 @@ mlx5_max_lro_msg_size_adjust(struct rte_eth_dev *dev,
uint16_t idx,
* Log number of strides to configure for this queue.
* @param actual_log_stride_size
* Log stride size to configure for this queue.
- *
+ * @param is_extmem
+ * Is external pinned memory pool used.
* @return
* 0 if Multi-Packet RQ is supported, otherwise -1.
*/
@@ -1556,7 +1559,8 @@ static int
mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx, uint16_t desc,
bool rx_seg_en, uint32_t min_mbuf_size,
uint32_t *actual_log_stride_num,
- uint32_t *actual_log_stride_size)
+ uint32_t *actual_log_stride_size,
+ bool is_extmem)
{
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_port_config *config = &priv->config;
@@ -1575,7 +1579,7 @@ mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
log_max_stride_size);
uint32_t log_stride_wqe_size;
- if (mlx5_check_mprq_support(dev) != 1 || rx_seg_en)
+ if (mlx5_check_mprq_support(dev) != 1 || rx_seg_en || is_extmem)
goto unsupport;
/* Checks if chosen number of strides is in supported range. */
if (config->mprq.log_stride_num > log_max_stride_num ||
@@ -1641,7 +1645,7 @@ mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
" rxq_num = %u, stride_sz = %u, stride_num = %u\n"
" supported: min_rxqs_num = %u, min_buf_wqe_sz = %u"
" min_stride_sz = %u, max_stride_sz = %u).\n"
-
[PATCH v2] net/mlx5: handle MPRQ incompatibility with external buffers
Multi-Packet Rx queue uses PMD-managed buffers to store packets.
These buffers are externally attached to user mbufs.
This conflicts with the feature that allows using user-managed
externally attached buffers in an application.
Fall back to SPRQ in case external buffers mempool is configured.
Add the corresponding limitation to MLX5 documentation that MPRQ
and external data buffers cannot be used together.
Signed-off-by: Alexander Kozyrev
---
v2: fixed typo in warning message
doc/guides/nics/mlx5.rst| 4 +++-
drivers/net/mlx5/mlx5_rx.h | 2 +-
drivers/net/mlx5/mlx5_rxq.c | 22 ++
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 679481bed5..4799875263 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -260,7 +260,9 @@ Limitations
ol_flags. As the mempool for the external buffer is managed by PMD, all the
Rx mbufs must be freed before the device is closed. Otherwise, the mempool of
the external buffers will be freed by PMD and the application which still
- holds the external buffers may be corrupted.
+ holds the external buffers may be corrupted. User-managed mempools with
+ external pinned data buffers cannot be used in conjunction with MPRQ
+ since packets may be already attached to PMD-managed external buffers.
- If Multi-Packet Rx queue is configured (``mprq_en``) and Rx CQE compression
is
enabled (``rxq_cqe_comp_en``) at the same time, RSS hash result is not fully
diff --git a/drivers/net/mlx5/mlx5_rx.h b/drivers/net/mlx5/mlx5_rx.h
index acebe3348c..5bf88b6181 100644
--- a/drivers/net/mlx5/mlx5_rx.h
+++ b/drivers/net/mlx5/mlx5_rx.h
@@ -209,7 +209,7 @@ struct mlx5_rxq_ctrl *mlx5_rxq_new(struct rte_eth_dev *dev,
uint16_t idx,
uint16_t desc, unsigned int socket,
const struct rte_eth_rxconf *conf,
const struct rte_eth_rxseg_split *rx_seg,
- uint16_t n_seg);
+ uint16_t n_seg, bool is_extmem);
struct mlx5_rxq_ctrl *mlx5_rxq_hairpin_new
(struct rte_eth_dev *dev, struct mlx5_rxq_priv *rxq, uint16_t desc,
const struct rte_eth_hairpin_conf *hairpin_conf);
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index f16795bac3..7a214dcca9 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -840,6 +840,8 @@ mlx5_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
int res;
uint64_t offloads = conf->offloads |
dev->data->dev_conf.rxmode.offloads;
+ bool is_extmem = rte_pktmbuf_priv_flags(mp) &
+RTE_PKTMBUF_POOL_F_PINNED_EXT_BUF;
if (mp) {
/*
@@ -912,7 +914,7 @@ mlx5_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
}
if (rxq_ctrl == NULL) {
rxq_ctrl = mlx5_rxq_new(dev, idx, desc, socket, conf, rx_seg,
- n_seg);
+ n_seg, is_extmem);
if (rxq_ctrl == NULL) {
DRV_LOG(ERR, "port %u unable to allocate rx queue index
%u",
dev->data->port_id, idx);
@@ -1548,7 +1550,8 @@ mlx5_max_lro_msg_size_adjust(struct rte_eth_dev *dev,
uint16_t idx,
* Log number of strides to configure for this queue.
* @param actual_log_stride_size
* Log stride size to configure for this queue.
- *
+ * @param is_extmem
+ * Is external pinned memory pool used.
* @return
* 0 if Multi-Packet RQ is supported, otherwise -1.
*/
@@ -1556,7 +1559,8 @@ static int
mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx, uint16_t desc,
bool rx_seg_en, uint32_t min_mbuf_size,
uint32_t *actual_log_stride_num,
- uint32_t *actual_log_stride_size)
+ uint32_t *actual_log_stride_size,
+ bool is_extmem)
{
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_port_config *config = &priv->config;
@@ -1575,7 +1579,7 @@ mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
log_max_stride_size);
uint32_t log_stride_wqe_size;
- if (mlx5_check_mprq_support(dev) != 1 || rx_seg_en)
+ if (mlx5_check_mprq_support(dev) != 1 || rx_seg_en || is_extmem)
goto unsupport;
/* Checks if chosen number of strides is in supported range. */
if (config->mprq.log_stride_num > log_max_stride_num ||
@@ -1641,7 +1645,7 @@ mlx5_mprq_prepare(struct rte_eth_dev *dev, uint16_t idx,
uint16_t desc,
" rxq_num = %u, stride_sz = %u, stride_num = %u\n"
" supported: min_rxqs_num = %u, min_buf_wqe_sz = %u"
" min_stride_sz = %
[PATCH v1] bbdev: add new operation for FFT processing
Hi, This contributions adds a new operation type to the existing ones already supported by the bbdev PMDs. This set of operation is FFT-based processing for 5GNR baseband processing acceleration. This operates in the same lookaside fashion as other existing bbdev operation with a dedicated set of capabilities and parameters (marked as experimental). I plan to also include a new PMD supporting this operation (and most of the related capabilities) in the next couple of months (either in 22.06 or 22.09) as well as extending the related bbdev-test. I can update the release notes for 22.06 on subsequent patch vs or separate commit (not there yet). Thanks for review feedback. Nicolas Chautru (1): bbdev: add new operation for FFT processing doc/guides/prog_guide/bbdev.rst | 130 +++ lib/bbdev/rte_bbdev.c | 8 +++ lib/bbdev/rte_bbdev.h | 76 lib/bbdev/rte_bbdev_op.h| 149 lib/bbdev/version.map | 10 +++ 5 files changed, 373 insertions(+) -- 1.8.3.1
[PATCH v1] bbdev: add new operation for FFT processing
Extension of bbdev operation to support FFT based operations.
Signed-off-by: Nicolas Chautru
---
doc/guides/prog_guide/bbdev.rst | 130 +++
lib/bbdev/rte_bbdev.c | 8 +++
lib/bbdev/rte_bbdev.h | 76
lib/bbdev/rte_bbdev_op.h| 149
lib/bbdev/version.map | 10 +++
5 files changed, 373 insertions(+)
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 70fa01a..2791286 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -1118,6 +1118,136 @@ Figure :numref:`figure_turbo_tb_decode` above
showing the Turbo decoding of CBs using BBDEV interface in TB-mode
is also valid for LDPC decode.
+BBDEV FFT Operation
+
+
+This operation allows to run a combination of DFT and/or IDFT and/or
time-domain windowing.
+These can be used in a modular fashion (using bypass modes) or as a processing
pipeline
+which can be used for FFT-based baseband signal processing.
+In more details it allows :
+- to process the data first through an IDFT of adjustable size and padding;
+- to perform the windowing as a programmable cyclic shift offset of the data
followed by a
+pointwise multiplication by a time domain window;
+- to process the related data through a DFT of adjustable size and depadding
for each such cyclic
+shift output.
+
+A flexible number of Rx antennas are being processed in parallel with the same
configuration.
+The API allows more generally for flexibility in what the PMD may support
(cabability flags) and
+flexibility to adjust some of the parameters of the processing.
+
+The operation/capability flags that can be set for each FFT operation are
given below.
+
+ **NOTE:** The actual operation flags that may be used with a specific
+ BBDEV PMD are dependent on the driver capabilities as reported via
+ ``rte_bbdev_info_get()``, and may be a subset of those below.
+
+++
+|Description of FFT capability flags |
+++
+|RTE_BBDEV_FFT_WINDOWING |
+| Set to enable/support windowing in time domain |
+++
+|RTE_BBDEV_FFT_CS_ADJUSTMENT |
+| Set to enable/support the cyclic shift time offset adjustment |
+++
+|RTE_BBDEV_FFT_DFT_BYPASS|
+| Set to bypass the DFT and use directly the IDFT as an option |
+++
+|RTE_BBDEV_FFT_IDFT_BYPASS |
+| Set to bypass the IDFT and use directly the DFT as an option |
+++
+|RTE_BBDEV_FFT_WINDOWING_BYPASS |
+| Set to bypass the time domain windowing as an option |
+++
+|RTE_BBDEV_FFT_POWER_MEAS|
+| Set to provide an optional power measument of the DFT output |
+++
+|RTE_BBDEV_FFT_FP16_INPUT|
+| Set if the input data shall use FP16 format instead of INT16 |
+++
+|RTE_BBDEV_FFT_FP16_OUTPUT |
+| Set if the output data shall use FP16 format instead of INT16 |
+++
+
+The structure passed for each FFT operation is given below,
+with the operation flags forming a bitmask in the ``op_flags`` field.
+
+.. code-block:: c
+
+struct rte_bbdev_op_fft {
+struct rte_bbdev_op_data base_input;
+struct rte_bbdev_op_data base_output;
+struct rte_bbdev_op_data power_meas_output;
+uint32_t op_flags;
+uint16_t input_sequence_size;
+uint16_t input_leading_padding;
+uint16_t output_sequence_size;
+uint16_t output_leading_depadding;
+uint8_t window_index[RTE_BBDEV_MAX_CS_2];
+uint16_t cs_bitmap;
+uint8_t num_antennas_log2;
+uint8_t idft_log2;
+uint8_t dft_log2;
+int8_t cs_time_adjustment;
+int8_t idft_shift;
+int8_t dft_shift;
+uint16_t ncs_reciprocal;
+uint16_t power_shift;
+uint16_t fp16_exp_adjust;
+};
+
+The FFT parameters are set out in the table below.
+
++--+
Re: [PATCH v1] bbdev: add new operation for FFT processing
On Thu, 10 Mar 2022 15:49:17 -0800
Nicolas Chautru wrote:
> diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c
> index aaee7b7..a72ecba 100644
> --- a/lib/bbdev/rte_bbdev.c
> +++ b/lib/bbdev/rte_bbdev.c
> @@ -850,6 +850,9 @@ struct rte_bbdev *
> case RTE_BBDEV_OP_LDPC_ENC:
> result = sizeof(struct rte_bbdev_enc_op);
> break;
> + case RTE_BBDEV_OP_FFT:
> + result = sizeof(struct rte_bbdev_fft_op);
> + break;
> default:
> break;
> }
> @@ -873,6 +876,10 @@ struct rte_bbdev *
> struct rte_bbdev_enc_op *op = element;
> memset(op, 0, mempool->elt_size);
> op->mempool = mempool;
> + } else if (type == RTE_BBDEV_OP_FFT) {
> + struct rte_bbdev_fft_op *op = element;
> + memset(op, 0, mempool->elt_size);
> + op->mempool = mempool;
> }
> }
>
> @@ -1123,6 +1130,7 @@ struct rte_mempool *
> "RTE_BBDEV_OP_TURBO_ENC",
> "RTE_BBDEV_OP_LDPC_DEC",
> "RTE_BBDEV_OP_LDPC_ENC",
> + "RTE_BBDEV_OP_FFT",
> };
>
> if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
> index b88c881..e9ca673 100644
> --- a/lib/bbdev/rte_bbdev.h
> +++ b/lib/bbdev/rte_bbdev.h
> @@ -380,6 +380,12 @@ typedef uint16_t (*rte_bbdev_enqueue_dec_ops_t)(
> struct rte_bbdev_dec_op **ops,
> uint16_t num);
>
> +/** @internal Enqueue fft operations for processing on queue of a device. */
> +typedef uint16_t (*rte_bbdev_enqueue_fft_ops_t)(
> + struct rte_bbdev_queue_data *q_data,
> + struct rte_bbdev_fft_op **ops,
> + uint16_t num);
> +
> /** @internal Dequeue encode operations from a queue of a device. */
> typedef uint16_t (*rte_bbdev_dequeue_enc_ops_t)(
> struct rte_bbdev_queue_data *q_data,
> @@ -390,6 +396,11 @@ typedef uint16_t (*rte_bbdev_dequeue_dec_ops_t)(
> struct rte_bbdev_queue_data *q_data,
> struct rte_bbdev_dec_op **ops, uint16_t num);
>
> +/** @internal Dequeue fft operations from a queue of a device. */
> +typedef uint16_t (*rte_bbdev_dequeue_fft_ops_t)(
> + struct rte_bbdev_queue_data *q_data,
> + struct rte_bbdev_fft_op **ops, uint16_t num);
> +
> #define RTE_BBDEV_NAME_MAX_LEN 64 /**< Max length of device name */
>
> /**
> @@ -438,6 +449,10 @@ struct __rte_cache_aligned rte_bbdev {
> rte_bbdev_dequeue_enc_ops_t dequeue_ldpc_enc_ops;
> /** Dequeue decode function */
> rte_bbdev_dequeue_dec_ops_t dequeue_ldpc_dec_ops;
> + /** Enqueue FFT function */
> + rte_bbdev_enqueue_fft_ops_t enqueue_fft_ops;
> + /** Dequeue FFT function */
> + rte_bbdev_dequeue_fft_ops_t dequeue_fft_ops;
> const struct rte_bbdev_ops *dev_ops; /**< Functions exported by PMD */
> struct rte_bbdev_data *data; /**< Pointer to device data */
> enum rte_bbdev_state state; /**< If device is currently used or not */
Since rte_bbdev is exposed in rte_bbdev.h it can not be changed without
breaking ABI. It would have been better if data structure was better hidden
(hint).
But you can't change it now until 22.11
[PATCH v1] raw/ifpga: remove vdev when ifpga is closed
Virtual devices created on ifpga raw device are not removed when
ifpga is closed. To avoid such problem, ifpga virtual device remove
function is implemented, virtual device is removed in raw device
close function.
Signed-off-by: Wei Huang
Acked-by: Tianfei Zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga/ifpga_rawdev.c | 137 +--
drivers/raw/ifpga/ifpga_rawdev.h | 8 +++
2 files changed, 109 insertions(+), 36 deletions(-)
diff --git a/drivers/raw/ifpga/ifpga_rawdev.c b/drivers/raw/ifpga/ifpga_rawdev.c
index 26c1366..9f4a3ce 100644
--- a/drivers/raw/ifpga/ifpga_rawdev.c
+++ b/drivers/raw/ifpga/ifpga_rawdev.c
@@ -134,6 +134,8 @@ struct ifpga_rawdev *
for (i = 0; i < IFPGA_MAX_IRQ; i++)
dev->intr_handle[i] = NULL;
dev->poll_enabled = 0;
+ for (i = 0; i < IFPGA_MAX_VDEV; i++)
+ dev->vdev_name[i] = NULL;
return dev;
}
@@ -735,10 +737,24 @@ static int set_surprise_link_check_aer(
static int
ifpga_rawdev_close(struct rte_rawdev *dev)
{
+ struct ifpga_rawdev *ifpga_rdev = NULL;
struct opae_adapter *adapter;
+ char *vdev_name = NULL;
+ int i = 0;
if (dev) {
- ifpga_monitor_stop_func(ifpga_rawdev_get(dev));
+ ifpga_rdev = ifpga_rawdev_get(dev);
+ if (ifpga_rdev) {
+ for (i = 0; i < IFPGA_MAX_VDEV; i++) {
+ vdev_name = ifpga_rdev->vdev_name[i];
+ if (!rte_vdev_uninit(vdev_name)) {
+ rte_free(vdev_name);
+ ifpga_rdev->vdev_name[i] = NULL;
+ }
+ }
+ ifpga_monitor_stop_func(ifpga_rdev);
+ ifpga_rdev->rawdev = NULL;
+ }
adapter = ifpga_rawdev_get_priv(dev);
if (adapter) {
opae_adapter_destroy(adapter);
@@ -1637,8 +1653,6 @@ static int fme_clean_fme_error(struct opae_manager *mgr)
return -EINVAL;
}
dev = ifpga_rawdev_get(rawdev);
- if (dev)
- dev->rawdev = NULL;
adapter = ifpga_rawdev_get_priv(rawdev);
if (!adapter)
@@ -1713,73 +1727,113 @@ static int ifpga_rawdev_get_string_arg(const char *key
__rte_unused,
return 0;
}
+
static int
-ifpga_cfg_probe(struct rte_vdev_device *dev)
+ifpga_vdev_parse_devargs(struct rte_devargs *devargs,
+ struct ifpga_vdev_args *args)
{
- struct rte_devargs *devargs;
- struct rte_kvargs *kvlist = NULL;
- struct rte_rawdev *rawdev = NULL;
- struct ifpga_rawdev *ifpga_dev;
- int port;
+ struct rte_kvargs *kvlist;
char *name = NULL;
- char dev_name[RTE_RAWDEV_NAME_MAX_LEN];
- int ret = -1;
+ int port = 0;
+ int ret = -EINVAL;
- devargs = dev->device.devargs;
+ if (!devargs || !args)
+ return ret;
kvlist = rte_kvargs_parse(devargs->args, valid_args);
if (!kvlist) {
- IFPGA_RAWDEV_PMD_LOG(ERR, "error when parsing param");
- goto end;
+ IFPGA_RAWDEV_PMD_ERR("error when parsing devargs");
+ return ret;
}
if (rte_kvargs_count(kvlist, IFPGA_ARG_NAME) == 1) {
if (rte_kvargs_process(kvlist, IFPGA_ARG_NAME,
- &ifpga_rawdev_get_string_arg,
- &name) < 0) {
+ &ifpga_rawdev_get_string_arg, &name) < 0) {
IFPGA_RAWDEV_PMD_ERR("error to parse %s",
-IFPGA_ARG_NAME);
+ IFPGA_ARG_NAME);
goto end;
+ } else {
+ strlcpy(args->bdf, name, sizeof(args->bdf));
+ rte_free(name);
}
} else {
IFPGA_RAWDEV_PMD_ERR("arg %s is mandatory for ifpga bus",
- IFPGA_ARG_NAME);
+ IFPGA_ARG_NAME);
goto end;
}
if (rte_kvargs_count(kvlist, IFPGA_ARG_PORT) == 1) {
- if (rte_kvargs_process(kvlist,
- IFPGA_ARG_PORT,
- &rte_ifpga_get_integer32_arg,
- &port) < 0) {
+ if (rte_kvargs_process(kvlist, IFPGA_ARG_PORT,
+ &rte_ifpga_get_integer32_arg, &port) < 0) {
IFPGA_RAWDEV_PMD_ERR("error to parse %s",
IFPGA_ARG_PORT);
goto end;
+ } else {
+ args->port = port;
}
} else {
IFPGA_RAWDEV_PMD_ERR("arg %s is mandatory for ifpga bus",
- IFPGA_ARG_PORT);
+ IFPGA_ARG_PORT);
RE: [PATCH v1] sched: enable/disable TC OV at runtime
>
> > diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index
> > ec74bee939..1d05089d00 100644
> > --- a/lib/sched/rte_sched.c
> > +++ b/lib/sched/rte_sched.c
> > @@ -155,6 +155,7 @@ struct rte_sched_subport {
> > uint64_t tc_credits[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> >
> > /* TC oversubscription */
> > + uint8_t is_tc_ov_enabled;
> > uint64_t tc_ov_wm;
> > uint64_t tc_ov_wm_min;
> > uint64_t tc_ov_wm_max;
>
> Putting the field there creates a hole in the structure.
> Put it after tc_ov and fill an existing hole.
>
> This is pahole of current code, looks like this struct could use some work to
> be
> better packed and aligned.
>
Thanks Stephen for pointing this out. I agree there is some work needed to pack
this structure better.
Can we take this up in a separate patch in later release as it requires more
performance test runs to see the impact ?
RE: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi-segments
Hi, Ferruh
Yuying has already reviewed it days ago.
If you can, I hope you can change the status as soon as possible and try to
merge the code in RC4.
Thank you.
> -Original Message-
> From: Zhang, Yuying
> Sent: 2022年3月3日 14:30
> To: Zhang, Qi Z ; Liu, KevinX ;
> dev
> Cc: Yang, Qiming ; Yang, SteveX
> ; Yigit, Ferruh ; Xing, Beilei
> ; Li, Xiaoyun ; dpdk stable
>
> Subject: RE: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi-
> segments
>
> LGTM.
>
> > > -Original Message-
> > > From: Liu, KevinX
> > > Sent: Wednesday, December 29, 2021 5:37 PM
> > > To: dev@dpdk.org
> > > Cc: Yang, Qiming ; Zhang, Qi Z
> > > ; Yang, SteveX ; Yigit,
> > > Ferruh ; Liu, KevinX ;
> > > sta...@dpdk.org
> > > Subject: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in
> > > multi-segments
> > >
> > > Testpmd forwards packets in checksum mode that it needs to calculate
> > > the checksum of each layer's protocol.
> > >
> > > In process_inner_cksums, when parsing tunnel packets, inner L4
> > > offset should be outer_l2_len + outer_l3_len + l2_len + l3_len.
> > >
> > > In process_outer_cksums, when parsing tunnel packets, outer L4
> > > offset should be outer_l2_len + outer_l3_len.
> > >
> > > Fixes: e6b9d6411e91 ("app/testpmd: add SW L4 checksum in multi-
> > > segments")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Kevin Liu
>
> Acked-by: Yuying Zhang
>
> > > ---
> > > app/test-pmd/csumonly.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index
> > > 02bc3929c7..c235456e58 100644
> > > --- a/app/test-pmd/csumonly.c
> > > +++ b/app/test-pmd/csumonly.c
> >
> >
> > > @@ -513,7 +513,7 @@ process_inner_cksums(void *l3_hdr, const struct
> > > testpmd_offload_info *info, ol_flags |=
> RTE_MBUF_F_TX_UDP_CKSUM; }
> > > else { if (info->is_tunnel) -l4_off = info->l2_len +
> > > +l4_off = info->outer_l2_len +
> > > info->outer_l3_len +
> > > info->l2_len + info->l3_len;
> > > else
> > > @@ -536,7 +536,7 @@ process_inner_cksums(void *l3_hdr, const struct
> > > testpmd_offload_info *info, ol_flags |=
> RTE_MBUF_F_TX_TCP_CKSUM; }
> > > else { if (info->is_tunnel) -l4_off = info->l2_len +
> > > info->outer_l3_len +
> > > +l4_off = info->outer_l2_len + info-
> > > >outer_l3_len +
> > > info->l2_len + info->l3_len;
> > > else
> > > l4_off = info->l2_len + info->l3_len; @@ -
> > > 625,7 +625,7 @@ process_outer_cksums(void *outer_l3_hdr, struct
> > > testpmd_offload_info *info, if (udp_hdr->dgram_cksum != 0) {
> > > udp_hdr->dgram_cksum = 0; udp_hdr->dgram_cksum =
> > > get_udptcp_checksum(m, outer_l3_hdr,
> > > -info->l2_len + info->outer_l3_len,
> > > +info->outer_l2_len + info-
> > > >outer_l3_len,
> > > info->outer_ethertype);
> > > }
> > >
> > > --
> > > 2.33.1
> >
