RE: [PATCH v9 2/4] ethdev: introduce protocol hdr based buffer split
Hi,
> -Original Message-
> From: Andrew Rybchenko
> Sent: Monday, August 1, 2022 10:28 PM
> To: Ding, Xuan
> Cc: dev@dpdk.org; step...@networkplumber.org; Wang, YuanX
> ; Ray Kinsella ; Wu, WenxuanX
> ; tho...@monjalon.net; Li, Xiaoyun
> ; ferruh.yi...@xilinx.com; Singh, Aman Deep
> ; Zhang, Yuying ;
> Zhang, Qi Z ; jerinjac...@gmail.com;
> viachesl...@nvidia.com
> Subject: Re: [PATCH v9 2/4] ethdev: introduce protocol hdr based buffer split
>
> On 7/21/22 06:24, Ding, Xuan wrote:
> > Hi Andrew,
> >
> >> -Original Message-
> >> From: Andrew Rybchenko
> >> Sent: 2022年7月8日 23:01
> >> To: Wu, WenxuanX ; tho...@monjalon.net;
> Li,
> >> Xiaoyun ; ferruh.yi...@xilinx.com; Singh, Aman
> >> Deep ; dev@dpdk.org; Zhang, Yuying
> >> ; Zhang, Qi Z ;
> >> jerinjac...@gmail.com
> >> Cc: step...@networkplumber.org; Ding, Xuan ;
> >> Wang, YuanX ; Ray Kinsella
> >> Subject: Re: [PATCH v9 2/4] ethdev: introduce protocol hdr based
> >> buffer split
> >>
> >> On 6/13/22 13:25, wenxuanx...@intel.com wrote:
> >>> From: Wenxuan Wu
> >>>
> >>> Currently, Rx buffer split supports length based split. With Rx
> >>> queue offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and Rx
> packet
> >> segment
> >>> configured, PMD will be able to split the received packets into
> >>> multiple segments.
> >>>
> >>> However, length based buffer split is not suitable for NICs that do
> >>> split based on protocol headers. Given an arbitrarily variable
> >>> length in Rx packet segment, it is almost impossible to pass a fixed
> >>> protocol header to driver. Besides, the existence of tunneling
> >>> results in the composition of a packet is various, which makes the
> situation even worse.
> >>>
> >>> This patch extends current buffer split to support protocol header
> >>> based buffer split. A new proto_hdr field is introduced in the
> >>> reserved field of rte_eth_rxseg_split structure to specify protocol
> >>> header. The proto_hdr field defines the split position of packet,
> >>> splitting will always happens after the protocol header defined in
> >>> the Rx packet segment. When Rx queue offload
> >>> RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is enabled and corresponding
> >>> protocol header is configured, driver will split the ingress packets
> >>> into multiple
> >> segments.
> >>>
> >>> struct rte_eth_rxseg_split {
> >>>
> >>> struct rte_mempool *mp; /* memory pools to allocate segment
> from */
> >>> uint16_t length; /* segment maximal data length,
> >>> configures "split point" */
> >>> uint16_t offset; /* data offset from beginning
> >>> of mbuf data buffer */
> >>> uint32_t proto_hdr; /* inner/outer L2/L3/L4 protocol header,
> >>> configures "split point" */
> >>
> >> There is a big problem here that using RTE_PTYPE_* defines I can't
> >> request split after either TCP or UDP header.
> >
> > Sorry, for some reason I missed your reply.
> >
> > Current RTE_PTYPE_* list all the tunnel and L2/L3/L4 protocol headers
> (both outer and inner).
> > Do you mean that we should support higher layer protocols after L4?
> >
> > I think tunnel and L2/L3/L4 protocol headers are enough.
> > In DPDK, we don't parse higher level protocols after L4.
> > And the higher layer protocols are richer, we can't list all of them.
> > What do you think?
>
> It looks like you don't get my point. You simply cannot say:
> RTE_PTYPE_L4_TCP | RTE_PTYPE_L4_UDP since it is numerically equal to
> RTE_PTYPE_L4_FRAG. May be the design limitation is acceptable.
> I have no strong opinion, but it must be clear for all that the limitation
> exists.
Thanks for your correction.
Similarly, RTE_PTYPE_INNER_L4_TCP and RTE_PTYPE_INNER_L4_UDP
also exists this situation.
I will try to solve this limitation by following ptypes_get approach.
>
> >>
> >>> };
> >>>
> >>> If both inner and outer L2/L3/L4 level protocol header split can be
> >>> supported by a PMD. Corresponding protocol header capability is
> >>> RTE_PTYPE_L2_ETHER, RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV6,
> >>> RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP,
> >>> RTE_PTYPE_INNER_L2_ETHER, RTE_PTYPE_INNER_L3_IPV4,
> >>> RTE_PTYPE_INNER_L3_IPV6, RTE_PTYPE_INNER_L4_TCP,
> >> RTE_PTYPE_INNER_L4_UDP, RTE_PTYPE_INNER_L4_SCTP.
> >>
> >> I think there is no point to list above defines here if it is not the
> >> only supported defines.
> >
> > Yes, since we use a API to return the protocol header driver supported
> > to split, there is no need to list the incomplete RTE_PTYPE* here. Please
> see next version.
> >
> >>
> >>>
> >>> For example, let's suppose we configured the Rx queue with the
> >>> following segments:
> >>> seg0 - pool0, proto_hdr0=RTE_PTYPE_L3_IPV4, off0=2B
> >>> seg1 - pool1, proto_hdr1=RTE_PTYPE_L4_UDP, off1=128B
> >>> seg2 - pool2, off1=0B
> >>>
> >>> The packet consists of MAC_IPV4_UDP_PAYLOAD will be split like
> >>> following:
> >>>
[PATCH v1] buildtools: ensure the NUMA nodes are counted correct
From: Peng Zhang
Sorting a list of strings with the format "node[0-9]+" in order to find the
largest integer by looking at the last item after the sort breaks. But if
there are more then 10 items as a string sort will sort "node10" before
"node2", it will get the error NUMA nodes.
Solve this by sorting the list based on the integer part of the string.
Fixes: 8ef09fdc506b ("build: add optional NUMA and CPU counts detection")
Cc: sta...@dpdk.org
Signed-off-by: Peng Zhang
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
buildtools/get-numa-count.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/buildtools/get-numa-count.py b/buildtools/get-numa-count.py
index 1b7787787f..2f243886cd 100644
--- a/buildtools/get-numa-count.py
+++ b/buildtools/get-numa-count.py
@@ -6,11 +6,12 @@
import glob
import os
import subprocess
+import re
if os.name == 'posix':
if os.path.isdir('/sys/devices/system/node'):
numa_nodes = glob.glob('/sys/devices/system/node/node*')
-numa_nodes.sort()
+numa_nodes.sort(key=lambda l: int(re.findall('\d+', l)[0]))
print(int(os.path.basename(numa_nodes[-1])[4:]) + 1)
else:
subprocess.run(['sysctl', '-n', 'vm.ndomains'], check=False)
--
2.27.0
[PATCH v1] net/nfp: compose firmware file name with new hwinfo
From: Peng Zhang
During initialization of the NFP driver, a file name for loading
application firmware is composed using the NIC's AMDA information and port
type (count and speed). E.g.: "nic_AMDA0145-1012_2x10.nffw".
In practice there may be many variants for each NIC type, and many of the
variants relate to assembly components which do not concern the driver and
application firmware implementation. Yet the current scheme leads to a
different application firmware file name for each variant, because they
have different AMDA information.
To reduce proliferation of content-duplicated application firmware images
or symlinks, the NIC's management firmware will only expose differences
between variants that need different application firmware via a newly
introduced hwinfo, "nffw.partno".
Use of the existing hwinfo, "assembly.partno", is maintained in order to
support for NICs with management firmware that does not expose
"nffw.partno".
Fixes: 646ea79ce481 ("net/nfp: move PF functions into its own file")
Cc: sta...@dpdk.org
Signed-off-by: Peng Zhang
Reviewed-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_ethdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 5cdd34e588..e9d01f4414 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -680,7 +680,9 @@ nfp_fw_setup(struct rte_pci_device *dev,
char card_desc[100];
int err = 0;
- nfp_fw_model = nfp_hwinfo_lookup(hwinfo, "assembly.partno");
+ nfp_fw_model = nfp_hwinfo_lookup(hwinfo, "nffw.partno");
+ if (nfp_fw_model == NULL)
+ nfp_fw_model = nfp_hwinfo_lookup(hwinfo, "assembly.partno");
if (nfp_fw_model) {
PMD_DRV_LOG(INFO, "firmware model found: %s", nfp_fw_model);
--
2.27.0
Re: 21.11.2 patches review and test
On Tue, 2022-08-02 at 11:29 +0800, YangHang Liu wrote: > Hi Luca, > > The dpdk 21.11.2-rc1 test result from Red Hat looks good. > > We tested below 17 scenarios and all got PASS on RHEL8: > * Guest with device assignment(PF) throughput testing(1G hugepage > size): PASS > * Guest with device assignment(PF) throughput testing(2M hugepage > size) : PASS > * Guest with device assignment(VF) throughput testing: PASS > * PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS > * PVP vhost-user 2Q throughput testing: PASS > * PVP vhost-user 1Q - cross numa node throughput testing: PASS > * Guest with vhost-user 2 queues throughput testing: PASS > * vhost-user reconnect with dpdk-client, qemu-server: qemu > reconnect: PASS > * vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: > PASS > * PVP 1Q live migration testing: PASS > * PVP 1Q cross numa node live migration testing: PASS > * Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS > * Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): > PASS > * Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS > * Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS > * Host PF + DPDK testing: PASS > * Host VF + DPDK testing: PASS > > Versions: > * kernel 4.18 > * qemu 6.2 > * dpdk: git://dpdk.org/dpdk-stable (remotes/origin/21.11) > - # git log > Author: Luca Boccassi > Date: Mon Jul 18 09:56:26 2022 +0100 > version: 21.11.2-rc1 > Signed-off-by: Luca Boccassi > * NICs: X540-AT2 NIC(ixgbe, 10G) > > > > Best Regards, > YangHang Liu Thank you! > On Thu, Jul 28, 2022 at 8:34 PM Luca Boccassi > wrote: > > On Mon, 2022-07-18 at 10:58 +0100, luca.bocca...@gmail.com wrote: > > > Hi all, > > > > > > Here is a list of patches targeted for stable release 21.11.2. > > > > > > The planned date for the final release is August 29th. > > > > > > Please help with testing and validation of your use cases and > > report > > > any issues/results with reply-all to this mail. For the final > > release > > > the fixes and reported validations will be added to the release > > notes. > > > > > > A release candidate tarball can be found at: > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.2-rc1 > > > > > > These patches are located at branch 21.11 of dpdk-stable repo: > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > Thanks. > > > > > > Luca Boccassi > > > > Hello, > > > > Any update from any of the validation teams? Any indication on how > > the > > tests are going? > >
Re: 21.11.2 patches review and test
On Fri, 2022-07-29 at 11:26 +, Jiang, YuX wrote: > > -Original Message- > > From: Jiang, YuX > > Sent: Friday, July 29, 2022 11:01 AM > > To: Luca Boccassi ; sta...@dpdk.org > > Cc: dev@dpdk.org; Abhishek Marathe > > ; > > Ali Alnubani ; Walker, Benjamin > > ; David Christensen > > ; Hemant Agrawal ; > > Stokes, Ian ; Jerin Jacob > > ; > > Mcnamara, John ; Ju-Hyoung Lee > > ; Kevin Traynor ; Pei > > Zhang > > ; Xu, Qian Q ; Raslan > > Darawsheh ; Thomas Monjalon > > ; Peng, Yuan ; Chen, > > Zhaoyan ; yangh...@redhat.com > > Subject: RE: 21.11.2 patches review and test > > > > > -Original Message- > > > From: Luca Boccassi > > > Sent: Thursday, July 28, 2022 8:34 PM > > > To: sta...@dpdk.org > > > Cc: dev@dpdk.org; Abhishek Marathe > > ; > > > Ali Alnubani ; Walker, Benjamin > > > ; David Christensen > > > ; Hemant Agrawal > > > ; > > > Stokes, Ian ; Jerin Jacob < > > > jer...@marvell.com>; > > > Mcnamara, John ; Ju-Hyoung Lee > > > ; Kevin Traynor ; Pei > > Zhang > > > ; Xu, Qian Q ; Raslan > > > Darawsheh ; Thomas Monjalon > > ; > > > Peng, Yuan ; Chen, Zhaoyan > > > ; yangh...@redhat.com > > > Subject: Re: 21.11.2 patches review and test > > > > > > On Mon, 2022-07-18 at 10:58 +0100, luca.bocca...@gmail.com wrote: > > > > Hi all, > > > > > > > > Here is a list of patches targeted for stable release 21.11.2. > > > > > > > > The planned date for the final release is August 29th. > > > > > > > > Please help with testing and validation of your use cases and > > > > report > > > > any issues/results with reply-all to this mail. For the final > > > > release the fixes and reported validations will be added to the > > > > release > > notes. > > > > > > > > A release candidate tarball can be found at: > > > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.2-rc1 > > > > > > > > These patches are located at branch 21.11 of dpdk-stable repo: > > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > > > Thanks. > > > > > > > > Luca Boccassi > > > > > > Hello, > > > > > > Any update from any of the validation teams? Any indication on > > > how the > > > tests are going? > > > > > > -- > > > Kind regards, > > > Luca Boccassi > > > > Everything is fine, find one vhost related issue which is > > investigated by Intel > > Dev. > > I will send a v1 report later. Thanks. > > > > Best regards, > > Yu Jiang > > Update the test status for Intel part. Till now dpdk21.11.2-rc1 test > rate is 90%, no critical issue is found. > Failure defects as below: > Bug1: [dpdk v21.11.2-rc1] examples/performance-thread meson build > error with gcc12.1 on fedora36 > Bug2: DPDK 21.11.1 cryptodev_qat_raw_api_autotest failing > - Intel Dev send a patch to skip oop test for raw api, need > be reviewed and merged. Hi, Do you have a reference to this patch? I did not see anything new sent to stable in the past week or so > Bug3: [21.11LTS]Test with the new local patch, Vhost-user meet > Segmentation fault issue when quit virtio-user before stopping > sending packets > - Intel Dev is under investigating. > > # Basic Intel(R) NIC testing > * Build&CFLAG compile: cover the build test combination with latest > GCC/Clang version and the popular OS revision such as > Ubuntu20.04&22.04, Fedora36, RHEL8.4, etc. > - All test done. Find one new defect as Bug1. > * PF(i40e, ixgbe): test scenarios including > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > - Test rate is 90%. No new dpdk issue is found. > * VF(i40e, ixgbe): test scenarios including VF- > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, > etc. > - Test rate is 90%. No new dpdk issue is found. > * PF/VF(ice): test scenarios including Switch features/Package > Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible > Descriptor, etc. > - All test done. No new dpdk issue is found. > * Intel NIC single core/NIC performance: test scenarios including > PF/VF single core performance test, etc. > - All test done. No big performance drop. > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic > test - QAT&SW/FIB library, etc. > - All test passed. > * Power: test scenarios including bi-direction/Telemetry/Empty Poll > Lib/Priority Base Frequency, etc. > - All test passed. > > # 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. Find one new issue, Intel Dev is under > investigating. > - Bug Summary:[21.11LTS]Test with the new local patch, Vhost- > user meet Segmentation fault issue when quiting virtio-user before > stopping sending packets > * Cryptodev: > *Function test: test scenarios including Cryptodev API > testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. > - All test done. Only one defect as the above. > *Performance test: test s
RE: [PATCH v9 1/4] ethdev: introduce protocol header API
Hi Thomas, > -Original Message- > From: Thomas Monjalon > Sent: Monday, August 1, 2022 6:01 PM > To: Wang, YuanX > Cc: andrew.rybche...@oktetlabs.ru; Li, Xiaoyun ; > ferruh.yi...@xilinx.com; Singh, Aman Deep ; > dev@dpdk.org; Zhang, Yuying ; Zhang, Qi Z > ; jerinjac...@gmail.com; > step...@networkplumber.org; Wu, WenxuanX ; > Ding, Xuan > Subject: Re: [PATCH v9 1/4] ethdev: introduce protocol header API > > 01/08/2022 09:09, Wang, YuanX: > > Hi Thomas, > > > > Sorry so long to response your email. > > > > From: Thomas Monjalon > > > 13/06/2022 12:25, wenxuanx...@intel.com: > > > > From: Wenxuan Wu > > > > > > > > This patch added new ethdev API to retrieve supported protocol > > > > header mask of a PMD, which helps to configure protocol header based > buffer split. > > > > > > > > Signed-off-by: Wenxuan Wu > > > > --- > > > > +/** > > > > + * @warning > > > > + * @b EXPERIMENTAL: this API may change without prior notice > > > > + * > > > > + * Get supported header protocols to split supported by PMD. > > > > + * The API will return error if the device is not valid. > > > > + * > > > > + * @param port_id > > > > + * The port identifier of the device. > > > > + * @param ptype > > > > + * Supported protocol headers of driver. > > > > > > It doesn't say where to find the types. > > > Please give the prefix. > > > > Sorry I didn't catch your point, are you referring the ptype should be > composed of RTE_PTYPE_*? > > Could you explain it in more detail? > > Yes just give to the user the required info to use the function. > If ptype must be composed with RTE_PTYPE_*, it must be said. Thanks for your explanation, will fix in the next version. Thanks, Yuan > > Thanks >
RE: 21.11.2 patches review and test
> -Original Message- > From: Luca Boccassi > Sent: Tuesday, August 2, 2022 6:01 PM > To: Jiang, YuX ; sta...@dpdk.org > Cc: dev@dpdk.org; Walker, Benjamin ; Raslan > Darawsheh ; Thomas Monjalon > ; yangh...@redhat.com > Subject: Re: 21.11.2 patches review and test > > On Fri, 2022-07-29 at 11:26 +, Jiang, YuX wrote: > > > -Original Message- > > > From: Jiang, YuX > > > Sent: Friday, July 29, 2022 11:01 AM > > > To: Luca Boccassi ; sta...@dpdk.org > > > Cc: dev@dpdk.org; Abhishek Marathe > > > ; > > > Ali Alnubani ; Walker, Benjamin > > > ; David Christensen > > > ; Hemant Agrawal > ; > > > Stokes, Ian ; Jerin Jacob > > > ; Mcnamara, John ; > > > Ju-Hyoung Lee ; Kevin Traynor > > > ; Pei Zhang ; Xu, Qian Q > > > ; Raslan Darawsheh ; > Thomas > > > Monjalon ; Peng, Yuan > ; > > > Chen, Zhaoyan ; yangh...@redhat.com > > > Subject: RE: 21.11.2 patches review and test > > > > > > > -Original Message- > > > > From: Luca Boccassi > > > > Sent: Thursday, July 28, 2022 8:34 PM > > > > To: sta...@dpdk.org > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > ; > > > > Ali Alnubani ; Walker, Benjamin > > > > ; David Christensen > > > > ; Hemant Agrawal > ; > > > > Stokes, Ian ; Jerin Jacob < > > > > jer...@marvell.com>; Mcnamara, John ; > > > > Ju-Hyoung Lee ; Kevin Traynor > > > > ; Pei > > > Zhang > > > > ; Xu, Qian Q ; Raslan > > > > Darawsheh ; Thomas Monjalon > > > ; > > > > Peng, Yuan ; Chen, Zhaoyan > > > > ; yangh...@redhat.com > > > > Subject: Re: 21.11.2 patches review and test > > > > > > > > On Mon, 2022-07-18 at 10:58 +0100, luca.bocca...@gmail.com wrote: > > > > > Hi all, > > > > > > > > > > Here is a list of patches targeted for stable release 21.11.2. > > > > > > > > > > The planned date for the final release is August 29th. > > > > > > > > > > Please help with testing and validation of your use cases and > > > > > report any issues/results with reply-all to this mail. For the > > > > > final release the fixes and reported validations will be added > > > > > to the release > > > notes. > > > > > > > > > > A release candidate tarball can be found at: > > > > > > > > > > https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.2-rc1 > > > > > > > > > > These patches are located at branch 21.11 of dpdk-stable repo: > > > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > > > > > Thanks. > > > > > > > > > > Luca Boccassi > > > > > > > > Hello, > > > > > > > > Any update from any of the validation teams? Any indication on how > > > > the tests are going? > > > > > > > > -- > > > > Kind regards, > > > > Luca Boccassi > > > > > > Everything is fine, find one vhost related issue which is > > > investigated by Intel Dev. > > > I will send a v1 report later. Thanks. > > > > > > Best regards, > > > Yu Jiang > > > > Update the test status for Intel part. Till now dpdk21.11.2-rc1 test > > rate is 90%, no critical issue is found. > > Failure defects as below: > > Bug1: [dpdk v21.11.2-rc1] examples/performance-thread meson build > > error with gcc12.1 on fedora36 > > Bug2: DPDK 21.11.1 cryptodev_qat_raw_api_autotest failing > > - Intel Dev send a patch to skip oop test for raw api, need be > > reviewed and merged. > > Hi, > > Do you have a reference to this patch? I did not see anything new sent to > stable in the past week or so > Yes, he only send an attached file, I will check this with Intel Dev. Thanks. > > Bug3: [21.11LTS]Test with the new local patch, Vhost-user meet > > Segmentation fault issue when quit virtio-user before stopping sending > > packets > > - Intel Dev is under investigating. --- Intel Dev is preparing dpdk patch~, Thanks. Best regards, Yu Jiang > > > > # Basic Intel(R) NIC testing > > * Build&CFLAG compile: cover the build test combination with latest > > GCC/Clang version and the popular OS revision such as > > Ubuntu20.04&22.04, Fedora36, RHEL8.4, etc. > > - All test done. Find one new defect as Bug1. > > * PF(i40e, ixgbe): test scenarios including > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. > > - Test rate is 90%. No new dpdk issue is found. > > * VF(i40e, ixgbe): test scenarios including VF- > > RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, > > etc. > > - Test rate is 90%. No new dpdk issue is found. > > * PF/VF(ice): test scenarios including Switch features/Package > > Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible > > Descriptor, etc. > > - All test done. No new dpdk issue is found. > > * Intel NIC single core/NIC performance: test scenarios including > > PF/VF single core performance test, etc. > > - All test done. No big performance drop. > > * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic > > test - QAT&SW/FIB library, etc. > > - All test passed. > > * Power: test scenarios including bi-direction/Telemetry/Empty Poll > > Lib/Priority Base Frequency, etc. > > - All test passed. > > > > # Basic cryptodev and virtio testing > > * Virtio: both fu
[PATCH] doc: add removal note for power empty poll API
Add removal note for experimental empty poll API. CC: David Hunt Signed-off-by: Reshma Pattan --- doc/guides/prog_guide/power_man.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/prog_guide/power_man.rst b/doc/guides/prog_guide/power_man.rst index 98cfd3c1f3..2e47d87cbb 100644 --- a/doc/guides/prog_guide/power_man.rst +++ b/doc/guides/prog_guide/power_man.rst @@ -192,6 +192,12 @@ User Cases -- The mechanism can applied to any device which is based on polling. e.g. NIC, FPGA. +Removal Note + +The experimental empty poll APIs will be removed from the library in a future DPDK release. +Suggest to use new lcore poll busyness APIs added in 22.11. + + Ethernet PMD Power Management API - -- 2.27.0
[RFC] doc: update required kernel version to 4.14
The 4.4 kernel was end of life in February 2022, and the next LTS is 4.9 and it is reaching EOL in January 2023. The main distro using 4.9 is Debian Stretch and it is no longer supported. When DPDK 22.11 is released, the 4.9 kernel would only be receiving fixes for three months; therefore lets make the official version 4.14. As always, current major enterprise Linux releases will continue to be supported, but those releases don't track regular kernel version numbering. For full details on kernel support see: https://www.kernel.org/category/releases.html https://en.wikipedia.org/wiki/Linux_kernel_version_history Debian Stretch: https://www.debian.org/releases/stretch/ Signed-off-by: Stephen Hemminger --- doc/guides/linux_gsg/sys_reqs.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst index 08d45898f025..ed22b6e80b4c 100644 --- a/doc/guides/linux_gsg/sys_reqs.rst +++ b/doc/guides/linux_gsg/sys_reqs.rst @@ -105,7 +105,7 @@ System Software **Required:** -* Kernel version >= 4.4 +* Kernel version >= 4.14 The kernel version required is based on the oldest long term stable kernel available at kernel.org when the DPDK version is in development. -- 2.35.1
Re: [PATCH v3 0/2] vhost fixes for OVS SIGSEGV in PMD
On Tue, 2 Aug 2022 02:49:36 +0200 Claudio Fontana wrote: > This is an alternative, more general fix compared with PATCH v1, > and fixes style issues in v2. > > The series fixes a segmentation fault in the OVS PMD thread when > resynchronizing with QEMU after the guest application has been killed > with SIGKILL (patch 1/2), > > The segmentation fault can be caused by the guest DPDK application, > which is able this way to crash the OVS process on the host, > see the backtrace in patch 1/2. > > Patch 2/2 is an additional improvement in the current error handling. Checking for NULL and 0 is good on host side. But guest should probably not be sending such a useless request?
RE: [RFC] doc: update required kernel version to 4.14
> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 2 August 2022 17.36 > > The 4.4 kernel was end of life in February 2022, > and the next LTS is 4.9 and it is reaching EOL in January 2023. > The main distro using 4.9 is Debian Stretch and it is no longer > supported. When DPDK 22.11 is released, the 4.9 kernel would > only be receiving fixes for three months; therefore > lets make the official version 4.14. Makes very good sense to me. > > As always, current major enterprise Linux releases will continue > to be supported, but those releases don't track regular kernel > version numbering. > > For full details on kernel support see: > https://www.kernel.org/category/releases.html > https://en.wikipedia.org/wiki/Linux_kernel_version_history > > Debian Stretch: > https://www.debian.org/releases/stretch/ > > Signed-off-by: Stephen Hemminger > --- > doc/guides/linux_gsg/sys_reqs.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/guides/linux_gsg/sys_reqs.rst > b/doc/guides/linux_gsg/sys_reqs.rst > index 08d45898f025..ed22b6e80b4c 100644 > --- a/doc/guides/linux_gsg/sys_reqs.rst > +++ b/doc/guides/linux_gsg/sys_reqs.rst > @@ -105,7 +105,7 @@ System Software > > **Required:** > > -* Kernel version >= 4.4 > +* Kernel version >= 4.14 > > The kernel version required is based on the oldest long term > stable kernel available > at kernel.org when the DPDK version is in development. Shouldn't we generalize your reasoning and update this too? It should reflect that we require more than 3 months to projected EOL, e.g. minimum one year. > -- > 2.35.1 >
[PATCH] app/testpmd: add command line argument 'nic-to-pmd-rx-metadata'
Presently, rx metadata is sent to PMD by default, leading
to a performance drop as processing for the same in rx path
takes extra cycles.
Hence, introducing command line argument, 'nic-to-pmd-rx-metadata'
to control passing rx metadata to PMD. By default it’s disabled.
Signed-off-by: Hanumanth Pothula
v2:
- taken care alignment issues
- renamed command line argument from rx-metadata to nic-to-pmd-rx-metadata
- renamed variable name from rx-metadata to nic_to_pmd_rx_metadata
---
app/test-pmd/parameters.c | 4
app/test-pmd/testpmd.c| 6 +-
app/test-pmd/testpmd.h| 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index e3c9757f3f..a381945492 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -213,6 +213,7 @@ usage(char* progname)
printf(" --hairpin-mode=0xXX: bitmask set the hairpin port mode.\n"
"0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n"
"0x01 - hairpin ports loop, 0x00 - hairpin port self\n");
+ printf(" --nic-to-pmd-rx-metadata: let the NIC deliver per-packet Rx
metadata to PMD\n");
}
#ifdef RTE_LIB_CMDLINE
@@ -710,6 +711,7 @@ launch_args_parse(int argc, char** argv)
{ "record-burst-stats", 0, 0, 0 },
{ PARAM_NUM_PROCS, 1, 0, 0 },
{ PARAM_PROC_ID,1, 0, 0 },
+ { "nic-to-pmd-rx-metadata", 0, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1510,6 +1512,8 @@ launch_args_parse(int argc, char** argv)
num_procs = atoi(optarg);
if (!strcmp(lgopts[opt_idx].name, PARAM_PROC_ID))
proc_id = atoi(optarg);
+ if (!strcmp(lgopts[opt_idx].name,
"nic-to-pmd-rx-metadata"))
+ nic_to_pmd_rx_metadata = 1;
break;
case 'h':
usage(argv[0]);
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index addcbcac85..2b17d4f757 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -411,6 +411,9 @@ uint8_t clear_ptypes = true;
/* Hairpin ports configuration mode. */
uint16_t hairpin_mode;
+/* Send Rx metadata */
+uint8_t nic_to_pmd_rx_metadata;
+
/* Pretty printing of ethdev events */
static const char * const eth_event_desc[] = {
[RTE_ETH_EVENT_UNKNOWN] = "unknown",
@@ -1628,7 +1631,8 @@ init_config_port_offloads(portid_t pid, uint32_t
socket_id)
int ret;
int i;
- eth_rx_metadata_negotiate_mp(pid);
+ if (nic_to_pmd_rx_metadata)
+ eth_rx_metadata_negotiate_mp(pid);
port->dev_conf.txmode = tx_mode;
port->dev_conf.rxmode = rx_mode;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index fb2f5195d3..294a9c8cf4 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -621,6 +621,8 @@ extern struct rte_ether_addr
peer_eth_addrs[RTE_MAX_ETHPORTS];
extern uint32_t burst_tx_delay_time; /**< Burst tx delay time(us) for
mac-retry. */
extern uint32_t burst_tx_retry_num; /**< Burst tx retry number for mac-retry.
*/
+extern uint8_t nic_to_pmd_rx_metadata;
+
#ifdef RTE_LIB_GRO
#define GRO_DEFAULT_ITEM_NUM_PER_FLOW 32
#define GRO_DEFAULT_FLOW_NUM (RTE_GRO_MAX_BURST_ITEM_NUM / \
--
2.25.1
[PATCH v2 2/2] app/testpmd: add command line argument 'nic-to-pmd-rx-metadata'
Presently, rx metadata is sent to PMD by default, leading
to a performance drop as processing for the same in rx path
takes extra cycles.
Hence, introducing command line argument, 'nic-to-pmd-rx-metadata'
to control passing rx metadata to PMD. By default it’s disabled.
Signed-off-by: Hanumanth Pothula
v2:
- taken cared alignment issues
- renamed command line argument from rx-metadata to nic-to-pmd-rx-metadata
- renamed variable name from rx-metadata to nic_to_pmd_rx_metadata
---
app/test-pmd/parameters.c | 4
app/test-pmd/testpmd.c| 6 +-
app/test-pmd/testpmd.h| 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index e3c9757f3f..a381945492 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -213,6 +213,7 @@ usage(char* progname)
printf(" --hairpin-mode=0xXX: bitmask set the hairpin port mode.\n"
"0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n"
"0x01 - hairpin ports loop, 0x00 - hairpin port self\n");
+ printf(" --nic-to-pmd-rx-metadata: let the NIC deliver per-packet Rx
metadata to PMD\n");
}
#ifdef RTE_LIB_CMDLINE
@@ -710,6 +711,7 @@ launch_args_parse(int argc, char** argv)
{ "record-burst-stats", 0, 0, 0 },
{ PARAM_NUM_PROCS, 1, 0, 0 },
{ PARAM_PROC_ID,1, 0, 0 },
+ { "nic-to-pmd-rx-metadata", 0, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1510,6 +1512,8 @@ launch_args_parse(int argc, char** argv)
num_procs = atoi(optarg);
if (!strcmp(lgopts[opt_idx].name, PARAM_PROC_ID))
proc_id = atoi(optarg);
+ if (!strcmp(lgopts[opt_idx].name,
"nic-to-pmd-rx-metadata"))
+ nic_to_pmd_rx_metadata = 1;
break;
case 'h':
usage(argv[0]);
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index addcbcac85..2b17d4f757 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -411,6 +411,9 @@ uint8_t clear_ptypes = true;
/* Hairpin ports configuration mode. */
uint16_t hairpin_mode;
+/* Send Rx metadata */
+uint8_t nic_to_pmd_rx_metadata;
+
/* Pretty printing of ethdev events */
static const char * const eth_event_desc[] = {
[RTE_ETH_EVENT_UNKNOWN] = "unknown",
@@ -1628,7 +1631,8 @@ init_config_port_offloads(portid_t pid, uint32_t
socket_id)
int ret;
int i;
- eth_rx_metadata_negotiate_mp(pid);
+ if (nic_to_pmd_rx_metadata)
+ eth_rx_metadata_negotiate_mp(pid);
port->dev_conf.txmode = tx_mode;
port->dev_conf.rxmode = rx_mode;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index fb2f5195d3..294a9c8cf4 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -621,6 +621,8 @@ extern struct rte_ether_addr
peer_eth_addrs[RTE_MAX_ETHPORTS];
extern uint32_t burst_tx_delay_time; /**< Burst tx delay time(us) for
mac-retry. */
extern uint32_t burst_tx_retry_num; /**< Burst tx retry number for mac-retry.
*/
+extern uint8_t nic_to_pmd_rx_metadata;
+
#ifdef RTE_LIB_GRO
#define GRO_DEFAULT_ITEM_NUM_PER_FLOW 32
#define GRO_DEFAULT_FLOW_NUM (RTE_GRO_MAX_BURST_ITEM_NUM / \
--
2.25.1
[PATCH v2 1/2] version: 22.11-rc0
From: David Marchand Start a new release cycle with empty release notes. The ABI version becomes 23.0. The map files are updated to the new ABI major number (23). The ABI exceptions are dropped and CI ABI checks are disabled because compatibility is not preserved. Special handling of removed drivers is also dropped in check-abi.sh and a note has been added in libabigail.abignore as a reminder. Signed-off-by: David Marchand Acked-by: Thomas Monjalon --- .github/workflows/build.yml| 4 +- .travis.yml| 21 +--- ABI_VERSION| 2 +- VERSION| 2 +- devtools/check-abi.sh | 4 - devtools/libabigail.abignore | 37 -- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_22_11.rst | 136 + drivers/baseband/acc100/version.map| 2 +- drivers/baseband/fpga_5gnr_fec/version.map | 2 +- drivers/baseband/fpga_lte_fec/version.map | 2 +- drivers/baseband/la12xx/version.map| 2 +- drivers/baseband/null/version.map | 2 +- drivers/baseband/turbo_sw/version.map | 2 +- drivers/bus/fslmc/version.map | 2 +- drivers/bus/ifpga/version.map | 2 +- drivers/bus/pci/version.map| 2 +- drivers/bus/vdev/version.map | 2 +- drivers/bus/vmbus/version.map | 2 +- drivers/common/qat/version.map | 2 +- drivers/compress/isal/version.map | 2 +- drivers/compress/mlx5/version.map | 2 +- drivers/compress/octeontx/version.map | 2 +- drivers/compress/zlib/version.map | 2 +- drivers/crypto/armv8/version.map | 2 +- drivers/crypto/bcmfs/version.map | 2 +- drivers/crypto/caam_jr/version.map | 2 +- drivers/crypto/ccp/version.map | 2 +- drivers/crypto/ipsec_mb/version.map| 2 +- drivers/crypto/mlx5/version.map| 2 +- drivers/crypto/mvsam/version.map | 2 +- drivers/crypto/nitrox/version.map | 2 +- drivers/crypto/null/version.map| 2 +- drivers/crypto/octeontx/version.map| 2 +- drivers/crypto/openssl/version.map | 2 +- drivers/crypto/scheduler/version.map | 2 +- drivers/crypto/virtio/version.map | 2 +- drivers/dma/cnxk/version.map | 2 +- drivers/dma/dpaa/version.map | 2 +- drivers/dma/dpaa2/version.map | 2 +- drivers/dma/hisilicon/version.map | 2 +- drivers/dma/idxd/version.map | 2 +- drivers/dma/ioat/version.map | 2 +- drivers/dma/skeleton/version.map | 2 +- drivers/event/dlb2/version.map | 2 +- drivers/event/dpaa/version.map | 2 +- drivers/event/dpaa2/version.map| 2 +- drivers/event/dsw/version.map | 2 +- drivers/event/octeontx/version.map | 2 +- drivers/event/opdl/version.map | 2 +- drivers/event/skeleton/version.map | 2 +- drivers/event/sw/version.map | 2 +- drivers/gpu/cuda/version.map | 2 +- drivers/mempool/bucket/version.map | 2 +- drivers/mempool/dpaa2/version.map | 2 +- drivers/mempool/octeontx/version.map | 2 +- drivers/mempool/ring/version.map | 2 +- drivers/mempool/stack/version.map | 2 +- drivers/net/af_packet/version.map | 2 +- drivers/net/af_xdp/version.map | 2 +- drivers/net/ark/version.map| 2 +- drivers/net/atlantic/version.map | 2 +- drivers/net/avp/version.map| 2 +- drivers/net/axgbe/version.map | 2 +- drivers/net/bnx2x/version.map | 2 +- drivers/net/bnxt/version.map | 2 +- drivers/net/bonding/version.map| 2 +- drivers/net/cnxk/version.map | 12 +- drivers/net/cxgbe/version.map | 2 +- drivers/net/dpaa/version.map | 2 +- drivers/net/dpaa2/version.map | 2 +- drivers/net/e1000/version.map | 2 +- drivers/net/ena/version.map| 2 +- drivers/net/enetc/version.map | 2 +- drivers/net/enetfec/version.map| 2 +- drivers/net/enic/version.map | 2 +- drivers/net/failsafe/version.map | 2 +- drivers/net/fm10k/version.map | 2 +- drivers/net/hinic/version.map | 2 +- drivers/net/hns3/version.map | 2 +- drivers/net/i40e/version.map | 2 +- drivers/net/iavf/version.map | 2 +- drivers/net/ice/version.map| 2 +- drivers/net/igc/version.map| 2 +- drivers/net/ionic/version.map | 2 +- drivers
Re: [PATCH v3 0/2] vhost fixes for OVS SIGSEGV in PMD
On 8/2/22 03:40, Stephen Hemminger wrote:
> On Tue, 2 Aug 2022 02:49:36 +0200
> Claudio Fontana wrote:
>
>> This is an alternative, more general fix compared with PATCH v1,
>> and fixes style issues in v2.
>>
>> The series fixes a segmentation fault in the OVS PMD thread when
>> resynchronizing with QEMU after the guest application has been killed
>> with SIGKILL (patch 1/2),
>>
>> The segmentation fault can be caused by the guest DPDK application,
>> which is able this way to crash the OVS process on the host,
>> see the backtrace in patch 1/2.
>>
>> Patch 2/2 is an additional improvement in the current error handling.
>
> Checking for NULL and 0 is good on host side.
> But guest should probably not be sending such a useless request?
Right, I focused on hardening the host side, as that is what the customer
required.
This happens specifically when the guest application goes away abruptly and has
no chance to signal anything (SIGKILL),
and at restart issues a virtio reset on the device, which in qemu causes also a
(actually two) virtio_net set_status, which attempt to stop the queues (twice).
DPDK seems to think at that point that it needs to drain the queue, and tries
to process MAX_PKT_BURST buffers
("about to dequeue 32 buffers"),
then calls fill_vec_buf_split and gets absolutely nothing.
I think this should also address the reports in this thread:
https://inbox.dpdk.org/dev/sa1pr08mb713373b0d19329c38c7527bb83...@sa1pr08mb7133.namprd08.prod.outlook.com/
in addition to my specific customer request,
Thanks,
Claudio
[PATCH v2 1/1] app/testpmd: add command line argument 'nic-to-pmd-rx-metadata'
Presently, rx metadata is sent to PMD by default, leading
to a performance drop as processing for the same in rx path
takes extra cycles.
Hence, introducing command line argument, 'nic-to-pmd-rx-metadata'
to control passing rx metadata to PMD. By default it’s disabled.
Signed-off-by: Hanumanth Pothula
v2:
- taken cared alignment issues
- renamed command line argument from rx-metadata to nic-to-pmd-rx-metadata
- renamed variable name from rx-metadata to nic_to_pmd_rx_metadata
---
app/test-pmd/parameters.c | 4
app/test-pmd/testpmd.c| 6 +-
app/test-pmd/testpmd.h| 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index e3c9757f3f..a381945492 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -213,6 +213,7 @@ usage(char* progname)
printf(" --hairpin-mode=0xXX: bitmask set the hairpin port mode.\n"
"0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n"
"0x01 - hairpin ports loop, 0x00 - hairpin port self\n");
+ printf(" --nic-to-pmd-rx-metadata: let the NIC deliver per-packet Rx
metadata to PMD\n");
}
#ifdef RTE_LIB_CMDLINE
@@ -710,6 +711,7 @@ launch_args_parse(int argc, char** argv)
{ "record-burst-stats", 0, 0, 0 },
{ PARAM_NUM_PROCS, 1, 0, 0 },
{ PARAM_PROC_ID,1, 0, 0 },
+ { "nic-to-pmd-rx-metadata", 0, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1510,6 +1512,8 @@ launch_args_parse(int argc, char** argv)
num_procs = atoi(optarg);
if (!strcmp(lgopts[opt_idx].name, PARAM_PROC_ID))
proc_id = atoi(optarg);
+ if (!strcmp(lgopts[opt_idx].name,
"nic-to-pmd-rx-metadata"))
+ nic_to_pmd_rx_metadata = 1;
break;
case 'h':
usage(argv[0]);
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index addcbcac85..2b17d4f757 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -411,6 +411,9 @@ uint8_t clear_ptypes = true;
/* Hairpin ports configuration mode. */
uint16_t hairpin_mode;
+/* Send Rx metadata */
+uint8_t nic_to_pmd_rx_metadata;
+
/* Pretty printing of ethdev events */
static const char * const eth_event_desc[] = {
[RTE_ETH_EVENT_UNKNOWN] = "unknown",
@@ -1628,7 +1631,8 @@ init_config_port_offloads(portid_t pid, uint32_t
socket_id)
int ret;
int i;
- eth_rx_metadata_negotiate_mp(pid);
+ if (nic_to_pmd_rx_metadata)
+ eth_rx_metadata_negotiate_mp(pid);
port->dev_conf.txmode = tx_mode;
port->dev_conf.rxmode = rx_mode;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index fb2f5195d3..294a9c8cf4 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -621,6 +621,8 @@ extern struct rte_ether_addr
peer_eth_addrs[RTE_MAX_ETHPORTS];
extern uint32_t burst_tx_delay_time; /**< Burst tx delay time(us) for
mac-retry. */
extern uint32_t burst_tx_retry_num; /**< Burst tx retry number for mac-retry.
*/
+extern uint8_t nic_to_pmd_rx_metadata;
+
#ifdef RTE_LIB_GRO
#define GRO_DEFAULT_ITEM_NUM_PER_FLOW 32
#define GRO_DEFAULT_FLOW_NUM (RTE_GRO_MAX_BURST_ITEM_NUM / \
--
2.25.1
[dpdk-kmods] windows/netuio: fix bar parsing
For certain PCIe devices, BAR values are not continuous.
This patch maps all the BARs and avoids skipping the next BAR addresses.
Fixes: e28aabd88279 ("windows/netuio: introduce NetUIO kernel driver")
Cc: navas...@microsoft.com
Signed-off-by: Qiao Liu
Signed-off-by: Pallavi Kadam
---
windows/netuio/netuio_dev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/windows/netuio/netuio_dev.c b/windows/netuio/netuio_dev.c
index b2deb10..e2cac3e 100644
--- a/windows/netuio/netuio_dev.c
+++ b/windows/netuio/netuio_dev.c
@@ -172,6 +172,7 @@ netuio_map_hw_resources(WDFDEVICE Device, WDFCMRESLIST
Resources, WDFCMRESLIST R
ULONG next_descriptor = 0;
ULONG curr_bar = 0;
ULONG prev_bar = 0;
+BOOLEAN bar_done = FALSE;
/*
* ResourcesTranslated report MMIO BARs in the correct order, but their
@@ -197,7 +198,8 @@ netuio_map_hw_resources(WDFDEVICE Device, WDFCMRESLIST
Resources, WDFCMRESLIST R
for (INT bar_index = 0; bar_index < PCI_MAX_BAR; bar_index++) {
prev_bar = curr_bar;
curr_bar = pci_config.u.type0.BaseAddresses[bar_index];
-if (curr_bar == 0 || (prev_bar & PCI_TYPE_64BIT)) {
+if (curr_bar == 0 || ((prev_bar & PCI_TYPE_64BIT) && (bar_done))) {
+bar_done = FALSE;
continue;
}
@@ -219,6 +221,7 @@ netuio_map_hw_resources(WDFDEVICE Device, WDFCMRESLIST
Resources, WDFCMRESLIST R
ctx->bar[bar_index].virt_addr =
MmMapIoSpace(descriptor->u.Memory.Start,
descriptor->u.Memory.Length,
MmNonCached);
+bar_done = TRUE;
if (ctx->bar[bar_index].virt_addr == NULL) {
status = STATUS_INSUFFICIENT_RESOURCES;
goto end;
--
2.31.1.windows.1
[PATCH v1] net/ice/base: fix symm RSS hash not valid for inner IPv4/6
Inner IPv4 and IPv6 symmetric RSS hash is not valid for raw pattern.
This patch fixes the issue by adding the corresponding protocol ID
for inner IPv4/6.
Fixes: 0837da2e27ae ("net/ice/base: support add HW profile for RSS raw
flow")
Cc: sta...@dpdk.org
Signed-off-by: Ting Xu
---
drivers/net/ice/base/ice_flow.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index bcbb9b12c4..0db474bd62 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -4092,6 +4092,8 @@ ice_rss_cfg_raw_symm(struct ice_hw *hw,
switch (proto_id) {
case ICE_PROT_IPV4_OF_OR_S:
+ case ICE_PROT_IPV4_IL:
+ case ICE_PROT_IPV4_IL_IL:
len = ICE_FLOW_FLD_SZ_IPV4_ADDR /
ICE_FLOW_FV_EXTRACT_SZ;
if (prof->fv[i].offset ==
@@ -4107,6 +4109,8 @@ ice_rss_cfg_raw_symm(struct ice_hw *hw,
i++;
continue;
case ICE_PROT_IPV6_OF_OR_S:
+ case ICE_PROT_IPV6_IL:
+ case ICE_PROT_IPV6_IL_IL:
len = ICE_FLOW_FLD_SZ_IPV6_ADDR /
ICE_FLOW_FV_EXTRACT_SZ;
if (prof->fv[i].offset ==
--
2.25.1
Re: 19.11.13 patches review and test
Hi Christian, The dpdk 19.11.13-rc1 test result from Red Hat looks good. We tested below 17 scenarios and all got PASS on RHEL8: - Guest with device assignment(PF) throughput testing(1G hugepage size): PASS - Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS - Guest with device assignment(VF) throughput testing: PASS - PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS - PVP vhost-user 2Q throughput testing: PASS - PVP vhost-user 1Q - cross numa node throughput testing: PASS - Guest with vhost-user 2 queues throughput testing: PASS - vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS - vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS - PVP 1Q live migration testing: PASS - PVP 1Q cross numa node live migration testing: PASS - Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS - Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS - Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS - Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS - Host PF + DPDK testing: PASS - Host VF + DPDK testing: PASS Versions: - kernel 4.18 - qemu 6.2 - dpdk: git://dpdk.org/dpdk-stable (remotes/origin/19.11) - # git log Author: Christian Ehrhardt Date: Mon Jul 18 11:14:00 2022 +0200 version: 19.11.13-rc1 Signed-off-by: Christian Ehrhardt - NICs: X540-AT2 NIC(ixgbe, 10G) Best Regards, YangHang Liu On Tue, Jul 19, 2022 at 1:33 PM Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > On Tue, Jul 19, 2022 at 4:43 AM Pei Zhang wrote: > > > > cc Yanghang Liu (yangh...@redhat.com). Yanghang is from the RedHat QE > team and will finish this dpdk testing with our test cases. > > > > Hello Christian, > > > > Could you also cc Yanghang in the future once there are new testing > requests :)? Thanks. > > Hi - Sure we can do that, > the list is tracked in http://git.dpdk.org/tools/stable-scripts/. > I've converted your request into a patch against that. > > > Best regards, > > > > Pei > > > > On Mon, Jul 18, 2022 at 6:19 PM > wrote: > >> > >> Hi all, > >> > >> Here is a list of patches targeted for stable release 19.11.13. > >> > >> The planned date for the final release is August 29th. > >> > >> Please help with testing and validation of your use cases and report > >> any issues/results with reply-all to this mail. For the final release > >> the fixes and reported validations will be added to the release notes. > >> > >> A release candidate tarball can be found at: > >> > >> https://dpdk.org/browse/dpdk-stable/tag/?id=v19.11.13-rc1 > >> > >> These patches are located at branch 19.11 of dpdk-stable repo: > >> https://dpdk.org/browse/dpdk-stable/ > >> > >> Thanks. > >> > >> Christian Ehrhardt > >> > >> --- > >> Abdullah Ömer Yamaç (1): > >> examples/distributor: fix distributor on Rx core > >> > >> Andy Pei (1): > >> vdpa/ifc/base: fix null pointer dereference > >> > >> Ankur Dwivedi (1): > >> common/cpt: fix build with GCC 12 > >> > >> Chengwen Feng (4): > >> ethdev: clarify null location case in xstats get > >> net/hns3: fix xstats get return if xstats is null > >> net/ipn3ke: fix xstats get return if xstats is null > >> net/mvpp2: fix xstats get return if xstats is null > >> > >> Ciara Power (6): > >> test/crypto: fix null check for ZUC authentication > >> test/crypto: fix cipher offset for ZUC > >> test/crypto: fix authentication IV for ZUC SGL > >> test/crypto: fix ZUC vector IV format > >> test/crypto: fix SNOW3G vector IV format > >> doc: fix grammar and formatting in compressdev guide > >> > >> Damodharam Ammepalli (2): > >> net/bnxt: allow Tx only or Rx only > >> net/bnxt: cleanup MTU setting > >> > >> Dariusz Sosnowski (1): > >> net/mlx5: fix GTP handling in header modify action > >> > >> David Marchand (11): > >> net/nfp: remove unneeded header inclusion > >> devtools: fix null test for NUMA systems > >> app/testpmd: remove useless pointer checks > >> net/bnxt: fix compatibility with some old firmwares > >> net/ice: fix build with GCC 12 > >> vdpa/ifc: fix build with GCC 12 > >> eal/x86: drop export of internal alignment macro > >> test/ipsec: fix build with GCC 12 > >> vhost/crypto: fix build with GCC 12 > >> vhost/crypto: fix descriptor processing > >> vhost: add some trailing newline in log messages > >> > >> Deepak Khandelwal (1): > >> mem: skip attaching external memory in secondary process > >> > >> Dmitry Kozlyuk (2): > >> net/mlx5: fix Tx when inlining is impossible > >> ethdev: prohibit polling stopped queue > >> > >> Fidaullah Noonari (1): > >> malloc: fix allocation of almost hugepage size > >> > >> Gagandeep Singh (5): > >> crypto/dpaa_sec: fix digest size > >>
