Re: [PATCH 1/2] net/txgbe: fix customized devices probe failure
On 6/29/2022 4:34 AM, Jiawen Wu wrote:
The devices with OEM subsystem vendor ID failed to be initialized,
because flash was read before memory address was set.
Fixes: 138d869e41c0 ("net/txgbe: support OEM subsystem vendor ID")
Signed-off-by: Jiawen Wu
Series applied to dpdk-next-net/main, thanks.
RE: release candidate 22.07-rc2
> -Original Message- > From: Thomas Monjalon > Sent: Monday, June 27, 2022 10:15 AM > To: annou...@dpdk.org > Subject: release candidate 22.07-rc2 > > A new DPDK release candidate is ready for testing: > https://git.dpdk.org/dpdk/tag/?id=v22.07-rc2 > > There are 317 new patches in this snapshot. > > Release notes: > https://doc.dpdk.org/guides/rel_notes/release_22_07.html > > There were a lot of updates in drivers. > The driver features should be frozen now. > > Please test and report issues on bugs.dpdk.org. > Do not forget to review examples and documentation updates. > > DPDK 22.07-rc3 is expected in one week (targetting end of June). > > Thank you everyone > Update the test status for Intel part. Till now dpdk22.07-rc2 test execution rate is 85%. Till now, two P2-high issues are found. Intel Dev have provided fix and test passed, other common issues need to be confirmed and fixed by Intel Dev. # Basic Intel(R) NIC testing * Build or compile: *Build: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu20.04, Ubuntu22.04, Fedora36, RHEL8.6 etc. - All test passed. * PF/VF(i40e, ixgbe): test scenarios including PF/VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - Execution rate is 85%. Find 3 new issues, two have fix, other is under investigating. * PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - Execution rate is 100%. - Find 1 new issue about "ice_iavf_fdir: the ipv4/6 gtpu_eh rule not take effect", - bad commit id is commit 0718b7716c9516fca458695f7a0195b1f45d4778 (HEAD, refs/bisect/bad) Author: Gregory Etelson Date: Thu Jun 16 21:01:03 2022 +0300 net: fix GTP PSC headers * 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 100%, all passed. No big performance drop. * Power and IPsec: * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc. - All test passed. * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - Execution rate is 20%. Known issue: https://bugs.dpdk.org/show_bug.cgi?id=1034, V2 patch is under verified. # 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. - Execution rate is 90%. Find 2 new issue. Intel dev is under investigating. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - Execution rate is 90%. Find 1 new issues. Intel dev is under investigating. *Performance test: test scenarios including Throughput Performance /Cryptodev Latency, etc. - Execution rate is 90%. No new issue is found. Best regards, Yu Jiang
[Bug 1044] [dpdk-22.07] ice_iavf_fdir: the ipv4/6 gtpu_eh rule not take effect
https://bugs.dpdk.org/show_bug.cgi?id=1044
Bug ID: 1044
Summary: [dpdk-22.07] ice_iavf_fdir: the ipv4/6 gtpu_eh rule
not take effect
Product: DPDK
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: zhiminx.hu...@intel.com
Target Milestone: ---
DPDK version:
22.07-rc2:7cac53f205ebd04d8ebd3ee6a9dd84f698d4ada3
OS:
4.18.0-348.el8.x86_64/redhat8.5
Compiler:
gcc version 8.5.0 20210514 (Red Hat 8.5.0-4)
Hardware platform:
Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz
NIC hardware:
Intel Corporation Ethernet Controller E810-C for QSFP [8086:1592]
NIC firmware:
driver: 1.9.3_dirty
firmware-version: 4.00 0x80011845 1.3236.0
ddp: ICE COMMS Package version 1.3.37.0
Reproduced Step:
1.
echo 1 > /sys/bus/pci/devices/\:ca\:00.0/sriov_numvfs
2.
./usertools/dpdk-devbind.py -b vfio-pci :ca:01.0
3.
ip link set ens25f0 vf 0 mac 00:11:22:33:44:55
4.
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0xf -n 4 -- -i --rxq=16
--txq=16
5.
set fwd rxonly
set verbose 1
start
flow create 0 ingress pattern eth / ipv4 / udp / gtpu teid is 0x12345678 /
gtp_psc qfi is 0x34 / end actions queue index 1 / end
6.
Ether(src="a4:bf:01:51:27:ca", dst="00:11:22:33:44:55")/IP(src="192.168.0.20",
dst="192.168.0.21")/UDP(dport=2152)/GTP_U_Header(gtp_type=255,teid=0x12345678)/GTPPDUSessionContainer(type=1,P=1,QFI=0x34)/IP()/Raw("x"*20)
output:
testpmd> port 0/queue 10: received 1 packets
src=A4:BF:01:51:27:CA - dst=00:11:22:33:44:55 - type=0x0800 - length=102 -
nb_segs=1 - RSS hash=0x43723baa - RSS queue=0xa - hw ptype: L2_ETHER
L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_NONFRAG -
sw ptype: L2_ETHER L3_IPV4 L4_UDP - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN
packet: packet type =32913, Destination UDP port =2152, VNI = 1193046,
last_rsvd = 120 - Receive queue=0xa
ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN
expect output:
testpmd> port 0/queue 1: received 1 packets
src=A4:BF:01:51:27:CA - dst=00:11:22:33:44:55 - type=0x0800 - length=102 -
nb_segs=1 - RSS hash=0x9ce7492b - RSS queue=0x1 - hw ptype: L2_ETHER
L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_NONFRAG -
sw ptype: L2_ETHER L3_IPV4 L4_UDP - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN
packet: packet type =32913, Destination UDP port =2152, VNI = 1193046,
last_rsvd = 120 - Receive queue=0x1
ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN
Regression
Is this issue a regression: (Y/N) Y
commit 0718b7716c9516fca458695f7a0195b1f45d4778 (HEAD, refs/bisect/bad)
Author: Gregory Etelson
Date: Thu Jun 16 21:01:03 2022 +0300
net: fix GTP PSC headers
Fix bitmap fields order in little endian section of GTP PSC headers.
Fixes: e8ca1479cdc4 ("net: add extension header for GTP PSC")
Cc: sta...@dpdk.org
Signed-off-by: Gregory Etelson
Reviewed-by: Viacheslav Ovsiienko
Acked-by: Aman Singh
Reviewed-by: Andrew Rybchenko
--
You are receiving this mail because:
You are the assignee for the bug.
[PATCH] raw/ntb: add PPD status check for SPR
Add PPD (PCIe Port Definition) status check for SPR (Sapphire Rapids).
Note that NTB on SPR has the same device id with that on ICX, while
the field offsets of PPD Control Register are different. Here, we use
the PCI device revision id to distinguish the HW platform (ICX/SPR)
and check the Port Config Status and Port Definition accordingly.
+---+++
| Fields | Bit Range (on ICX) | Bit Range (on SPR) |
+---+++
| Port Configuration Status | 12 | 14 |
| Port Definition | 9:8| 10:8 |
+---+++
Signed-off-by: Junfeng Guo
---
drivers/raw/ntb/ntb.h | 1 +
drivers/raw/ntb/ntb_hw_intel.c | 60 ++
drivers/raw/ntb/ntb_hw_intel.h | 13
3 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/raw/ntb/ntb.h b/drivers/raw/ntb/ntb.h
index c9ff33aa59..a30a6b60c9 100644
--- a/drivers/raw/ntb/ntb.h
+++ b/drivers/raw/ntb/ntb.h
@@ -19,6 +19,7 @@ extern int ntb_logtype;
/* Device IDs */
#define NTB_INTEL_DEV_ID_B2B_SKX0x201C
#define NTB_INTEL_DEV_ID_B2B_ICX0x347E
+#define NTB_INTEL_DEV_ID_B2B_SPR0x347E
/* Reserved to app to use. */
#define NTB_SPAD_USER "spad_user_"
diff --git a/drivers/raw/ntb/ntb_hw_intel.c b/drivers/raw/ntb/ntb_hw_intel.c
index a742e8fbb9..b40142d148 100644
--- a/drivers/raw/ntb/ntb_hw_intel.c
+++ b/drivers/raw/ntb/ntb_hw_intel.c
@@ -37,7 +37,8 @@ is_gen3_ntb(const struct ntb_hw *hw)
static inline int
is_gen4_ntb(const struct ntb_hw *hw)
{
- if (hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_ICX)
+ if (hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_ICX ||
+ hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_SPR)
return 1;
return 0;
@@ -87,12 +88,8 @@ intel_ntb3_check_ppd(struct ntb_hw *hw)
}
static int
-intel_ntb4_check_ppd(struct ntb_hw *hw)
+intel_ntb4_check_ppd_for_ICX(struct ntb_hw *hw, uint32_t reg_val)
{
- uint32_t reg_val;
-
- reg_val = rte_read32(hw->hw_addr + XEON_GEN4_PPD1_OFFSET);
-
/* Check connection topo type. Only support B2B. */
switch (reg_val & XEON_GEN4_PPD_CONN_MASK) {
case XEON_GEN4_PPD_CONN_B2B:
@@ -115,6 +112,57 @@ intel_ntb4_check_ppd(struct ntb_hw *hw)
return 0;
}
+static int
+intel_ntb4_check_ppd_for_SPR(struct ntb_hw *hw, uint32_t reg_val)
+{
+ /* Check connection topo type. Only support B2B. */
+ switch (reg_val & XEON_SPR_PPD_CONN_MASK) {
+ case XEON_SPR_PPD_CONN_B2B:
+ NTB_LOG(INFO, "Topo B2B (back to back) is using.");
+ break;
+ default:
+ NTB_LOG(ERR, "Not supported conn topo. Please use B2B.");
+ return -EINVAL;
+ }
+
+ /* Check device type. */
+ if (reg_val & XEON_SPR_PPD_DEV_DSD) {
+ NTB_LOG(INFO, "DSD, Downstream Device.");
+ hw->topo = NTB_TOPO_B2B_DSD;
+ } else {
+ NTB_LOG(INFO, "USD, Upstream device.");
+ hw->topo = NTB_TOPO_B2B_USD;
+ }
+
+ return 0;
+}
+
+static int
+intel_ntb4_check_ppd(struct ntb_hw *hw)
+{
+ uint8_t revision_id;
+ uint32_t reg_val;
+ int ret;
+
+ ret = rte_pci_read_config(hw->pci_dev, &revision_id,
+ NTB_PCI_DEV_REVISION_ID_LEN,
+ NTB_PCI_DEV_REVISION_ID_REG);
+ if (ret != NTB_PCI_DEV_REVISION_ID_LEN) {
+ NTB_LOG(ERR, "Cannot get NTB PCI Device Revision ID.");
+ return -EIO;
+ }
+
+ reg_val = rte_read32(hw->hw_addr + XEON_GEN4_PPD1_OFFSET);
+
+ /* Distinguish HW platform (ICX/SPR) via PCI Revision ID */
+ if (revision_id > NTB_PCI_DEV_REVISION_ICX_MAX)
+ ret = intel_ntb4_check_ppd_for_SPR(hw, reg_val);
+ else if (revision_id > NTB_PCI_DEV_REVISION_ICX_MIN)
+ ret = intel_ntb4_check_ppd_for_ICX(hw, reg_val);
+
+ return ret;
+}
+
static int
intel_ntb_dev_init(const struct rte_rawdev *dev)
{
diff --git a/drivers/raw/ntb/ntb_hw_intel.h b/drivers/raw/ntb/ntb_hw_intel.h
index c61a2a8a62..9587104f80 100644
--- a/drivers/raw/ntb/ntb_hw_intel.h
+++ b/drivers/raw/ntb/ntb_hw_intel.h
@@ -5,6 +5,13 @@
#ifndef _NTB_HW_INTEL_H_
#define _NTB_HW_INTEL_H_
+/* Supported PCI device revision ID range for ICX */
+#define NTB_PCI_DEV_REVISION_ICX_MIN 0x02
+#define NTB_PCI_DEV_REVISION_ICX_MAX 0x0F
+
+#define NTB_PCI_DEV_REVISION_ID_REG0x08
+#define NTB_PCI_DEV_REVISION_ID_LEN1
+
/* Ntb control and link status */
#define NTB_CTL_CFG_LOCK 1
#define NTB_CTL_DISABLE2
@@ -90,6 +97,12 @@
#define XEON_GEN4_SLOTSTS 0xb05a
#define XEON_GEN4_SLOTSTS_DLLSCS 0x100
+#d
RE: Service core statistics MT safety
Hey All, (I've been away on Holidays a few days, just catching up!) > -Original Message- > From: Honnappa Nagarahalli > Sent: Wednesday, June 29, 2022 9:07 PM > To: Mattias Rönnblom ; mattias.ronnblom > ; Morten Brørup > ; dev@dpdk.org > Cc: Van Haaren, Harry ; nd ; nd > > Subject: RE: Service core statistics MT safety > > > > At the time of the read operation (in the global counter solution), there > > may well > > be cycles consumed or calls having been made, but not yet posted. The window > > between call having been made, and global counter having been incremented > > (and thus made globally visible) is small, but non-zero. > Agree. The read value is the atomic state of the system at a given instance > (when the > read was executed), though that instance happened few cycles back. > (Just to be clear, I am fine with per-core counters) Option 1: "Per core counters" > Agree we need atomic operations. I am not sure if __atomic_fetch_add or > __atomic_store_n would have a large difference. __atomic_fetch_add would > result > in less number of instructions. I am fine with either. Option 2: "Use atomics for counter increments". > > >> I was fortunate to get some data from a real-world application, and > > >> enabling service core stats resulted in a 7% degradation of overall > > >> system capacity. I'm guessing atomic instructions would not make things > > better. Agree, performance of atomics is likely to reduce performance.. but correctness is worth more than performance. In my mind, any LTS/backports get the simplest/highest-confidence bugfix: using atomics. The atomics are behind the "service stats" feature enable, so impact is only when those are enabled. If there is still a performance hit, and there are *no* MT services registered, we could check a static-global flag, and if there are no MT services use the normal adds. Thoughts on such a solution to reduce atomic perf impact only to apps with MT-services? The code changes themselves are OK.. I can send a patch with fix if there's agreement on the approach? diff --git a/lib/eal/common/rte_service.c b/lib/eal/common/rte_service.c index ef31b1f63c..a07c8fc2d7 100644 --- a/lib/eal/common/rte_service.c +++ b/lib/eal/common/rte_service.c @@ -363,9 +363,9 @@ service_runner_do_callback(struct rte_service_spec_impl *s, uint64_t start = rte_rdtsc(); s->spec.callback(userdata); uint64_t end = rte_rdtsc(); - s->cycles_spent += end - start; + __atomic_fetch_add(&s->cycles_spent, (end-start), __ATOMIC_RELAXED); + __atomic_fetch_add(&s->calls, 1, __ATOMIC_RELAXED); cs->calls_per_service[service_idx]++; - s->calls++; } else s->spec.callback(userdata); }
[PATCH v2] raw/ntb: add PPD status check for SPR
Add PPD (PCIe Port Definition) status check for SPR (Sapphire Rapids).
Note that NTB on SPR has the same device id with that on ICX, while
the field offsets of PPD Control Register are different. Here, we use
the PCI device revision id to distinguish the HW platform (ICX/SPR)
and check the Port Config Status and Port Definition accordingly.
+---+++
| Fields | Bit Range (on ICX) | Bit Range (on SPR) |
+---+++
| Port Configuration Status | 12 | 14 |
| Port Definition | 9:8| 10:8 |
+---+++
v2:
fix revision id value check logic.
Signed-off-by: Junfeng Guo
---
drivers/raw/ntb/ntb.h | 1 +
drivers/raw/ntb/ntb_hw_intel.c | 64 ++
drivers/raw/ntb/ntb_hw_intel.h | 13 +++
3 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/raw/ntb/ntb.h b/drivers/raw/ntb/ntb.h
index c9ff33aa59..a30a6b60c9 100644
--- a/drivers/raw/ntb/ntb.h
+++ b/drivers/raw/ntb/ntb.h
@@ -19,6 +19,7 @@ extern int ntb_logtype;
/* Device IDs */
#define NTB_INTEL_DEV_ID_B2B_SKX0x201C
#define NTB_INTEL_DEV_ID_B2B_ICX0x347E
+#define NTB_INTEL_DEV_ID_B2B_SPR0x347E
/* Reserved to app to use. */
#define NTB_SPAD_USER "spad_user_"
diff --git a/drivers/raw/ntb/ntb_hw_intel.c b/drivers/raw/ntb/ntb_hw_intel.c
index a742e8fbb9..20cdb761a3 100644
--- a/drivers/raw/ntb/ntb_hw_intel.c
+++ b/drivers/raw/ntb/ntb_hw_intel.c
@@ -37,7 +37,8 @@ is_gen3_ntb(const struct ntb_hw *hw)
static inline int
is_gen4_ntb(const struct ntb_hw *hw)
{
- if (hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_ICX)
+ if (hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_ICX ||
+ hw->pci_dev->id.device_id == NTB_INTEL_DEV_ID_B2B_SPR)
return 1;
return 0;
@@ -87,12 +88,8 @@ intel_ntb3_check_ppd(struct ntb_hw *hw)
}
static int
-intel_ntb4_check_ppd(struct ntb_hw *hw)
+intel_ntb4_check_ppd_for_ICX(struct ntb_hw *hw, uint32_t reg_val)
{
- uint32_t reg_val;
-
- reg_val = rte_read32(hw->hw_addr + XEON_GEN4_PPD1_OFFSET);
-
/* Check connection topo type. Only support B2B. */
switch (reg_val & XEON_GEN4_PPD_CONN_MASK) {
case XEON_GEN4_PPD_CONN_B2B:
@@ -115,6 +112,61 @@ intel_ntb4_check_ppd(struct ntb_hw *hw)
return 0;
}
+static int
+intel_ntb4_check_ppd_for_SPR(struct ntb_hw *hw, uint32_t reg_val)
+{
+ /* Check connection topo type. Only support B2B. */
+ switch (reg_val & XEON_SPR_PPD_CONN_MASK) {
+ case XEON_SPR_PPD_CONN_B2B:
+ NTB_LOG(INFO, "Topo B2B (back to back) is using.");
+ break;
+ default:
+ NTB_LOG(ERR, "Not supported conn topo. Please use B2B.");
+ return -EINVAL;
+ }
+
+ /* Check device type. */
+ if (reg_val & XEON_SPR_PPD_DEV_DSD) {
+ NTB_LOG(INFO, "DSD, Downstream Device.");
+ hw->topo = NTB_TOPO_B2B_DSD;
+ } else {
+ NTB_LOG(INFO, "USD, Upstream device.");
+ hw->topo = NTB_TOPO_B2B_USD;
+ }
+
+ return 0;
+}
+
+static int
+intel_ntb4_check_ppd(struct ntb_hw *hw)
+{
+ uint8_t revision_id;
+ uint32_t reg_val;
+ int ret;
+
+ ret = rte_pci_read_config(hw->pci_dev, &revision_id,
+ NTB_PCI_DEV_REVISION_ID_LEN,
+ NTB_PCI_DEV_REVISION_ID_REG);
+ if (ret != NTB_PCI_DEV_REVISION_ID_LEN) {
+ NTB_LOG(ERR, "Cannot get NTB PCI Device Revision ID.");
+ return -EIO;
+ }
+
+ reg_val = rte_read32(hw->hw_addr + XEON_GEN4_PPD1_OFFSET);
+
+ /* Distinguish HW platform (ICX/SPR) via PCI Revision ID */
+ if (revision_id > NTB_PCI_DEV_REVISION_ICX_MAX)
+ ret = intel_ntb4_check_ppd_for_SPR(hw, reg_val);
+ else if (revision_id >= NTB_PCI_DEV_REVISION_ICX_MIN)
+ ret = intel_ntb4_check_ppd_for_ICX(hw, reg_val);
+ else {
+ NTB_LOG(ERR, "Invalid NTB PCI Device Revision ID.");
+ return -EIO;
+ }
+
+ return ret;
+}
+
static int
intel_ntb_dev_init(const struct rte_rawdev *dev)
{
diff --git a/drivers/raw/ntb/ntb_hw_intel.h b/drivers/raw/ntb/ntb_hw_intel.h
index c61a2a8a62..9587104f80 100644
--- a/drivers/raw/ntb/ntb_hw_intel.h
+++ b/drivers/raw/ntb/ntb_hw_intel.h
@@ -5,6 +5,13 @@
#ifndef _NTB_HW_INTEL_H_
#define _NTB_HW_INTEL_H_
+/* Supported PCI device revision ID range for ICX */
+#define NTB_PCI_DEV_REVISION_ICX_MIN 0x02
+#define NTB_PCI_DEV_REVISION_ICX_MAX 0x0F
+
+#define NTB_PCI_DEV_REVISION_ID_REG0x08
+#define NTB_PCI_DEV_REVISION_ID_LEN1
+
/* Ntb control and link status */
#define NTB_CTL_CFG_LOCK 1
#de
[PATCH] net/cnxk: fix segmentation fault in telemetry
It gives segmentation fault when no parameter is passed for command '/cnxk/ipsec/info' in usertools/telemetry app as NULL is being passed as parameter to strtoul(). Now this function returns -1 before strtoul() if no parameter is passed. Signed-off-by: Usman Tanveer --- drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c b/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c index dfad5af8fe..088798d70a 100644 --- a/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c +++ b/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c @@ -229,6 +229,9 @@ ethdev_sec_tel_handle_info(const char *cmd __rte_unused, const char *params, uint32_t i; int ret; + if (params == NULL || strlen(params) == 0 || !isdigit(*params)) + return -1; + port_id = strtoul(params, &end_p, 0); if (errno != 0) return -EINVAL; -- 2.25.1
Re: [PATCH] net/cnxk: fix segmentation fault in telemetry
On Thu, Jun 30, 2022 at 11:24 AM Usman Tanveer wrote: > > It gives segmentation fault when no parameter is passed for > command '/cnxk/ipsec/info' in usertools/telemetry app as NULL > is being passed as parameter to strtoul(). Now this function > returns -1 before strtoul() if no parameter is passed. > > Signed-off-by: Usman Tanveer > --- > drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c > b/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c > index dfad5af8fe..088798d70a 100644 > --- a/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c > +++ b/drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c > @@ -229,6 +229,9 @@ ethdev_sec_tel_handle_info(const char *cmd __rte_unused, > const char *params, > uint32_t i; > int ret; > > + if (params == NULL || strlen(params) == 0 || !isdigit(*params)) > + return -1; > + > port_id = strtoul(params, &end_p, 0); > if (errno != 0) > return -EINVAL; Duplicate of already merged: https://git.dpdk.org/dpdk/commit/?id=a31c9f970dfd -- David Marchand
[PATCH] doc: announce some raw/ifpga API removal
rte_pmd_ifpga_get_pci_bus() documentation is vague and it is unclear what could be done with it. On the other hand, EAL provides a standard API to retrieve a bus object by name. Announce removal of this driver specific API for v22.11. Signed-off-by: David Marchand --- A RFC series of the intended changes is available at: https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both --- doc/guides/rel_notes/deprecation.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..64d649777a 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -119,6 +119,8 @@ Deprecation Notices * metrics: The function ``rte_metrics_init`` will have a non-void return in order to notify errors instead of calling ``rte_exit``. +* raw/ifgpa: The ``rte_pmd_ifpga_get_pci_bus`` will be removed in 22.11. + * raw/ioat: The ``ioat`` rawdev driver has been deprecated, since it's functionality is provided through the new ``dmadev`` infrastructure. To continue to use hardware previously supported by the ``ioat`` rawdev driver, -- 2.36.1
[PATCH] doc: announce marking bus object as internal
rte_bus is unnecessarily exposed in the public API/ABI. Besides, we had cases where extending rte_bus was necessary. Announce that rte_bus will be made opaque in the public API and mark associated API as internal. Signed-off-by: David Marchand --- A RFC series of the intended changes is available at: https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 64d649777a..a9fd6676be 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -32,6 +32,12 @@ Deprecation Notices ``__atomic_thread_fence`` must be used for patches that need to be merged in 20.08 onwards. This change will not introduce any performance degradation. +* bus: The ``rte_bus`` object will be made opaque in DPDK 22.11. + The goal is to remove it from the public ABI and make this object extendable. + As a side effect, registering a bus will be marked as an internal API: + external users may still register their bus using a new driver header (see + ``enable_driver_sdk`` meson option). + * mempool: Helper macro ``MEMPOOL_HEADER_SIZE()`` is deprecated and will be removed in DPDK 22.11. The replacement macro ``RTE_MEMPOOL_HEADER_SIZE()`` is internal only. -- 2.36.1
Re: [PATCH] doc: announce marking bus object as internal
On Thu, Jun 30, 2022 at 11:41:53AM +0200, David Marchand wrote: > rte_bus is unnecessarily exposed in the public API/ABI. > Besides, we had cases where extending rte_bus was necessary. > Announce that rte_bus will be made opaque in the public API and mark > associated API as internal. > > Signed-off-by: David Marchand > --- > A RFC series of the intended changes is available at: > https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both > > --- Acked-by: Bruce Richardson
Re: [PATCH v2] vhost: fix unchecked return value
On 6/29/22 11:07, Jiayu Hu wrote:
This patch checks the return value of rte_dma_info_get()
called in rte_vhost_async_dma_configure().
Coverity issue: 379066
Fixes: 53d3f4778c1d ("vhost: integrate dmadev in asynchronous data-path")
Cc: sta...@dpdk.org
Signed-off-by: Jiayu Hu
Reviewed-by: Chenbo Xia
---
v2:
- add cc stable tag
---
lib/vhost/vhost.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
index b14521e4d1..70c04c036e 100644
--- a/lib/vhost/vhost.c
+++ b/lib/vhost/vhost.c
@@ -1868,7 +1868,11 @@ rte_vhost_async_dma_configure(int16_t dma_id, uint16_t
vchan_id)
return -1;
}
- rte_dma_info_get(dma_id, &info);
+ if (rte_dma_info_get(dma_id, &info) != 0) {
+ VHOST_LOG_CONFIG(ERR, "Fail to get DMA %d information.\n",
dma_id);
+ return -1;
+ }
+
if (vchan_id >= info.max_vchans) {
VHOST_LOG_CONFIG(ERR, "Invalid DMA %d vChannel %u.\n", dma_id,
vchan_id);
return -1;
The patch itself looks good, but rte_vhost_async_dma_configure() should
be protected by a lock, as concurrent calls of this function would lead
to undefined behavior.
Can you cook something?
David, is that the issue you mentioned me this week or was it another
one?
Thanks,
Maxime
[PATCH] examples/ipsec-secgw: fix fallback session create
Fix fallback session create for inline sessions.
Fixes: a8ade12123c3 ("examples/ipsec-secgw: create lookaside sessions at init")
Cc: vfia...@marvell.com
Signed-off-by: Radu Nicolau
---
examples/ipsec-secgw/sa.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 5d9cec97db..f62b88ca23 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1522,9 +1522,11 @@ fill_ipsec_session(struct rte_ipsec_session *ss, struct
rte_ipsec_sa *sa)
ss->sa = sa;
- rc = rte_ipsec_session_prepare(ss);
- if (rc != 0)
- memset(ss, 0, sizeof(*ss));
+ if (ss->security.ses != NULL) {
+ rc = rte_ipsec_session_prepare(ss);
+ if (rc != 0)
+ memset(ss, 0, sizeof(*ss));
+ }
return rc;
}
--
2.25.1
[dpdk-dev v1] crypto/openssl: EVP_PKEY routine update in rsa op
EVP_PKEY function need to be called twice for rsa sign and verify
operations. This patch also remove the OPENSSL_API_COMPAT as all
the deprecated APIs are avoid if 3.0 lib is present.
Fixes: d7bd42f6db19 ("crypto/openssl: update RSA routine with 3.0 EVP API")
Cc: kai...@intel.com
Signed-off-by: Kai Ji
---
drivers/crypto/openssl/rte_openssl_pmd.c | 32 ++--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 --
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
b/drivers/crypto/openssl/rte_openssl_pmd.c
index 84bca86894..e01dacc98d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1788,7 +1788,7 @@ process_openssl_dsa_sign_op_evp(struct rte_crypto_op *cop,
if (key_ctx == NULL
|| EVP_PKEY_fromdata_init(key_ctx) <= 0
|| EVP_PKEY_fromdata(key_ctx, &pkey,
- EVP_PKEY_PUBLIC_KEY, params) <=
0)
+ EVP_PKEY_KEYPAIR, params) <= 0)
goto err_dsa_sign;
dsa_ctx = EVP_PKEY_CTX_new(pkey, NULL);
@@ -2478,6 +2478,14 @@ process_openssl_rsa_op_evp(struct rte_crypto_op *cop,
if (EVP_PKEY_CTX_set_rsa_padding(rsa_ctx, pad) <= 0)
goto err_rsa;
+ if (EVP_PKEY_sign(rsa_ctx, NULL, &outlen,
+ op->rsa.message.data,
+ op->rsa.message.length) <= 0)
+ goto err_rsa;
+
+ if (outlen <= 0)
+ goto err_rsa;
+
if (EVP_PKEY_sign(rsa_ctx, op->rsa.sign.data, &outlen,
op->rsa.message.data,
op->rsa.message.length) <= 0)
@@ -2486,19 +2494,23 @@ process_openssl_rsa_op_evp(struct rte_crypto_op *cop,
break;
case RTE_CRYPTO_ASYM_OP_VERIFY:
- tmp = rte_malloc(NULL, op->rsa.sign.length, 0);
- if (tmp == NULL) {
- OPENSSL_LOG(ERR, "Memory allocation failed");
+ if (EVP_PKEY_verify_recover_init(rsa_ctx) <= 0)
goto err_rsa;
- }
- if (EVP_PKEY_verify_recover_init(rsa_ctx) <= 0) {
- rte_free(tmp);
+ if (EVP_PKEY_CTX_set_rsa_padding(rsa_ctx, pad) <= 0)
goto err_rsa;
- }
- if (EVP_PKEY_CTX_set_rsa_padding(rsa_ctx, pad) <= 0) {
- rte_free(tmp);
+ if (EVP_PKEY_verify_recover(rsa_ctx, NULL, &outlen,
+ op->rsa.sign.data,
+ op->rsa.sign.length) <= 0)
+ goto err_rsa;
+
+ if ((outlen <= 0) || (outlen != op->rsa.sign.length))
+ goto err_rsa;
+
+ tmp = OPENSSL_malloc(outlen);
+ if (tmp == NULL) {
+ OPENSSL_LOG(ERR, "Memory allocation failed");
goto err_rsa;
}
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 8d1f8e834a..3e24ef94f7 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -2,8 +2,6 @@
* Copyright(c) 2016-2017 Intel Corporation
*/
-#define OPENSSL_API_COMPAT 0x1010L
-
#include
#include
--
2.17.1
RE: [PATCH v4] lib/eal: fix segfaults due to thread exit order
Hi Harman, Bruce Could you please help to review this patch, thank you so much! Best regards Zhichao > -Original Message- > From: Zeng, ZhichaoX > Sent: Wednesday, June 15, 2022 2:02 PM > To: dev@dpdk.org > Cc: sta...@dpdk.org; Yang, Qiming ; > david.march...@redhat.com; step...@networkplumber.org; > m...@smartsharesystems.com; Zeng, ZhichaoX ; > Richardson, Bruce > ; Harman Kalra > > Subject: [PATCH v4] lib/eal: fix segfaults due to thread exit order > > From: Zhichao Zeng > > The eal-intr-thread is not closed before memory cleanup in the process of > exiting. There is a small probability that when the eal-intr-thread is about > to use some pointers, the memory were just cleaned, which cause the > segment > fault error caught by ASan. > > This patch close the eal-intr-thread before memory cleanup when exiting to > avoid segment fault. And add some atomic operations to avoid executing > rte_eal_cleanup in the child process spawned by fork() in some test > cases, > e.g. debug_autotest of dpdk-test. > > Cc: sta...@dpdk.org > > --- > v2: > add the same API for FreeBSD > --- > v3: > fix rte_eal_cleanup crash in debug_autotest > --- > v4: > shorten the prompt message and optimize the commit log > > Suggested-by: David Marchand > Signed-off-by: Zhichao Zeng
DPDK Release Status Meeting 2022-06-30
Release status meeting minutes 2022-06-30 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * ARM * Debian/Microsoft * Intel * Marvell * Nvidia * Red Hat * Xilinx/AMD Release Dates - The following are the proposed current dates for 22.07: * V1 deadline: 10 April 2022 * RC1: 8 June 2022 * RC2: 23 June 2022 * RC3: 4 July 2022 - was 30 June 2022 * RC4: 8 July 2022 * Release: 13 July 2022 Updated dates are posted shortly after they are changed at: http://core.dpdk.org/roadmap/#dates Here are some provisional dates for 22.11: * V1 deadline: 14 August 2022 * RC1: 3 October 2022 * RC2: 23 June 2022 * RC3: 31 October 2022 * Release: 16 November 2022 Subtrees * next-net * RC2 released * Prepping for RC3 * Patch for MTU in PCAP Driver - needs reviews * next-net-intel * Get update 4 patches waiting for upstream * Looking at fix for GCC12 issue in ice driver * next-net-mlx * 2 small patches for private testpmd * next-net-brcm * No update * next-net-mrvl * Mainly complete after RC2 * next-eventdev * Some fixes from Intel * next-virtio * Some reviews to do * Prepping a PR for RC3 around docs and fixes * next-crypto * Most patches merged in RC2 * Looking at docs and fixes * main * Merged last fixes for GCC 12 * Still some issues with cross compilation * Merged NULL pointer/checks patches * Series for memory leaks needs some rework * Sent first RFC on rte_bus * Please send **and** review deprecation notices: https://patchwork.dpdk.org/project/dpdk/list/?series=&q=deprecat Other - * DPDK Summit: https://events.linuxfoundation.org/dpdk-userspace-summit/ * Call for papers: https://linuxfoundation.smapply.io/prog/dpdk_userspace_summit_2022/ Dates to Remember: CFP Opens: Monday, June 27 at 12:00 am PDT CFP Closes: Friday, July 22 at 11:59 PM PDT Speaker Notifications: August 1 Schedule Announcement: Week of August 1 Presentation Slide Due Date: Tuesday, August 30 Event Dates: Tuesday, September 6 - Thursday, September 8, 2022 LTS --- * 21.11.2 * Back porting in progress * 21.11.1 released April 26th * 20.11.6 * Backporting waiting for RC2 * 20.11.5 released April 4th * 19.11.13 * Backporting waiting for RC2 * 19.11.12 released April 7th * 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.
Re: DPDK Release Status Meeting 2022-06-30
On Thu, Jun 30, 2022 at 12:47 PM Mcnamara, John wrote: > * Please send **and** review deprecation notices: > https://patchwork.dpdk.org/project/dpdk/list/?series=&q=deprecat And more here: https://patchwork.dpdk.org/project/dpdk/list/?series=&q=announce -- David Marchand
[PATCH v4] net/igc: add support for secondary processes
From: Zhichao Zeng
The RX function was not specified in the secondary process, causing the
secondary process to segfault in a multi-process environment.
This patch specify RX/TX functions in "dev_init" to support secondary
processes.
Fixes: 66fde1b943eb ("net/igc: add skeleton")
Cc: alvinx.zh...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Zhichao Zeng
---
v2:
remove unnecessary parameters, move declaration to relevant header file
---
v3:
remove redundant code, optimize commit log
---
v4:
rework patch
---
drivers/net/igc/igc_ethdev.c | 9 -
drivers/net/igc/igc_txrx.c | 8
drivers/net/igc/igc_txrx.h | 6 ++
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/igc/igc_ethdev.c b/drivers/net/igc/igc_ethdev.c
index b9933b395d..7f221a5d34 100644
--- a/drivers/net/igc/igc_ethdev.c
+++ b/drivers/net/igc/igc_ethdev.c
@@ -1240,8 +1240,15 @@ eth_igc_dev_init(struct rte_eth_dev *dev)
* has already done this work. Only check we don't need a different
* RX function.
*/
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ dev->rx_pkt_burst = igc_recv_pkts;
+ if (dev->data->scattered_rx)
+ dev->rx_pkt_burst = igc_recv_scattered_pkts;
+
+ dev->tx_pkt_burst = igc_xmit_pkts;
+ dev->tx_pkt_prepare = eth_igc_prep_pkts;
return 0;
+ }
rte_eth_copy_pci_info(dev, pci_dev);
dev->data->dev_flags |= RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
diff --git a/drivers/net/igc/igc_txrx.c b/drivers/net/igc/igc_txrx.c
index e48d5df11a..ffd219b0df 100644
--- a/drivers/net/igc/igc_txrx.c
+++ b/drivers/net/igc/igc_txrx.c
@@ -345,7 +345,7 @@ rx_desc_get_pkt_info(struct igc_rx_queue *rxq, struct
rte_mbuf *rxm,
rxm->packet_type = rx_desc_pkt_info_to_pkt_type(pkt_info);
}
-static uint16_t
+uint16_t
igc_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
{
struct igc_rx_queue * const rxq = rx_queue;
@@ -488,7 +488,7 @@ igc_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
return nb_rx;
}
-static uint16_t
+uint16_t
igc_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
{
@@ -1397,7 +1397,7 @@ eth_igc_rx_queue_setup(struct rte_eth_dev *dev,
}
/* prepare packets for transmit */
-static uint16_t
+uint16_t
eth_igc_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
{
@@ -1604,7 +1604,7 @@ tx_desc_cksum_flags_to_olinfo(uint64_t ol_flags)
return tmp;
}
-static uint16_t
+uint16_t
igc_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
struct igc_tx_queue * const txq = tx_queue;
diff --git a/drivers/net/igc/igc_txrx.h b/drivers/net/igc/igc_txrx.h
index 535108a868..02a0a051bb 100644
--- a/drivers/net/igc/igc_txrx.h
+++ b/drivers/net/igc/igc_txrx.h
@@ -49,6 +49,12 @@ void eth_igc_txq_info_get(struct rte_eth_dev *dev, uint16_t
queue_id,
struct rte_eth_txq_info *qinfo);
void eth_igc_vlan_strip_queue_set(struct rte_eth_dev *dev,
uint16_t rx_queue_id, int on);
+uint16_t igc_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t
nb_pkts);
+uint16_t igc_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t
nb_pkts);
+uint16_t eth_igc_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf
**tx_pkts,
+ uint16_t nb_pkts);
+uint16_t igc_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
#ifdef __cplusplus
}
#endif
--
2.25.1
[PATCH v1] examples/fips_validation: fix print for zero length payload
NIST GCM decrypt result vectors expects to have following print
for zero length payload instead of having no print.
"pt" = ""
Fixes: b09aac2d6e2b ("examples/fips_validation: add JSON to GCM test")
Signed-off-by: Archana Muniganti
---
examples/fips_validation/fips_validation_gcm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/examples/fips_validation/fips_validation_gcm.c
b/examples/fips_validation/fips_validation_gcm.c
index 28ef04c817..6b3d158629 100644
--- a/examples/fips_validation/fips_validation_gcm.c
+++ b/examples/fips_validation/fips_validation_gcm.c
@@ -327,6 +327,9 @@ parse_test_gcm_json_writeback(struct fips_val *val)
writeback_hex_str("", info.one_line_text,
&tmp_val);
json_object_set_new(json_info.json_write_case,
PT_JSON_STR,
json_string(info.one_line_text));
+ } else {
+ json_object_set_new(json_info.json_write_case,
PT_JSON_STR,
+ json_string(""));
}
} else {
json_object_set_new(json_info.json_write_case,
"testPassed", json_false());
--
2.25.1
Re: DPDK Release Status Meeting 2022-06-30
On 6/30/2022 11:47 AM, Mcnamara, John wrote: Release status meeting minutes 2022-06-30 = <...> Opens - Last minute opens were: * I am getting ABI check crash, when again v21.11 with abigail 2.0.0, for the file 'librte_common_qat'. Not sure if this is specific to my environment, would be good if someone double checks. * igb_uio build fails with latest kernel, a fix is required.
[PATCH v2] examples/ipsec-secgw: fix fallback session create
Fix fallback session create for inline sessions.
Fixes: a8ade12123c3 ("examples/ipsec-secgw: create lookaside sessions at init")
Cc: vfia...@marvell.com
Signed-off-by: Radu Nicolau
---
v2: create the session rather than just check if it's NULLL
examples/ipsec-secgw/sa.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 5d9cec97db..d081cd0e2c 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1533,7 +1533,8 @@ fill_ipsec_session(struct rte_ipsec_session *ss, struct
rte_ipsec_sa *sa)
* Initialise related rte_ipsec_sa object.
*/
static int
-ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa *sa, uint32_t sa_size)
+ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa *sa, uint32_t sa_size,
+ struct socket_ctx *skt_ctx, struct ipsec_ctx *ips_ctx[])
{
int rc;
struct rte_ipsec_sa_prm prm;
@@ -1572,8 +1573,15 @@ ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa
*sa, uint32_t sa_size)
return rc;
/* init inline fallback processing session */
- if (lsa->fallback_sessions == 1)
- rc = fill_ipsec_session(ipsec_get_fallback_session(lsa), sa);
+ if (lsa->fallback_sessions == 1) {
+ struct rte_ipsec_session *ipfs =
ipsec_get_fallback_session(lsa);
+ if (ipfs->security.ses == NULL) {
+ rc = create_lookaside_session(ips_ctx, skt_ctx, lsa,
ipfs);
+ if (rc != 0)
+ return rc;
+ }
+ rc = fill_ipsec_session(ipfs, sa);
+ }
return rc;
}
@@ -1583,7 +1591,8 @@ ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa
*sa, uint32_t sa_size)
* one per session.
*/
static int
-ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent, int32_t socket)
+ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent, int32_t socket,
+ struct socket_ctx *skt_ctx, struct ipsec_ctx *ips_ctx[])
{
int32_t rc, sz;
uint32_t i, idx;
@@ -1621,7 +1630,7 @@ ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent,
int32_t socket)
sa = (struct rte_ipsec_sa *)((uintptr_t)ctx->satbl + sz * i);
lsa = ctx->sa + idx;
- rc = ipsec_sa_init(lsa, sa, sz);
+ rc = ipsec_sa_init(lsa, sa, sz, skt_ctx, ips_ctx);
}
return rc;
@@ -1700,7 +1709,7 @@ sa_init(struct socket_ctx *ctx, int32_t socket_id,
if (app_sa_prm.enable != 0) {
rc = ipsec_satbl_init(ctx->sa_in, nb_sa_in,
- socket_id);
+ socket_id, ctx, ipsec_ctx);
if (rc != 0)
rte_exit(EXIT_FAILURE,
"failed to init inbound SAs\n");
@@ -1722,7 +1731,7 @@ sa_init(struct socket_ctx *ctx, int32_t socket_id,
if (app_sa_prm.enable != 0) {
rc = ipsec_satbl_init(ctx->sa_out, nb_sa_out,
- socket_id);
+ socket_id, ctx, ipsec_ctx);
if (rc != 0)
rte_exit(EXIT_FAILURE,
"failed to init outbound SAs\n");
--
2.25.1
RE: [PATCH v4] net/igc: add support for secondary processes
> -Original Message-
> From: Zeng, ZhichaoX
> Sent: Thursday, June 30, 2022 7:04 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Yang, Qiming ; Zhang, Qi Z
> ; Zeng, ZhichaoX ;
> alvinx.zh...@intel.com; Guo, Junfeng ; Su, Simei
> ; Burakov, Anatoly ; Ferruh
> Yigit
> Subject: [PATCH v4] net/igc: add support for secondary processes
>
> From: Zhichao Zeng
>
> The RX function was not specified in the secondary process, causing the
> secondary process to segfault in a multi-process environment.
>
> This patch specify RX/TX functions in "dev_init" to support secondary
> processes.
>
> Fixes: 66fde1b943eb ("net/igc: add skeleton")
> Cc: alvinx.zh...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Zhichao Zeng
>
> ---
> v2:
> remove unnecessary parameters, move declaration to relevant header file
> ---
> v3:
> remove redundant code, optimize commit log
> ---
> v4:
> rework patch
> ---
> drivers/net/igc/igc_ethdev.c | 9 -
> drivers/net/igc/igc_txrx.c | 8
> drivers/net/igc/igc_txrx.h | 6 ++
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/igc/igc_ethdev.c b/drivers/net/igc/igc_ethdev.c index
> b9933b395d..7f221a5d34 100644
> --- a/drivers/net/igc/igc_ethdev.c
> +++ b/drivers/net/igc/igc_ethdev.c
> @@ -1240,8 +1240,15 @@ eth_igc_dev_init(struct rte_eth_dev *dev)
>* has already done this work. Only check we don't need a different
>* RX function.
>*/
> - if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + dev->rx_pkt_burst = igc_recv_pkts;
> + if (dev->data->scattered_rx)
> + dev->rx_pkt_burst = igc_recv_scattered_pkts;
Please removed the redundant code in igc_rx_init
Re: DPDK Release Status Meeting 2022-06-30
On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit wrote: > Last minute opens were: > > * I am getting ABI check crash, when again v21.11 with abigail 2.0.0, > for the file 'librte_common_qat'. Not sure if this is specific to my > environment, would be good if someone double checks. I ran into a crash too with 2.0.0. This seems fixed in (unreleased) latest libabigail. -- David Marchand
Re: Minutes of Technical Board Meeting, 2022-06-01
On Tue, Jun 7, 2022 at 3:48 PM Olivier Matz wrote: > NOTE: Next meeting will be on Wednesday 2021-June-15 @3pm UTC, and will Looking at recent 2022 minutes, we have a few wrong 2021 dates. Not a big deal, the next techboard chairs probably won't do the same mistake :-). > be chaired by Stephen. -- David Marchand
Re: [PATCH v4] lib/eal: fix segfaults due to thread exit order
On Wed, Jun 15, 2022 at 02:01:54PM +0800, zhichaox.z...@intel.com wrote:
> From: Zhichao Zeng
>
> The eal-intr-thread is not closed before memory cleanup in the
> process of exiting. There is a small probability that when the
> eal-intr-thread is about to use some pointers, the memory were
> just cleaned, which cause the segment fault error caught by ASan.
>
> This patch close the eal-intr-thread before memory cleanup when
> exiting to avoid segment fault. And add some atomic operations
> to avoid executing rte_eal_cleanup in the child process spawned
> by fork() in some test cases, e.g. debug_autotest of dpdk-test.
>
> Cc: sta...@dpdk.org
>
Hi,
some comments inline below.
/Bruce
> ---
> v2:
> add the same API for FreeBSD
> ---
> v3:
> fix rte_eal_cleanup crash in debug_autotest
> ---
> v4:
> shorten the prompt message and optimize the commit log
>
Please put these updates below the cutline after the sign-offs, i.e.
immediately before the diffstat.
> Suggested-by: David Marchand
> Signed-off-by: Zhichao Zeng
> ---
> lib/eal/common/eal_private.h | 7 +++
> lib/eal/freebsd/eal.c| 21 -
> lib/eal/freebsd/eal_interrupts.c | 12
> lib/eal/linux/eal.c | 20 +++-
> lib/eal/linux/eal_interrupts.c | 12
> 5 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
> index 44d14241f0..7adf41b7d7 100644
> --- a/lib/eal/common/eal_private.h
> +++ b/lib/eal/common/eal_private.h
> @@ -152,6 +152,13 @@ int rte_eal_tailqs_init(void);
> */
> int rte_eal_intr_init(void);
>
> +/**
> + * Destroy interrupt handling thread.
> + *
> + * This function is private to EAL.
> + */
> +void rte_eal_intr_destroy(void);
> +
> /**
> * Close the default log stream
> *
> diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
> index a6b20960f2..4882f27abd 100644
> --- a/lib/eal/freebsd/eal.c
> +++ b/lib/eal/freebsd/eal.c
> @@ -72,6 +72,8 @@ struct lcore_config lcore_config[RTE_MAX_LCORE];
> /* used by rte_rdtsc() */
> int rte_cycles_vmware_tsc_map;
>
> +/* used to judge the running status of the eal */
> +static uint32_t run_once;
>
I don't like just moving this variable from the eal_init function. When in
eal_init the name "run_once" made sense as it tracked how often the EAL
init function was run. However, now as a global variable the name
"run_once" no longer makes sense.
Two suggestions:
1. Keep run_once in EAL init as-is, and use a different variable or value
to indicate that DPDK is initialized for cleanup.
2. Move the variable as you have here, just rename it to a more meaningful
name.
> int
> eal_clean_runtime_dir(void)
> @@ -574,12 +576,22 @@ static void rte_eal_init_alert(const char *msg)
> RTE_LOG(ERR, EAL, "%s\n", msg);
> }
>
> +static void warn_parent(void)
> +{
> + RTE_LOG(WARNING, EAL, "DPDK won't work in the child process\n");
> +}
I wonder if this contains enough information. Can we identify briefly what
parts will or won't work, or if we just want to deny everything, can we
give a brief reason why?
> +
> +static void scratch_child(void)
> +{
> + /* Scratch run_once so that a call to rte_eal_cleanup won't crash... */
> + __atomic_store_n(&run_once, 0, __ATOMIC_RELAXED);
> +}
> +
I think the name of this function needs improvement. I'm not sure that
"scratch" is the best term to use. Something like "clear_eal_flag" is
probably better.
> /* Launch threads, called at application init(). */
> int
> rte_eal_init(int argc, char **argv)
> {
> int i, fctret, ret;
> - static uint32_t run_once;
> uint32_t has_run = 0;
> char cpuset[RTE_CPU_AFFINITY_STR_LEN];
> char thread_name[RTE_MAX_THREAD_NAME_LEN];
> @@ -883,6 +895,8 @@ rte_eal_init(int argc, char **argv)
>
> eal_mcfg_complete();
>
> + pthread_atfork(NULL, warn_parent, scratch_child);
> +
> return fctret;
> }
>
> @@ -891,8 +905,13 @@ rte_eal_cleanup(void)
> {
> struct internal_config *internal_conf =
> eal_get_internal_configuration();
> +
> + if (__atomic_load_n(&run_once, __ATOMIC_RELAXED) == 0)
> + return 0;
> +
> rte_service_finalize();
> rte_mp_channel_cleanup();
> + rte_eal_intr_destroy();
> /* after this point, any DPDK pointers will become dangling */
> rte_eal_memory_detach();
> rte_eal_alarm_cleanup();
Re: DPDK Release Status Meeting 2022-06-30
On 6/30/2022 12:57 PM, David Marchand wrote: CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit wrote: Last minute opens were: * I am getting ABI check crash, when again v21.11 with abigail 2.0.0, for the file 'librte_common_qat'. Not sure if this is specific to my environment, would be good if someone double checks. I ran into a crash too with 2.0.0. This seems fixed in (unreleased) latest libabigail. Thanks David, I will try latest code.
Re: DPDK Release Status Meeting 2022-06-30
David Marchand writes: > On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit wrote: >> Last minute opens were: >> >> * I am getting ABI check crash, when again v21.11 with abigail 2.0.0, >> for the file 'librte_common_qat'. Not sure if this is specific to my >> environment, would be good if someone double checks. > > I ran into a crash too with 2.0.0. > This seems fixed in (unreleased) latest libabigail. Sorry about that. We are working towards releasing 2.1 soon, which should hopefully fix that. Cheers, -- Dodji
[PATCH] app/testpmd: fix GTP PSC raw processing
Fix GTP PSP extension size initialization.
Clear input buffer.
cc: sta...@dpdk.org
Fixes: c65282c9aa31 ("app/testpmd: fix GTP PSC raw processing")
Signed-off-by: Gregory Etelson
---
app/test-pmd/cmdline_flow.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 6cb1173385..7f50028eb7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -11030,10 +11030,12 @@ cmd_set_raw_parsed(const struct buffer *in)
const struct rte_flow_item_gtp_psc
*opt = item->spec;
struct rte_gtp_psc_generic_hdr *hdr;
-
- *total_size += RTE_ALIGN(sizeof(hdr),
+ size_t hdr_size = RTE_ALIGN(sizeof(*hdr),
sizeof(int32_t));
+
+ *total_size += hdr_size;
hdr = (typeof(hdr))(data_tail - (*total_size));
+ memset(hdr, 0, hdr_size);
*hdr = opt->hdr;
hdr->ext_hdr_len = 1;
gtp_psc = i;
--
2.34.1
Re: [PATCH] net/netvsc: replace the pointers to vmbus device from secondary process
On 6/30/2022 12:52 AM, Stephen Hemminger wrote:
On Wed, 29 Jun 2022 16:29:44 -0700
lon...@linuxonhyperv.com wrote:
From: Long Li
The vmbus device is allocated via "calloc" before the EAL memory is
initialized. The secondary process can't reference the vmbus device as it is
not mapped correctly in the shared memory region.
Replace all references to the vmbus device (and its contents) with the
pointers/contents set by the primary process.
Fixes: 4e9c73e96e ("net/netvsc: add Hyper-V network device")
Cc: sta...@dpdk.org
Signed-off-by: Long Li
Acked-by: Stephen Hemminger
Applied to dpdk-next-net/main, thanks.
[RFC] non-temporal memory access functions
This RFC proposes a set of functions optimized for non-temporal memory handling. Applications sometimes copy large amounts of data to another memory location, which is only used much later. In this case, it is inefficient to pollute the cache with the copied data. I have only provided the API, and omitted most of the implementation details. The implementation is irrelevant if the community disapproves of the concept. Although the function names resemble standard C library function names, their signatures are intentionally different. No need to drag legacy into it. The x86 non-temporal streaming instructions have alignment requirements, so I suggest we require minimum 16 byte alignment. /** * Copy data to 16 byte aligned non-temporal destination. * * @param dst * Pointer to the non-temporal destination of the data. * Must be 16 byte aligned. * @param src * Pointer to the source data. * No alignment requirements. * @param len * Number of bytes to copy. * Must be divisible by 16. */ __rte_experimental static __rte_always_inline __attribute__((__nonnull__(1, 2), __access__(write_only, 1, 3), __access__(read_only, 2, 3))) void rte_memcpy_ntd16(void * __rte_restrict dst, const void * __rte_restrict src, size_t len); /** * Copy data from 16 byte aligned non-temporal source. * * @param dst * Pointer to the destination of the data. * No alignment requirements. * @param src * Pointer to the non-temporal source data. * Must be 16 byte aligned. * @param len * Number of bytes to copy. * Must be divisible by 16. */ __rte_experimental static __rte_always_inline __attribute__((__nonnull__(1, 2), __access__(write_only, 1, 3), __access__(read_only, 2, 3))) void rte_memcpy_nts16(void * __rte_restrict dst, const void * __rte_restrict src, size_t len); /** * Copy data from 16 byte aligned non-temporal source * to 16 byte aligned non-temporal destination. * * @param dst * Pointer to the non-temporal destination of the data. * Must be 16 byte aligned. * @param src * Pointer to the non-temporal source data. * Must be 16 byte aligned. * @param len * Number of bytes to copy. * Must be divisible by 16. */ __rte_experimental static __rte_always_inline __attribute__((__nonnull__(1, 2), __access__(write_only, 1, 3), __access__(read_only, 2, 3))) void rte_memcpy_ntsd16(void * __rte_restrict dst, const void * __rte_restrict src, size_t len); /** * Fill 16 byte aligned non-temporal memory. * * @param dst * Pointer to the non-temporal memory. * Must be 16 byte aligned. * @param c * Byte to fill with. * @param len * Number of bytes to fill. * Must be divisible by 16. */ __rte_experimental static __rte_always_inline __attribute__((__nonnull__(1), __access__(write_only, 1, 3))) void rte_memset_nt16(void * dst, unsigned char c, size_t len); In addition to these, we could also provide variants with 64 byte alignment (and length divisible by 64). Those would use 64 in their names instead of 16. E.g. the name of the 64 byte aligned variant would be rte_memset_nt64(). Personally, I think the 16 byte aligned variants suffice, and 64 byte aligned variants would be overkill. Remember, the performance gain is achieved by not polluting the cache. And the implementation can still use AVX512 instructions for large copies, if desired. Another thing for discussion is the location of these functions. Should the memcpy function go into the existing rte_memcpy.h files, and a new rte_memset.h file be created? Or should a new rte_nt.h file be created for functions optimized for non-temporal memory? Personally, I think these belong together with the existing functions, rather than in a separate "non-temporal memory" library. When considering this question, remember that other functions using non-temporal memory access might be added in the future, e.g.: /** * @internal Calculate a sum of all words in the non-temporal buffer. * Helper routine for the rte_raw_cksum_nt(). * * 16 byte aligment is required when accessing non-temporal memory. * If the buffer is not 16 byte aligned, the preceding bytes are also read. * If the end of the buffer is 16 byte aligned, the following bytes are also * read. * Any such additional bytes are obvisouly not included in the checksum. * * @param buf * Pointer to the non-temporal buffer. * No alignment requirements. * @param len * Length of the buffer. * @return * Sum of all words in the buffer. */ __rte_experimental extern __attribute__((__nonnull__(1), __access__(read_only, 1, 2))) uint32_t __rte_raw_cksum_nt(const void *buf, size_t len); Med venlig hilsen / Kind regards, -Morten Brørup
Re: [PATCH v2] vdpa/sfc: handle sync issue between qemu and vhost-user
On 6/28/22 07:29, abhimanyu.sa...@xilinx.com wrote:
From: Abhimanyu Saini
When DPDK app is running in the VF, it sometimes rings the doorbell
before dev_config has had a chance to complete and hence it misses
the event. As workaround, ring the doorbell when vDPA reports the
notify_area to QEMU.
Fixes: 630be406dcbf ("vdpa/sfc: get queue notify area info")
Cc: sta...@dpdk.org
Signed-off-by: Vijay Kumar Srivastava
Signed-off-by: Abhimanyu Saini
---
v1:
* Update the commit id that this patch fixes
drivers/vdpa/sfc/sfc_vdpa_ops.c | 14 ++
1 file changed, 14 insertions(+)
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [PATCH] doc: announce marking bus object as internal
30/06/2022 11:54, Bruce Richardson: > On Thu, Jun 30, 2022 at 11:41:53AM +0200, David Marchand wrote: > > rte_bus is unnecessarily exposed in the public API/ABI. > > Besides, we had cases where extending rte_bus was necessary. > > Announce that rte_bus will be made opaque in the public API and mark > > associated API as internal. > > > > Signed-off-by: David Marchand > > --- > > A RFC series of the intended changes is available at: > > https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&archive=both > > > > --- > Acked-by: Bruce Richardson Acked-by: Thomas Monjalon
RE: [PATCH v4] doc: announce changes in bbdev related to enum extension
Hi Thomas, Any concern with that deprecation notice please? Thanks Nic > -Original Message- > From: Chautru, Nicolas > Sent: Monday, June 27, 2022 1:48 PM > To: dev@dpdk.org; tho...@monjalon.net > Cc: t...@redhat.com; Kinsella, Ray ; Richardson, > Bruce ; hemant.agra...@nxp.com; > david.march...@redhat.com; step...@networkplumber.org; Maxime > Coquelin ; gak...@marvell.com > Subject: RE: [PATCH v4] doc: announce changes in bbdev related to enum > extension > > Hi Thomas, > Kind reminder on this one. > Thanks > Nic > > > -Original Message- > > From: Chautru, Nicolas > > Sent: Friday, June 17, 2022 9:13 AM > > To: dev@dpdk.org; tho...@monjalon.net > > Cc: t...@redhat.com; Kinsella, Ray ; > > Richardson, Bruce ; > > hemant.agra...@nxp.com; david.march...@redhat.com; > > step...@networkplumber.org; Maxime Coquelin > > ; gak...@marvell.com > > Subject: RE: [PATCH v4] doc: announce changes in bbdev related to enum > > extension > > > > Hi Thomas, > > Can this one be applied based on your review? > > Thanks > > Nic > > > > > -Original Message- > > > From: Maxime Coquelin > > > Sent: Thursday, June 9, 2022 12:54 AM > > > To: Chautru, Nicolas ; dev@dpdk.org; > > > gak...@marvell.com; tho...@monjalon.net > > > Cc: t...@redhat.com; Kinsella, Ray ; > > > Richardson, Bruce ; > > > hemant.agra...@nxp.com; david.march...@redhat.com; > > > step...@networkplumber.org > > > Subject: Re: [PATCH v4] doc: announce changes in bbdev related to > > > enum extension > > > > > > Hi Nicolas, > > > > > > On 6/9/22 02:34, Nicolas Chautru wrote: > > > > Intent to resolve in DPDK 22.11 historical usage which prevents > > > > graceful extension of enum and API without troublesome ABI > > > > breakage as well as extending API RTE_BBDEV_OP_FFT for new > > > > operation type in bbdev as well as other new members in existing > structures. > > > > > > > > Signed-off-by: Nicolas Chautru > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 11 +++ > > > > 1 file changed, 11 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > b/doc/guides/rel_notes/deprecation.rst > > > > index 4e5b23c..c8ab1ec 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -112,6 +112,17 @@ Deprecation Notices > > > > session and the private data of session. An opaque pointer can > > > > be > > exposed > > > > directly to application which can be attached to the > ``rte_crypto_op``. > > > > > > > > +* bbdev: ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the > > > > +``rte_bbdev_op_type`` > > > > + enum will be deprecated and instead use fixed array size when > > > > +required to allow for > > > > + future enum extension. > > > > + Will extend API to support new operation type > > > > +``RTE_BBDEV_OP_FFT`` as per this > > > > + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111 > > > > + New members will be added in ``rte_bbdev_driver_info`` to > > > > +expose PMD queue topology inspired > > > > + by this RFC > > > > +https://patches.dpdk.org/project/dpdk/list/?series=22076 > > > > + New member will be added in ``rte_bbdev_driver_info`` to expose > > > > +the device status as per > > > > + this RFC > > > > +https://patches.dpdk.org/project/dpdk/list/?series=23367 > > > > + This should be updated in DPDK 22.11. > > > > + > > > > * security: Hide structure ``rte_security_session`` and expose an > opaque > > > > pointer for the private data to the application which can be > > > > attached > > > > to the packet while enqueuing. > > > > > > Thanks for rewording the notice. > > > > > > Acked-by: Maxime Coquelin > > > > > > Maxime
RE: [PATCH v1 0/5] Direct re-arming of buffers on receive side
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] > Sent: Wednesday, 29 June 2022 23.58 > > > > > > > > > 16/05/2022 07:10, Feifei Wang пишет: > > > > > > > >>> Currently, the transmit side frees the buffers into the > lcore > > > >>> cache and the receive side allocates buffers from the lcore > > > cache. > > > >>> The transmit side typically frees 32 buffers resulting in > > > >>> 32*8=256B of stores to lcore cache. The receive side > allocates > > > 32 > > > >>> buffers and stores them in the receive side software ring, > > > >>> resulting in 32*8=256B of stores and 256B of load from the > > > lcore cache. > > > >>> > > > >>> This patch proposes a mechanism to avoid freeing > to/allocating > > > >>> from the lcore cache. i.e. the receive side will free the > > > buffers > > > >>> from transmit side directly into it's software ring. This > will > > > >>> avoid the 256B of loads and stores introduced by the lcore > > > cache. > > > >>> It also frees up the cache lines used by the lcore cache. > > > >>> > > > >>> However, this solution poses several constraints: > > > >>> > > > >>> 1)The receive queue needs to know which transmit queue it > > > should > > > >>> take the buffers from. The application logic decides which > > > >>> transmit port to use to send out the packets. In many use > > > >>> cases the NIC might have a single port ([1], [2], [3]), in > > > >>> which case > > > a > > > >>> given transmit queue is always mapped to a single receive > > > >>> queue > > > >>> (1:1 Rx queue: Tx queue). This is easy to configure. > > > >>> > > > >>> If the NIC has 2 ports (there are several references), then > we > > > >>> will have > > > >>> 1:2 (RX queue: TX queue) mapping which is still easy to > > > configure. > > > >>> However, if this is generalized to 'N' ports, the > > > >>> configuration can be long. More over the PMD would have to > > > >>> scan a list of transmit queues to pull the buffers from. > > > > > > > >> Just to re-iterate some generic concerns about this > proposal: > > > >> - We effectively link RX and TX queues - when this > feature > > > is enabled, > > > >> user can't stop TX queue without stopping linked RX > queue > > > first. > > > >> Right now user is free to start/stop any queues at his > > > will. > > > >> If that feature will allow to link queues from > different > > > ports, > > > >> then even ports will become dependent and user will > have > > > to pay extra > > > >> care when managing such ports. > > > > > > > > [Feifei] When direct rearm enabled, there are two path for > > > > thread > > > to > > > > choose. If there are enough Tx freed buffers, Rx can put > buffers > > > > from Tx. > > > > Otherwise, Rx will put buffers from mempool as usual. Thus, > > > > users > > > do > > > > not need to pay much attention managing ports. > > > > > > What I am talking about: right now different port or different > > > queues > > > of the same port can be treated as independent entities: > > > in general user is free to start/stop (and even reconfigure in > > > some > > > cases) one entity without need to stop other entity. > > > I.E user can stop and re-configure TX queue while keep > receiving > > > packets from RX queue. > > > With direct re-arm enabled, I think it wouldn't be possible > any > > > more: > > > before stopping/reconfiguring TX queue user would have make > sure > > > that > > > corresponding RX queue wouldn't be used by datapath. > > > >>> I am trying to understand the problem better. For the TX queue > to > > > be stopped, > > > >> the user must have blocked the data plane from accessing the TX > > > queue. > > > >> > > > >> Surely it is user responsibility tnot to call tx_burst() for > > > stopped/released queue. > > > >> The problem is that while TX for that queue is stopped, RX for > > > related queue still > > > >> can continue. > > > >> So rx_burst() will try to read/modify TX queue data, that might > be > > > already freed, > > > >> or simultaneously modified by control path. > > > > Understood, agree on the issue > > > > > > > >> > > > >> Again, it all can be mitigated by carefully re-designing and > > > modifying control and > > > >> data-path inside user app - by doing extra checks and > > > synchronizations, etc. > > > >> But from practical point - I presume most of users simply would > > > avoid using this > > > >> feature due all potential problems it might cause. > > > > That is subjective, it all depends on the performance > improvements > > > users see in their application. > > > > IMO, the performance improvement seen with this patch is worth > few > > > changes. > > > > > > Yes, it is subjective till some extent, though my feeling that it > > > might end-up
RE: Optimizations are not features
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Wednesday, 29 June 2022 22.44
>
>
>
> >
> > 04/06/2022 13:51, Andrew Rybchenko пишет:
> > > On 6/4/22 15:19, Morten Brørup wrote:
> > >>> From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > >>> Sent: Saturday, 4 June 2022 13.10
> > >>>
> > >>> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> > >>> wrote:
> >
> > On 6/4/22 12:33, Jerin Jacob wrote:
> > > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> > >>> wrote:
> > >>
> > >> I would like the DPDK community to change its view on compile
> > >> time
> > >>> options. Here is why:
> > >>
> > >>
> > >>
> > >> Application specific performance micro-optimizations like
> “fast
> > >>> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> > >>> presented as features.
> > >>
> > >>
> > >>
> > >> They are not features, but optimizations, and I don’t
> understand
> > >>> the need for them to be available at run-time!
> > >>
> > >>
> > >>
> > >> Instead of adding a bunch of exotic exceptions to the fast
> path
> > >> of
> > >>> the PMDs, they should be compile time options. This will improve
> > >>> performance by avoiding branches in the fast path, both for the
> > >>> applications using them, and for generic applications (where the
> > >>> exotic code is omitted).
> > >
> > > Agree. I think, keeping the best of both worlds would be
> > >
> > > -Enable the feature/optimization as runtime -Have a compile-
> time
> > > option to disable the feature/optimization as
> > >>> an override.
> >
> > It is hard to find the right balance, but in general compile
> time
> > options are a nightmare for maintenance. Number of required
> builds
> > will grow as an exponent.
> > >>
> > >> Test combinations are exponential for N features, regardless if N
> are
> > >> runtime or compile time options.
> > >
> > > But since I'm talking about build checks I don't care about
> > > exponential grows in run time. Yes, testing should care, but it is
> a separate
> > story.
> > >
> > >>
> > Of course, we can
> > limit number of checked combinations, but it will result in flow
> of
> > patches to fix build in other cases.
> > >>>
> > >>> The build breakage can be fixed if we use (2) vs (1)
> > >>>
> > >>> 1)
> > >>> #ifdef ...
> > >>> My feature
> > >>> #endif
> > >>>
> > >>> 2)
> > >>> static __rte_always_inline int
> > >>> rte_has_xyz_feature(void)
> > >>> {
> > >>> #ifdef RTE_LIBRTE_XYZ_FEATURE
> > >>> return RTE_LIBRTE_XYZ_FEATURE; #else
> > >>> return 0;
> > >>> #endif
> > >>> }
> > >>>
> > >>> if(rte_has_xyz_feature())) {
> > >>> My feature code
> > >>>
> > >>> }
> > >>>
> > >
> > > Jerin, thanks, very good example.
> > >
> > >> I'm not sure all the features can be covered by that, e.g. added
> > >> fields in structures.
> > >
> > > +1
> > >
> > >>
> > >> Also, I would consider such features "opt in" at compile time
> only.
> > >> As such, they could be allowed to break the ABI/API.
> > >>
> > >>>
> > >>>
> > Also compile time options tend to make code less readable which
> > makes all aspects of the development harder.
> >
> > Yes, compile time is nice for micro optimizations, but I have
> great
> > concerns that it is a right way to go.
> >
> > >> Please note that I am only talking about the performance
> > >>> optimizations that are limited to application specific use cases.
> I
> > >>> think it makes sense to require that performance optimizing an
> > >>> application also requires recompiling the performance critical
> > >>> libraries used by it.
> > >>abandon some of existing functionality to create a 'short-cut'
> > >>
> > >>
> > >> Allowing compile time options for application specific
> > >> performance
> > >>> optimizations in DPDK would also open a path for other
> > >>> optimizations, which can only be achieved at compile time, such
> as
> > >>> “no fragmented packets”, “no attached mbufs” and “single mbuf
> pool”.
> > >>> And even more exotic optimizations, such as the “indexed mempool
> > >>> cache”, which was rejected due to ABI violations – they could be
> > >>> marked as “risky and untested” or similar, but still be part of
> the DPDK main
> > repository.
> > >>
> >
> >
> > Thanks Morten for bringing it up, it is an interesting topic.
> > Though I look at it from different angle.
> > All optimizations you mentioned above introduce new limitations:
> > MBUF_FAST_FREE - no indirect mbufs and multiple mempools, mempool
> object
> > indexes - mempool size is limited to 4GB, direct rearm - drop ability
> to
> > stop/reconfigure TX queue, while RX queue is still running, etc.
> > Note that all these limitations are not forced by HW.
> > All of them are pure SW limitations that developers forced in (or
> tried to) to get
> > few extra performance.
> > That's concerning tendency.
> >
[PATCH v2] crypto/ipsec_mb: enable support for arm64
Enable support for arm64 architecture in ipsec_mb. x86
specific code is conditionally compiled only for x86
architecture builds. Other architectures will be unsupported.
Signed-off-by: Ashwin Sekhar T K
---
drivers/crypto/ipsec_mb/ipsec_mb_private.c | 7 +++
drivers/crypto/ipsec_mb/ipsec_mb_private.h | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_private.c
b/drivers/crypto/ipsec_mb/ipsec_mb_private.c
index aab42c360c..b555a28a0b 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_private.c
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_private.c
@@ -53,6 +53,9 @@ ipsec_mb_create(struct rte_vdev_device *vdev,
const char *name, *args;
int retval;
+#if defined(RTE_ARCH_ARM64)
+ vector_mode = IPSEC_MB_ARM64;
+#elif defined(RTE_ARCH_X86_64)
if (vector_mode == IPSEC_MB_NOT_SUPPORTED) {
/* Check CPU for supported vector instruction set */
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F))
@@ -64,6 +67,10 @@ ipsec_mb_create(struct rte_vdev_device *vdev,
else
vector_mode = IPSEC_MB_SSE;
}
+#else
+ /* Unsupported architecture */
+ return -ENOTSUP;
+#endif
init_params.private_data_size = sizeof(struct ipsec_mb_dev_private) +
pmd_data->internals_priv_size;
diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_private.h
b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
index e2c240dfc0..d0a1bcc360 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_private.h
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_private.h
@@ -26,7 +26,8 @@ enum ipsec_mb_vector_mode {
IPSEC_MB_SSE,
IPSEC_MB_AVX,
IPSEC_MB_AVX2,
- IPSEC_MB_AVX512
+ IPSEC_MB_AVX512,
+ IPSEC_MB_ARM64,
};
extern enum ipsec_mb_vector_mode vector_mode;
--
2.25.1
Re: [PATCH 3/4] vhost: improve some datapath log messages
On 6/27/22 11:27, David Marchand wrote: Those messages were missed when adding socket context. Fix this. Signed-off-by: David Marchand --- lib/vhost/vhost.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Maxime Coquelin Thanks, Maxime
Re: [PATCH 4/4] vhost: prefix logs with context
Hi David, On 6/27/22 11:27, David Marchand wrote: We recently improved the log messages in the vhost library, adding some context that helps filtering for a given vhost-user device. However, some parts of the code were missed, and some later code changes broke this new convention (fixes were sent previous to this patch). Change the VHOST_LOG_CONFIG/DATA helpers and always ask for a string used as context. This should help limit regressions on this topic. Most of the time, the context is the vhost-user device socket path. For the rest when a vhost-user device can not be related, generic names were chosen: - "dma", for vhost-user async DMA operations, - "device", for vhost-user device creation and lookup, - "thread", for threads management, Signed-off-by: David Marchand --- lib/vhost/iotlb.c | 30 +- lib/vhost/socket.c | 129 - lib/vhost/vdpa.c | 4 +- lib/vhost/vhost.c | 144 - lib/vhost/vhost.h | 20 +- lib/vhost/vhost_user.c | 642 + lib/vhost/virtio_net.c | 258 + 7 files changed, 634 insertions(+), 593 deletions(-) diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h index 810bc71c9d..310aaf88ff 100644 --- a/lib/vhost/vhost.h +++ b/lib/vhost/vhost.h @@ -625,14 +625,14 @@ vhost_log_write_iova(struct virtio_net *dev, struct vhost_virtqueue *vq, extern int vhost_config_log_level; extern int vhost_data_log_level; -#define VHOST_LOG_CONFIG(level, fmt, args...) \ +#define VHOST_LOG_CONFIG(prefix, level, fmt, args...) \ rte_log(RTE_LOG_ ## level, vhost_config_log_level, \ - "VHOST_CONFIG: " fmt, ##args) + "VHOST_CONFIG: (%s): " fmt, prefix, ##args) -#define VHOST_LOG_DATA(level, fmt, args...) \ +#define VHOST_LOG_DATA(prefix, level, fmt, args...)\ (void)((RTE_LOG_ ## level <= RTE_LOG_DP_LEVEL) ? \ rte_log(RTE_LOG_ ## level, vhost_data_log_level, \ - "VHOST_DATA : " fmt, ##args) :\ + "VHOST_DATA: (%s):" fmt, prefix, ##args) :\ 0) As discussed off-list, adding the function will break OVS tests once again. I propose to pick the first 3 patches for now. Thanks, Maxime
Re: [PATCH v2] examples/ipsec-secgw: fix fallback session create
Tested-by: Vladimir Medvedkin
On 30/06/2022 12:45, Radu Nicolau wrote:
Fix fallback session create for inline sessions.
Fixes: a8ade12123c3 ("examples/ipsec-secgw: create lookaside sessions at init")
Cc: vfia...@marvell.com
Signed-off-by: Radu Nicolau
---
v2: create the session rather than just check if it's NULLL
examples/ipsec-secgw/sa.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 5d9cec97db..d081cd0e2c 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1533,7 +1533,8 @@ fill_ipsec_session(struct rte_ipsec_session *ss, struct
rte_ipsec_sa *sa)
* Initialise related rte_ipsec_sa object.
*/
static int
-ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa *sa, uint32_t sa_size)
+ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa *sa, uint32_t sa_size,
+ struct socket_ctx *skt_ctx, struct ipsec_ctx *ips_ctx[])
{
int rc;
struct rte_ipsec_sa_prm prm;
@@ -1572,8 +1573,15 @@ ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa
*sa, uint32_t sa_size)
return rc;
/* init inline fallback processing session */
- if (lsa->fallback_sessions == 1)
- rc = fill_ipsec_session(ipsec_get_fallback_session(lsa), sa);
+ if (lsa->fallback_sessions == 1) {
+ struct rte_ipsec_session *ipfs =
ipsec_get_fallback_session(lsa);
+ if (ipfs->security.ses == NULL) {
+ rc = create_lookaside_session(ips_ctx, skt_ctx, lsa,
ipfs);
+ if (rc != 0)
+ return rc;
+ }
+ rc = fill_ipsec_session(ipfs, sa);
+ }
return rc;
}
@@ -1583,7 +1591,8 @@ ipsec_sa_init(struct ipsec_sa *lsa, struct rte_ipsec_sa
*sa, uint32_t sa_size)
* one per session.
*/
static int
-ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent, int32_t socket)
+ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent, int32_t socket,
+ struct socket_ctx *skt_ctx, struct ipsec_ctx *ips_ctx[])
{
int32_t rc, sz;
uint32_t i, idx;
@@ -1621,7 +1630,7 @@ ipsec_satbl_init(struct sa_ctx *ctx, uint32_t nb_ent,
int32_t socket)
sa = (struct rte_ipsec_sa *)((uintptr_t)ctx->satbl + sz * i);
lsa = ctx->sa + idx;
- rc = ipsec_sa_init(lsa, sa, sz);
+ rc = ipsec_sa_init(lsa, sa, sz, skt_ctx, ips_ctx);
}
return rc;
@@ -1700,7 +1709,7 @@ sa_init(struct socket_ctx *ctx, int32_t socket_id,
if (app_sa_prm.enable != 0) {
rc = ipsec_satbl_init(ctx->sa_in, nb_sa_in,
- socket_id);
+ socket_id, ctx, ipsec_ctx);
if (rc != 0)
rte_exit(EXIT_FAILURE,
"failed to init inbound SAs\n");
@@ -1722,7 +1731,7 @@ sa_init(struct socket_ctx *ctx, int32_t socket_id,
if (app_sa_prm.enable != 0) {
rc = ipsec_satbl_init(ctx->sa_out, nb_sa_out,
- socket_id);
+ socket_id, ctx, ipsec_ctx);
if (rc != 0)
rte_exit(EXIT_FAILURE,
"failed to init outbound SAs\n");
--
Regards,
Vladimir
[PATCH] mbuf: add mbuf physical address field to dynamic field
If all devices are configured to run in IOVA mode as VA, physical
address field of mbuf (buf_iova) won't be used. In such cases, buf_iova
space is free to use as a dynamic field. So a new dynamic field member
(dynfield2) is added in mbuf structure to make use of that space.
A new mbuf flag RTE_MBUF_F_DYNFIELD2 is introduced to help identify the
mbuf that can use dynfield2.
Signed-off-by: Shijith Thotton
---
lib/mbuf/rte_mbuf.c | 8
lib/mbuf/rte_mbuf.h | 16 +---
lib/mbuf/rte_mbuf_core.h | 29 ++---
lib/mbuf/rte_mbuf_dyn.c | 3 +++
4 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
index a2307cebe6..718b4505c4 100644
--- a/lib/mbuf/rte_mbuf.c
+++ b/lib/mbuf/rte_mbuf.c
@@ -101,6 +101,10 @@ rte_pktmbuf_init(struct rte_mempool *mp,
m->port = RTE_MBUF_PORT_INVALID;
rte_mbuf_refcnt_set(m, 1);
m->next = NULL;
+
+ /* enable dynfield2 if IOVA mode is VA */
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ m->ol_flags = RTE_MBUF_F_DYNFIELD2;
}
/*
@@ -206,6 +210,10 @@ __rte_pktmbuf_init_extmem(struct rte_mempool *mp,
rte_mbuf_refcnt_set(m, 1);
m->next = NULL;
+ /* enable dynfield2 if IOVA mode is VA */
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ m->ol_flags |= RTE_MBUF_F_DYNFIELD2;
+
/* init external buffer shared info items */
shinfo = RTE_PTR_ADD(m, mbuf_size);
m->shinfo = shinfo;
diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
index 9811e8c760..59485f04ed 100644
--- a/lib/mbuf/rte_mbuf.h
+++ b/lib/mbuf/rte_mbuf.h
@@ -1056,9 +1056,11 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void
*buf_addr,
RTE_ASSERT(shinfo->free_cb != NULL);
m->buf_addr = buf_addr;
- m->buf_iova = buf_iova;
m->buf_len = buf_len;
+ if (!RTE_MBUF_HAS_DYNFIELD2(m))
+ m->buf_iova = buf_iova;
+
m->data_len = 0;
m->data_off = 0;
@@ -1087,6 +1089,10 @@ static inline void
rte_mbuf_dynfield_copy(struct rte_mbuf *mdst, const struct rte_mbuf *msrc)
{
memcpy(&mdst->dynfield1, msrc->dynfield1, sizeof(mdst->dynfield1));
+
+ if (RTE_MBUF_HAS_DYNFIELD2(mdst))
+ memcpy(&mdst->dynfield2, &msrc->dynfield2,
+ sizeof(mdst->dynfield2));
}
/* internal */
@@ -1143,10 +1149,12 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf
*mi, struct rte_mbuf *m)
mi->data_off = m->data_off;
mi->data_len = m->data_len;
- mi->buf_iova = m->buf_iova;
mi->buf_addr = m->buf_addr;
mi->buf_len = m->buf_len;
+ if (!RTE_MBUF_HAS_DYNFIELD2(mi))
+ mi->buf_iova = m->buf_iova;
+
mi->next = NULL;
mi->pkt_len = mi->data_len;
mi->nb_segs = 1;
@@ -1245,11 +1253,13 @@ static inline void rte_pktmbuf_detach(struct rte_mbuf
*m)
m->priv_size = priv_size;
m->buf_addr = (char *)m + mbuf_size;
- m->buf_iova = rte_mempool_virt2iova(m) + mbuf_size;
m->buf_len = (uint16_t)buf_len;
rte_pktmbuf_reset_headroom(m);
m->data_len = 0;
m->ol_flags = 0;
+
+ if (!RTE_MBUF_HAS_DYNFIELD2(m))
+ m->buf_iova = rte_mempool_virt2iova(m) + mbuf_size;
}
/**
diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
index 3d6ddd6773..a549e36464 100644
--- a/lib/mbuf/rte_mbuf_core.h
+++ b/lib/mbuf/rte_mbuf_core.h
@@ -504,6 +504,8 @@ extern "C" {
#define RTE_MBUF_F_INDIRECT(1ULL << 62) /**< Indirect attached mbuf */
#define IND_ATTACHED_MBUF RTE_DEPRECATED(IND_ATTACHED_MBUF) RTE_MBUF_F_INDIRECT
+#define RTE_MBUF_F_DYNFIELD2 (1ULL << 63) /**< dynfield2 mbuf field enabled
*/
+
/** Alignment constraint of mbuf private area. */
#define RTE_MBUF_PRIV_ALIGN 8
@@ -579,13 +581,18 @@ struct rte_mbuf {
RTE_MARKER cacheline0;
void *buf_addr; /**< Virtual address of segment buffer. */
- /**
-* Physical address of segment buffer.
-* Force alignment to 8-bytes, so as to ensure we have the exact
-* same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
-* working on vector drivers easier.
-*/
- rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
+ RTE_STD_C11
+ union {
+ /**
+* Physical address of segment buffer if IOVA mode is not VA.
+* Force alignment to 8-bytes, so as to ensure we have the exact
+* same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
+* working on vector drivers easier.
+*/
+ rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
+ /* Reserved for dynamic field if IOVA mode is VA. */
+ uint64_t dynfield2;
+ };
/* next 8 bytes are initialised on RX descriptor rearm */
RTE_MARKER64 rearm_data;
@@ -803,
RE: [PATCH v4] net: fix checksum with unaligned buffer
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Tuesday, 28 June 2022 08.28 > > On 2022-06-27 22:21, Morten Brørup wrote: > >> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > >> Sent: Monday, 27 June 2022 19.23 > >> > >> On 2022-06-27 15:22, Morten Brørup wrote: > From: Emil Berg [mailto:emil.b...@ericsson.com] > Sent: Monday, 27 June 2022 14.51 > > > From: Emil Berg > > Sent: den 27 juni 2022 14:46 > > > >> From: Mattias Rönnblom > >> Sent: den 27 juni 2022 14:28 > >> > >> On 2022-06-23 14:51, Morten Brørup wrote: > From: Morten Brørup [mailto:m...@smartsharesystems.com] > Sent: Thursday, 23 June 2022 14.39 > > With this patch, the checksum can be calculated on an > unaligned > buffer. > I.e. the buf parameter is no longer required to be 16 bit > aligned. > > The checksum is still calculated using a 16 bit aligned > pointer, > so > the compiler can auto-vectorize the function's inner loop. > > When the buffer is unaligned, the first byte of the buffer is > handled separately. Furthermore, the calculated checksum of > the > buffer is byte shifted before being added to the initial > checksum, > to compensate for the checksum having been calculated on the > buffer > shifted by one byte. > > v4: > * Add copyright notice. > * Include stdbool.h (Emil Berg). > * Use RTE_PTR_ADD (Emil Berg). > * Fix one more typo in commit message. Is 'unligned' even a > word? > v3: > * Remove braces from single statement block. > * Fix typo in commit message. > v2: > * Do not assume that the buffer is part of an aligned packet > buffer. > > Bugzilla ID: 1035 > Cc: sta...@dpdk.org > > Signed-off-by: Morten Brørup > > > > [...] > > > >> > >> The compiler will be able to auto vectorize even unaligned > accesses, > >> just with different instructions. From what I can tell, there's > no > >> performance impact, at least not on the x86_64 systems I tried > on. > >> > >> I think you should remove the first special case conditional and > use > >> memcpy() instead of the cumbersome __may_alias__ construct to > retrieve > >> the data. > >> > > > > Here: > > https://www.agner.org/optimize/instruction_tables.pdf > > it lists the latency of vmovdqa (aligned) as 6 cycles and the > >> latency > for > > vmovdqu (unaligned) as 7 cycles. So I guess there can be some > difference. > > Although in practice I'm not sure what difference it makes. I've > >> not > seen any > > difference in runtime between the two versions. > > > > Correction to my comment: > Those stats are for some older CPU. For some newer CPUs such as > >> Tiger > Lake the stats seem to be the same regardless of aligned or > >> unaligned. > > >>> > >>> I agree that the memcpy method is more elegant and easy to read. > >>> > >>> However, we would need to performance test the modified checksum > >> function with a large number of CPUs to prove that we don't > introduce a > >> performance regression on any CPU architecture still supported by > DPDK. > >> And Emil already found a CPU where it costs 1 extra cycle per 16 > bytes, > >> which adds up to a total of ca. 91 extra cycles on a 1460 byte TCP > >> packet. > >>> > >> > >> I think you've misunderstood what latency means in such tables. It's > a > >> data dependency thing, not a measure of throughput. The throughput > is > >> *much* higher. My guess would be two such instruction per clock. > >> > >> For your 1460 bytes example, my Zen3 AMD needs performs identical > with > >> both the current DPDK implementation, your patch, and a memcpy()- > ified > >> version of the current implementation. They all need ~130 clock > >> cycles/packet, with warm caches. IPC is 3 instructions per cycle, > but > >> obvious not all instructions are SIMD. > > > > You're right, I wasn't thinking deeper about it before extrapolating. > > > > Great to see some real numbers! I wish someone would do the same > testing on an old ARM CPU, so we could also see the other end of the > scale. > > > > I've ran it on an ARM A72. For the aligned 1460 bytes case I got: > Current DPDK ~572 cc. Your patch: ~578 cc. Memcpy-fied: ~573 cc. They > performed about the same for all unaligned/aligned and sizes I tested. > This platform (or could be GCC version as well) doesn't suffer from the > unaligned performance degradation your patch showed on my AMD machine. > > >> The main issue with checksumming on the CPU is, in my experience, > not > >> that you don't have enough compute, but that you trash the caches. > > > > Agree. I have noticed that x86 has "non-temporal" instruction > var
Re: [PATCH] mbuf: add mbuf physical address field to dynamic field
On Thu, 30 Jun 2022 21:55:16 +0530 Shijith Thotton wrote: > If all devices are configured to run in IOVA mode as VA, physical > address field of mbuf (buf_iova) won't be used. In such cases, buf_iova > space is free to use as a dynamic field. So a new dynamic field member > (dynfield2) is added in mbuf structure to make use of that space. > > A new mbuf flag RTE_MBUF_F_DYNFIELD2 is introduced to help identify the > mbuf that can use dynfield2. > > Signed-off-by: Shijith Thotton This seems like a complex and potentially error prone way to do this. What is the use case? How much of a performance gain?
[PATCH] doc: add deprecation notice for kni example
As agreed by DPDK Technical Board, the KNI example app is due to be removed from the repository to discourage use in future projects, given that better alternatives exist. Signed-off-by: Bruce Richardson --- doc/guides/rel_notes/deprecation.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..ee36fc684d 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,7 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* examples/kni: The ``kni`` kernel module and library are not recommended for use by new applications - + other technologies such as virtio-user are recommended instead. + Because of this, the example application for kni is deprecated and will be removed in a future release. -- 2.34.1
Re: [PATCH] mbuf: add mbuf physical address field to dynamic field
On Thu, Jun 30, 2022 at 09:55:16PM +0530, Shijith Thotton wrote: > If all devices are configured to run in IOVA mode as VA, physical > address field of mbuf (buf_iova) won't be used. In such cases, buf_iova > space is free to use as a dynamic field. So a new dynamic field member > (dynfield2) is added in mbuf structure to make use of that space. > > A new mbuf flag RTE_MBUF_F_DYNFIELD2 is introduced to help identify the > mbuf that can use dynfield2. > > Signed-off-by: Shijith Thotton > --- I disagree with this patch. The mbuf should always record the iova of the buffer directly, rather than forcing the drivers to query the EAL mode. This will likely also break all vector drivers right now, as they are sensitive to the mbuf layout and the position of the IOVA address in the buffer. /Bruce
Re: [PATCH v4] net: fix checksum with unaligned buffer
On Thu, 23 Jun 2022 14:39:00 +0200 Morten Brørup wrote: > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > index b502481670..738d643da0 100644 > --- a/lib/net/rte_ip.h > +++ b/lib/net/rte_ip.h > @@ -3,6 +3,7 @@ > * The Regents of the University of California. > * Copyright(c) 2010-2014 Intel Corporation. > * Copyright(c) 2014 6WIND S.A. > + * Copyright(c) 2022 SmartShare Systems. > * All rights reserved. > */ NAK Doing a small incremental fix should not change copyright.
Re: [PATCH v4] net: fix checksum with unaligned buffer
On Thu, 23 Jun 2022 14:39:00 +0200
Morten Brørup wrote:
> + /* if buffer is unaligned, keeping it byte order independent */
> + if (unlikely(unaligned)) {
> + uint16_t first = 0;
> + if (unlikely(len == 0))
> + return 0;
Why is length == 0 unique to unaligned case?
> + ((unsigned char *)&first)[1] = *(const unsigned char *)buf;
Use a proper union instead of casting to avoid aliasing warnings.
> + bsum += first;
> + buf = RTE_PTR_ADD(buf, 1);
> + len--;
> + }
Many CPU's (such as x86) won't care about alignment and therefore the extra
code to handle this is not worth doing.
Perhaps DPDK needs a macro (like Linux kernel) for efficient unaligned access.
In Linux kernel it is CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
Re: DPDK Release Status Meeting 2022-06-30
On 6/30/2022 1:43 PM, Dodji Seketeli wrote: David Marchand writes: On Thu, Jun 30, 2022 at 1:43 PM Ferruh Yigit wrote: Last minute opens were: * I am getting ABI check crash, when again v21.11 with abigail 2.0.0, for the file 'librte_common_qat'. Not sure if this is specific to my environment, would be good if someone double checks. I ran into a crash too with 2.0.0. This seems fixed in (unreleased) latest libabigail. Sorry about that. We are working towards releasing 2.1 soon, which should hopefully fix that. I confirm issue is solved with latest head (libabigail-2.0-140-gd21dba84). Thanks, ferruh
[Bug 1046] igb_uio fails to build with kernel 5.19
https://bugs.dpdk.org/show_bug.cgi?id=1046
Bug ID: 1046
Summary: igb_uio fails to build with kernel 5.19
Product: DPDK
Version: 22.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: ferr...@gmail.com
Target Milestone: ---
$ make kernelversion
5.19.0-rc4
igb_uio:
repo: https://dpdk.org/git/dpdk-kmods
Commit e68a705cc5dc ("linux/igb_uio: fix build for switch fall through")
Build command:
make V=1 KSRC=
Build error:
.../dpdk-kmods/linux/igb_uio/igb_uio.c: In function ‘igbuio_pci_probe’:
.../dpdk-kmods/linux/igb_uio/igb_uio.c:515:8:
error: implicit declaration of function ‘pci_set_dma_mask’; did you mean
‘ipi_send_mask’? [-Werror=implicit-function-declaration]
515 | err = pci_set_dma_mask(dev, DMA_BIT_MASK(64));
|^~~~
.../dpdk-kmods/linux/igb_uio/igb_uio.c:521:8:
error: implicit declaration of function ‘pci_set_consistent_dma_mask’
[-Werror=implicit-function-declaration]
521 | err = pci_set_consistent_dma_mask(dev, DMA_BIT_MASK(64));
|^~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:249:
.../dpdk-kmods/linux/igb_uio/igb_uio.o] Error 1
--
You are receiving this mail because:
You are the assignee for the bug.
RE: [PATCH] doc: add event timer expiry drop stat
> -Original Message- > From: Naga Harish K, S V > Sent: Monday, June 27, 2022 10:40 AM > To: m...@ashroe.eu; jer...@marvell.com; pbhagavat...@marvell.com; > sthot...@marvell.com; Carrillo, Erik G > Cc: dev@dpdk.org > Subject: [PATCH] doc: add event timer expiry drop stat > > The structure ``rte_event_timer_adapter_stats`` will be extended by adding > a new field, ``evtim_drop_count``. This stat will represent the number of > times an event timer expiry is dropped by the event timer adapter. > > Signed-off-by: Naga Harish K S V Reviewed-by: Erik Gabriel Carrillo
RE: [PATCH] doc: add deprecation notice for kni example
> -Original Message- > From: Bruce Richardson > Sent: Friday, July 1, 2022 12:51 AM > To: dev@dpdk.org > Cc: Richardson, Bruce > Subject: [PATCH] doc: add deprecation notice for kni example > > As agreed by DPDK Technical Board, the KNI example app is due to be > removed from the repository to discourage use in future projects, given > that better alternatives exist. > > Signed-off-by: Bruce Richardson > --- > doc/guides/rel_notes/deprecation.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 4e5b23c53d..ee36fc684d 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -125,3 +125,7 @@ Deprecation Notices >applications should be updated to use the ``dmadev`` library instead, >with the underlying HW-functionality being provided by the ``ioat`` or >``idxd`` dma drivers > + > +* examples/kni: The ``kni`` kernel module and library are not recommended > for use by new applications - > + other technologies such as virtio-user are recommended instead. > + Because of this, the example application for kni is deprecated and will > be removed in a future release. > -- > 2.34.1 Acked-by: Chenbo Xia
[PATCH v4 00/12] preparation for the rte_flow offload of nfp PMD
This is the first patch series to add the support of rte_flow offload for
nfp PMD, includes:
Add the support of flower firmware
Add the support of representor port
Add the flower service infrastructure
Add the cmsg interactive channels between pmd and fw
* Changes since v3
- Add the 'Depends-on' tag
* Changes since v2
- Remove the use of rte_panic()
* Changes since v1
- Fix the compile error
Depends-on: series-23707 ("Add support of NFP3800 chip and firmware with NFDk")
Chaoyong He (12):
net/nfp: move app specific attributes to own struct
net/nfp: simplify initialization and remove dead code
net/nfp: move app specific init logic to own function
net/nfp: add initial flower firmware support
net/nfp: add flower PF setup and mempool init logic
net/nfp: add flower PF related routines
net/nfp: add flower ctrl VNIC related logics
net/nfp: move common rxtx function for flower use
net/nfp: add flower ctrl VNIC rxtx logic
net/nfp: add flower representor framework
net/nfp: move rxtx function to header file
net/nfp: add flower PF rxtx logic
drivers/net/nfp/flower/nfp_flower.c | 1565 +++
drivers/net/nfp/flower/nfp_flower.h | 71 +
drivers/net/nfp/flower/nfp_flower_cmsg.c| 165 +++
drivers/net/nfp/flower/nfp_flower_cmsg.h| 173 +++
drivers/net/nfp/flower/nfp_flower_ctrl.c| 248
drivers/net/nfp/flower/nfp_flower_ctrl.h| 13 +
drivers/net/nfp/flower/nfp_flower_ovs_compat.h | 145 +++
drivers/net/nfp/flower/nfp_flower_representor.c | 508
drivers/net/nfp/flower/nfp_flower_representor.h | 39 +
drivers/net/nfp/meson.build |4 +
drivers/net/nfp/nfp_common.c|2 +-
drivers/net/nfp/nfp_common.h| 37 +-
drivers/net/nfp/nfp_cpp_bridge.c| 87 +-
drivers/net/nfp/nfp_cpp_bridge.h|4 +-
drivers/net/nfp/nfp_ethdev.c| 359 --
drivers/net/nfp/nfp_ethdev_vf.c |2 +-
drivers/net/nfp/nfp_rxtx.c | 123 +-
drivers/net/nfp/nfp_rxtx.h | 121 ++
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 31 +-
19 files changed, 3412 insertions(+), 285 deletions(-)
create mode 100644 drivers/net/nfp/flower/nfp_flower.c
create mode 100644 drivers/net/nfp/flower/nfp_flower.h
create mode 100644 drivers/net/nfp/flower/nfp_flower_cmsg.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_cmsg.h
create mode 100644 drivers/net/nfp/flower/nfp_flower_ctrl.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_ctrl.h
create mode 100644 drivers/net/nfp/flower/nfp_flower_ovs_compat.h
create mode 100644 drivers/net/nfp/flower/nfp_flower_representor.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_representor.h
--
1.8.3.1
[PATCH v4 01/12] net/nfp: move app specific attributes to own struct
The NFP Card can load different firmware applications. Currently
only the CoreNIC application is supported. This commit makes
needed infrastructure changes in order to support other firmware
applications too.
Clearer separation is made between the PF device and any application
specific concepts. The PF struct is now generic regardless of the
application loaded. A new struct is also made for the CoreNIC
application. Future additions to support other applications should
also add an applications specific struct.
Signed-off-by: Chaoyong He
Signed-off-by: Heinrich Kuhn
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_common.h | 33 +++-
drivers/net/nfp/nfp_ethdev.c | 196 +++
2 files changed, 154 insertions(+), 75 deletions(-)
diff --git a/drivers/net/nfp/nfp_common.h b/drivers/net/nfp/nfp_common.h
index 6d917e4..2aaf1d6 100644
--- a/drivers/net/nfp/nfp_common.h
+++ b/drivers/net/nfp/nfp_common.h
@@ -111,6 +111,14 @@
#include
#include
+/* Firmware application ID's */
+enum nfp_app_id {
+ NFP_APP_CORE_NIC = 0x1,
+ NFP_APP_BPF_NIC= 0x2,
+ NFP_APP_FLOWER_NIC = 0x3,
+ NFP_APP_ACTIVE_BUFFER_MGMT_NIC = 0x4,
+};
+
/* nfp_qcp_ptr - Read or Write Pointer of a queue */
enum nfp_qcp_ptr {
NFP_QCP_READ_PTR = 0,
@@ -121,8 +129,10 @@ struct nfp_pf_dev {
/* Backpointer to associated pci device */
struct rte_pci_device *pci_dev;
- /* Array of physical ports belonging to this PF */
- struct nfp_net_hw *ports[NFP_MAX_PHYPORTS];
+ enum nfp_app_id app_id;
+
+ /* Pointer to the app running on the PF */
+ void *app_priv;
/* Current values for control */
uint32_t ctrl;
@@ -151,8 +161,6 @@ struct nfp_pf_dev {
struct nfp_cpp_area *msix_area;
uint8_t *hw_queues;
- uint8_t total_phyports;
- boolmultiport;
union eth_table_entry *eth_table;
@@ -161,6 +169,20 @@ struct nfp_pf_dev {
uint32_t nfp_cpp_service_id;
};
+struct nfp_app_nic {
+ /* Backpointer to the PF device */
+ struct nfp_pf_dev *pf_dev;
+
+ /*
+* Array of physical ports belonging to the this CoreNIC app
+* This is really a list of vNIC's. One for each physical port
+*/
+ struct nfp_net_hw *ports[NFP_MAX_PHYPORTS];
+
+ bool multiport;
+ uint8_t total_phyports;
+};
+
struct nfp_net_hw {
/* Backpointer to the PF this port belongs to */
struct nfp_pf_dev *pf_dev;
@@ -424,6 +446,9 @@ int nfp_net_rss_hash_conf_get(struct rte_eth_dev *dev,
#define NFP_NET_DEV_PRIVATE_TO_PF(dev_priv)\
(((struct nfp_net_hw *)dev_priv)->pf_dev)
+#define NFP_APP_PRIV_TO_APP_NIC(app_priv)\
+ ((struct nfp_app_nic *)app_priv)
+
#endif /* _NFP_COMMON_H_ */
/*
* Local variables:
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 5cdd34e..3c4b0ac 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -39,15 +39,15 @@
#include "nfp_cpp_bridge.h"
static int
-nfp_net_pf_read_mac(struct nfp_pf_dev *pf_dev, int port)
+nfp_net_pf_read_mac(struct nfp_app_nic *app_nic, int port)
{
struct nfp_eth_table *nfp_eth_table;
struct nfp_net_hw *hw = NULL;
/* Grab a pointer to the correct physical port */
- hw = pf_dev->ports[port];
+ hw = app_nic->ports[port];
- nfp_eth_table = nfp_eth_read_ports(pf_dev->cpp);
+ nfp_eth_table = nfp_eth_read_ports(app_nic->pf_dev->cpp);
nfp_eth_copy_mac((uint8_t *)&hw->mac_addr,
(uint8_t *)&nfp_eth_table->ports[port].mac_addr);
@@ -64,6 +64,7 @@
uint32_t new_ctrl, update = 0;
struct nfp_net_hw *hw;
struct nfp_pf_dev *pf_dev;
+ struct nfp_app_nic *app_nic;
struct rte_eth_conf *dev_conf;
struct rte_eth_rxmode *rxmode;
uint32_t intr_vector;
@@ -71,6 +72,7 @@
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
pf_dev = NFP_NET_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ app_nic = NFP_APP_PRIV_TO_APP_NIC(pf_dev->app_priv);
PMD_INIT_LOG(DEBUG, "Start");
@@ -82,7 +84,7 @@
/* check and configure queue intr-vector mapping */
if (dev->data->dev_conf.intr_conf.rxq != 0) {
- if (pf_dev->multiport) {
+ if (app_nic->multiport) {
PMD_INIT_LOG(ERR, "PMD rx interrupt is not supported "
"with NFP multiport PF");
return -EINVAL;
@@ -250,6 +252,7 @@
struct nfp_net_hw *hw;
struct rte_pci_device *pci_dev;
struct nfp_pf_dev *pf_dev;
+ struct nfp_app_nic *app_nic;
int i;
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
@@ -260,6 +263,7 @@
pf_dev = NFP_NET_DEV_PRIVATE_TO_PF(dev->data->dev_private);
hw = NFP_NET_DEV_PRIVATE_TO_HW
[PATCH v4 02/12] net/nfp: simplify initialization and remove dead code
Calling nfp_net_init() is only done for the corenic firmware flavor
and it is guaranteed to always be called from the primary process,
so the explicit check for RTE_PROC_PRIMARY can be dropped.
The calling graph of nfp_net_init() already guaranteed the free of
resources when it fail, so remove the necessary free logics inside it.
While at it remove the unused member is_phyport from struct nfp_net_hw.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_common.h | 1 -
drivers/net/nfp/nfp_ethdev.c | 40 +++-
2 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/net/nfp/nfp_common.h b/drivers/net/nfp/nfp_common.h
index 2aaf1d6..b28ebc9 100644
--- a/drivers/net/nfp/nfp_common.h
+++ b/drivers/net/nfp/nfp_common.h
@@ -238,7 +238,6 @@ struct nfp_net_hw {
uint8_t idx;
/* Internal port number as seen from NFP */
uint8_t nfp_idx;
- boolis_phyport;
union eth_table_entry *eth_table;
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 3c4b0ac..2c5607c 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -417,7 +417,6 @@
uint32_t start_q;
int stride = 4;
int port = 0;
- int err;
PMD_INIT_FUNC_TRACE();
@@ -452,10 +451,6 @@
PMD_INIT_LOG(DEBUG, "Working with physical port number: %d, "
"NFP internal port number: %d", port, hw->nfp_idx);
- /* For secondary processes, the primary has done all the work */
- if (rte_eal_process_type() != RTE_PROC_PRIMARY)
- return 0;
-
rte_eth_copy_pci_info(eth_dev, pci_dev);
hw->device_id = pci_dev->id.device_id;
@@ -506,8 +501,7 @@
break;
default:
PMD_DRV_LOG(ERR, "nfp_net: no device ID matching");
- err = -ENODEV;
- goto dev_err_ctrl_map;
+ return -ENODEV;
}
PMD_INIT_LOG(DEBUG, "tx_bar_off: 0x%" PRIx64 "", tx_bar_off);
@@ -573,8 +567,7 @@
RTE_ETHER_ADDR_LEN, 0);
if (eth_dev->data->mac_addrs == NULL) {
PMD_INIT_LOG(ERR, "Failed to space for MAC address");
- err = -ENOMEM;
- goto dev_err_queues_map;
+ return -ENOMEM;
}
nfp_net_pf_read_mac(app_nic, port);
@@ -604,24 +597,15 @@
hw->mac_addr[0], hw->mac_addr[1], hw->mac_addr[2],
hw->mac_addr[3], hw->mac_addr[4], hw->mac_addr[5]);
- if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- /* Registering LSC interrupt handler */
- rte_intr_callback_register(pci_dev->intr_handle,
- nfp_net_dev_interrupt_handler, (void *)eth_dev);
- /* Telling the firmware about the LSC interrupt entry */
- nn_cfg_writeb(hw, NFP_NET_CFG_LSC, NFP_NET_IRQ_LSC_IDX);
- /* Recording current stats counters values */
- nfp_net_stats_reset(eth_dev);
- }
+ /* Registering LSC interrupt handler */
+ rte_intr_callback_register(pci_dev->intr_handle,
+ nfp_net_dev_interrupt_handler, (void *)eth_dev);
+ /* Telling the firmware about the LSC interrupt entry */
+ nn_cfg_writeb(hw, NFP_NET_CFG_LSC, NFP_NET_IRQ_LSC_IDX);
+ /* Recording current stats counters values */
+ nfp_net_stats_reset(eth_dev);
return 0;
-
-dev_err_queues_map:
- nfp_cpp_area_free(hw->hwqueues_area);
-dev_err_ctrl_map:
- nfp_cpp_area_free(hw->ctrl_area);
-
- return err;
}
#define DEFAULT_FW_PATH "/lib/firmware/netronome"
@@ -818,7 +802,6 @@
hw->eth_dev = eth_dev;
hw->idx = i;
hw->nfp_idx = nfp_eth_table->ports[i].index;
- hw->is_phyport = true;
eth_dev->device = &pf_dev->pci_dev->device;
@@ -884,8 +867,7 @@
if (cpp == NULL) {
PMD_INIT_LOG(ERR, "A CPP handle can not be obtained");
- ret = -EIO;
- goto error;
+ return -EIO;
}
hwinfo = nfp_hwinfo_read(cpp);
@@ -1005,7 +987,7 @@
free(hwinfo);
cpp_cleanup:
nfp_cpp_free(cpp);
-error:
+
return ret;
}
--
1.8.3.1
[PATCH v4 03/12] net/nfp: move app specific init logic to own function
The NFP card can load different firmware applications.
This commit move the init logic of corenic app of the
secondary process into its own function.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_ethdev.c | 93 +---
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 2c5607c..90dd01e 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -936,7 +936,7 @@
break;
default:
PMD_INIT_LOG(ERR, "nfp_net: no device ID matching");
- err = -ENODEV;
+ ret = -ENODEV;
goto pf_cleanup;
}
@@ -991,6 +991,50 @@
return ret;
}
+static int
+nfp_secondary_init_app_nic(struct rte_pci_device *pci_dev,
+ struct nfp_rtsym_table *sym_tbl,
+ struct nfp_cpp *cpp)
+{
+ int i;
+ int err = 0;
+ int ret = 0;
+ int total_vnics;
+ struct nfp_net_hw *hw;
+
+ /* Read the number of vNIC's created for the PF */
+ total_vnics = nfp_rtsym_read_le(sym_tbl, "nfd_cfg_pf0_num_ports", &err);
+ if (err || total_vnics <= 0 || total_vnics > 8) {
+ PMD_INIT_LOG(ERR, "nfd_cfg_pf0_num_ports symbol with wrong
value");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < total_vnics; i++) {
+ struct rte_eth_dev *eth_dev;
+ char port_name[RTE_ETH_NAME_MAX_LEN];
+ snprintf(port_name, sizeof(port_name), "%s_port%d",
+ pci_dev->device.name, i);
+
+ PMD_DRV_LOG(DEBUG, "Secondary attaching to port %s", port_name);
+ eth_dev = rte_eth_dev_attach_secondary(port_name);
+ if (eth_dev == NULL) {
+ RTE_LOG(ERR, EAL,
+ "secondary process attach failed, ethdev
doesn't exist");
+ ret = -ENODEV;
+ break;
+ }
+
+ eth_dev->process_private = cpp;
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ if (nfp_net_ethdev_ops_mount(hw, eth_dev))
+ return -EINVAL;
+
+ rte_eth_dev_probing_finish(eth_dev);
+ }
+
+ return ret;
+}
+
/*
* When attaching to the NFP4000/6000 PF on a secondary process there
* is no need to initialise the PF again. Only minimal work is required
@@ -999,12 +1043,10 @@
static int
nfp_pf_secondary_init(struct rte_pci_device *pci_dev)
{
- int i;
int err = 0;
int ret = 0;
- int total_ports;
+ enum nfp_app_id app_id;
struct nfp_cpp *cpp;
- struct nfp_net_hw *hw;
struct nfp_rtsym_table *sym_tbl;
if (pci_dev == NULL)
@@ -1038,37 +1080,26 @@
return -EIO;
}
- total_ports = nfp_rtsym_read_le(sym_tbl, "nfd_cfg_pf0_num_ports", &err);
- if (err || total_ports <= 0 || total_ports > 8) {
- PMD_INIT_LOG(ERR, "nfd_cfg_pf0_num_ports symbol with wrong
value");
- ret = -ENODEV;
+ /* Read the app ID of the firmware loaded */
+ app_id = nfp_rtsym_read_le(sym_tbl, "_pf0_net_app_id", &err);
+ if (err) {
+ PMD_INIT_LOG(ERR, "Couldn't read app_id from fw");
goto sym_tbl_cleanup;
}
- for (i = 0; i < total_ports; i++) {
- struct rte_eth_dev *eth_dev;
- char port_name[RTE_ETH_NAME_MAX_LEN];
-
- snprintf(port_name, sizeof(port_name), "%s_port%d",
-pci_dev->device.name, i);
-
- PMD_DRV_LOG(DEBUG, "Secondary attaching to port %s", port_name);
- eth_dev = rte_eth_dev_attach_secondary(port_name);
- if (eth_dev == NULL) {
- RTE_LOG(ERR, EAL,
- "secondary process attach failed, ethdev
doesn't exist");
- ret = -ENODEV;
- break;
+ switch (app_id) {
+ case NFP_APP_CORE_NIC:
+ PMD_INIT_LOG(INFO, "Initializing coreNIC");
+ ret = nfp_secondary_init_app_nic(pci_dev, sym_tbl, cpp);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Could not initialize coreNIC!");
+ goto sym_tbl_cleanup;
}
-
- hw = NFP_NET_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
-
- if (nfp_net_ethdev_ops_mount(hw, eth_dev))
- return -EINVAL;
-
- eth_dev->process_private = cpp;
-
- rte_eth_dev_probing_finish(eth_dev);
+ break;
+ default:
+ PMD_INIT_LOG(ERR, "Unsupported Firmware loaded");
+ ret = -EINVAL;
+ goto sym_tbl_cleanup;
}
if (ret)
--
1.8.3.1
[PATCH v4 04/12] net/nfp: add initial flower firmware support
This commits adds the basic probing infrastructure to support the flower
firmware. This firmware is geared towards offloading OVS and can
generally be found in /lib/firmware/netronome/flower. It is also used by
the NFP kernel driver when OVS offload with TC is desired.
This commit also adds the basic infrastructure needed by the flower
firmware to operate. The firmware requires threads to service both the
PF vNIC and the ctrl vNIC. The PF is responsible for handling any
fallback traffic and the ctrl vNIC is used to communicate OVS flows
and flow statistics to and from the smartNIC. rte_services are used to
facilitate this logic.
This commit also adds the cpp service, used for some user tools.
Signed-off-by: Chaoyong He
Signed-off-by: Heinrich Kuhn
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 101
drivers/net/nfp/flower/nfp_flower.h | 22
drivers/net/nfp/meson.build | 1 +
drivers/net/nfp/nfp_cpp_bridge.c| 87 ++-
drivers/net/nfp/nfp_cpp_bridge.h| 4 +-
drivers/net/nfp/nfp_ethdev.c| 40 --
6 files changed, 236 insertions(+), 19 deletions(-)
create mode 100644 drivers/net/nfp/flower/nfp_flower.c
create mode 100644 drivers/net/nfp/flower/nfp_flower.h
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
new file mode 100644
index 000..1dddced
--- /dev/null
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -0,0 +1,101 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Corigine, Inc.
+ * All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../nfp_common.h"
+#include "../nfp_logs.h"
+#include "../nfp_ctrl.h"
+#include "../nfp_cpp_bridge.h"
+#include "nfp_flower.h"
+
+static struct rte_service_spec flower_services[NFP_FLOWER_SERVICE_MAX] = {
+};
+
+static int
+nfp_flower_enable_services(struct nfp_app_flower *app_flower)
+{
+ int i;
+ int ret = 0;
+
+ for (i = 0; i < NFP_FLOWER_SERVICE_MAX; i++) {
+ /* Pass a pointer to the flower app to the service */
+ flower_services[i].callback_userdata = (void *)app_flower;
+
+ /* Register the flower services */
+ ret = rte_service_component_register(&flower_services[i],
+ &app_flower->flower_services_ids[i]);
+ if (ret) {
+ PMD_INIT_LOG(WARNING,
+ "Could not register Flower PF vNIC service");
+ break;
+ }
+
+ PMD_INIT_LOG(INFO, "Flower PF vNIC service registered");
+
+ /* Map them to available service cores*/
+ ret = nfp_map_service(app_flower->flower_services_ids[i]);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+int
+nfp_init_app_flower(struct nfp_pf_dev *pf_dev)
+{
+ int ret;
+ unsigned int numa_node;
+ struct nfp_net_hw *pf_hw;
+ struct nfp_app_flower *app_flower;
+
+ numa_node = rte_socket_id();
+
+ /* Allocate memory for the Flower app */
+ app_flower = rte_zmalloc_socket("nfp_app_flower", sizeof(*app_flower),
+ RTE_CACHE_LINE_SIZE, numa_node);
+ if (app_flower == NULL) {
+ ret = -ENOMEM;
+ goto done;
+ }
+
+ pf_dev->app_priv = app_flower;
+
+ /* Allocate memory for the PF AND ctrl vNIC here (hence the * 2) */
+ pf_hw = rte_zmalloc_socket("nfp_pf_vnic", 2 * sizeof(struct
nfp_net_adapter),
+ RTE_CACHE_LINE_SIZE, numa_node);
+ if (pf_hw == NULL) {
+ ret = -ENOMEM;
+ goto app_cleanup;
+ }
+
+ /* Start up flower services */
+ if (nfp_flower_enable_services(app_flower)) {
+ ret = -ESRCH;
+ goto vnic_cleanup;
+ }
+
+ return 0;
+
+vnic_cleanup:
+ rte_free(pf_hw);
+app_cleanup:
+ rte_free(app_flower);
+done:
+ return ret;
+}
+
+int
+nfp_secondary_init_app_flower(__rte_unused struct nfp_cpp *cpp)
+{
+ PMD_INIT_LOG(ERR, "Flower firmware not supported");
+ return -ENOTSUP;
+}
diff --git a/drivers/net/nfp/flower/nfp_flower.h
b/drivers/net/nfp/flower/nfp_flower.h
new file mode 100644
index 000..4a9b302
--- /dev/null
+++ b/drivers/net/nfp/flower/nfp_flower.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2022 Corigine, Inc.
+ * All rights reserved.
+ */
+
+#ifndef _NFP_FLOWER_H_
+#define _NFP_FLOWER_H_
+
+enum nfp_flower_service {
+ NFP_FLOWER_SERVICE_MAX
+};
+
+/* The flower application's private structure */
+struct nfp_app_flower {
+ /* List of rte_service ID's for the flower app */
+ uint32_t flower_services_ids[NFP_FLOWER_SERVICE_MAX];
+};
+
+int nfp_init_app_flower(struct nfp_pf_dev *pf_dev);
+int nfp_secondary_init_app_
[PATCH v4 05/12] net/nfp: add flower PF setup and mempool init logic
This commit adds the vNIC initialization logic for the flower PF vNIC.
The flower firmware exposes this vNIC for the purposes of fallback
traffic in the switchdev use-case. The logic of setting up this vNIC is
similar to the logic seen in nfp_net_init() and nfp_net_start().
This commit also adds minimal dev_ops for this PF device. Because the
device is being exposed externally to DPDK it should also be configured
using DPDK helpers like rte_eth_configure(). For these helpers to work
the flower logic needs to implements a minimal set of dev_ops. The Rx
and Tx logic for this vNIC will be added in a subsequent commit.
OVS expects incoming packets coming into the OVS datapath to be
allocated from a mempool that contains objects of type "struct
dp_packet". For the PF handling the slowpath into OVS it should
use a mempool that is compatible with OVS. This commit adds the logic
to create the OVS compatible mempool. It adds certain OVS specific
structs to be able to instantiate the mempool.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c| 390 -
drivers/net/nfp/flower/nfp_flower.h| 9 +
drivers/net/nfp/flower/nfp_flower_ovs_compat.h | 145 +
drivers/net/nfp/nfp_common.h | 3 +
4 files changed, 543 insertions(+), 4 deletions(-)
create mode 100644 drivers/net/nfp/flower/nfp_flower_ovs_compat.h
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 1dddced..0a0b1db 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -14,7 +14,35 @@
#include "../nfp_logs.h"
#include "../nfp_ctrl.h"
#include "../nfp_cpp_bridge.h"
+#include "../nfp_rxtx.h"
+#include "../nfpcore/nfp_mip.h"
+#include "../nfpcore/nfp_rtsym.h"
+#include "../nfpcore/nfp_nsp.h"
#include "nfp_flower.h"
+#include "nfp_flower_ovs_compat.h"
+
+#define MAX_PKT_BURST 32
+#define MEMPOOL_CACHE_SIZE 512
+#define DEFAULT_FLBUF_SIZE 9216
+
+/*
+ * Simple dev ops functions for the flower PF. Because a rte_device is exposed
+ * to DPDK the flower logic also makes use of helper functions like
+ * rte_dev_configure() to set up the PF device. Stub functions are needed to
+ * use these helper functions
+ */
+static int
+nfp_flower_pf_configure(__rte_unused struct rte_eth_dev *dev)
+{
+ return 0;
+}
+
+static const struct eth_dev_ops nfp_flower_pf_dev_ops = {
+ .dev_configure = nfp_flower_pf_configure,
+
+ /* Use the normal dev_infos_get functionality in the NFP PMD */
+ .dev_infos_get = nfp_net_infos_get,
+};
static struct rte_service_spec flower_services[NFP_FLOWER_SERVICE_MAX] = {
};
@@ -49,6 +77,310 @@
return ret;
}
+static void
+nfp_flower_pf_mp_init(__rte_unused struct rte_mempool *mp,
+ __rte_unused void *opaque_arg,
+ void *_p,
+ __rte_unused unsigned int i)
+{
+ struct dp_packet *pkt = _p;
+ pkt->source = DPBUF_DPDK;
+ pkt->l2_pad_size = 0;
+ pkt->l2_5_ofs= UINT16_MAX;
+ pkt->l3_ofs = UINT16_MAX;
+ pkt->l4_ofs = UINT16_MAX;
+ pkt->packet_type = 0; /* PT_ETH */
+}
+
+static struct rte_mempool *
+nfp_flower_pf_mp_create(void)
+{
+ uint32_t nb_mbufs;
+ uint32_t pkt_size;
+ uint32_t n_rxd = 1024;
+ uint32_t n_txd = 1024;
+ unsigned int numa_node;
+ uint32_t aligned_mbuf_size;
+ uint32_t mbuf_priv_data_len;
+ struct rte_mempool *pktmbuf_pool;
+
+ nb_mbufs = RTE_MAX(n_rxd + n_txd + MAX_PKT_BURST + MEMPOOL_CACHE_SIZE,
+ 81920U);
+
+ /*
+* The size of the mbuf's private area (i.e. area that holds OvS'
+* dp_packet data)
+*/
+ mbuf_priv_data_len = sizeof(struct dp_packet) - sizeof(struct rte_mbuf);
+ /* The size of the entire dp_packet. */
+ pkt_size = sizeof(struct dp_packet) + RTE_MBUF_DEFAULT_BUF_SIZE;
+ /* mbuf size, rounded up to cacheline size. */
+ aligned_mbuf_size = ROUND_UP(pkt_size, RTE_CACHE_LINE_SIZE);
+ mbuf_priv_data_len += (aligned_mbuf_size - pkt_size);
+
+ numa_node = rte_socket_id();
+ pktmbuf_pool = rte_pktmbuf_pool_create("flower_pf_mbuf_pool", nb_mbufs,
+ MEMPOOL_CACHE_SIZE, mbuf_priv_data_len,
+ RTE_MBUF_DEFAULT_BUF_SIZE, numa_node);
+ if (pktmbuf_pool == NULL) {
+ RTE_LOG(ERR, PMD, "Cannot init mbuf pool\n");
+ return NULL;
+ }
+
+ rte_mempool_obj_iter(pktmbuf_pool, nfp_flower_pf_mp_init, NULL);
+
+ return pktmbuf_pool;
+}
+
+static void
+nfp_flower_cleanup_pf_vnic(struct nfp_net_hw *hw)
+{
+ uint16_t i;
+ struct rte_eth_dev *eth_dev;
+ struct nfp_app_flower *app_flower;
+
+ eth_dev = hw->eth_dev;
+ app_flower = NFP_APP_PRIV_TO_APP_FLOWER(hw->pf_dev->app_priv);
+
+ for (i = 0; i < et
[PATCH v4 06/12] net/nfp: add flower PF related routines
This commit adds the start/stop/close routine of the
flower PF vNIC.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 193
1 file changed, 193 insertions(+)
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 0a0b1db..417155e 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -37,11 +38,178 @@
return 0;
}
+static int
+nfp_flower_pf_start(struct rte_eth_dev *dev)
+{
+ int ret;
+ uint32_t new_ctrl;
+ uint32_t update = 0;
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /* Disabling queues just in case... */
+ nfp_net_disable_queues(dev);
+
+ /* Enabling the required queues in the device */
+ nfp_net_enable_queues(dev);
+
+ new_ctrl = nfp_check_offloads(dev);
+
+ /* Writing configuration parameters in the device */
+ nfp_net_params_setup(hw);
+
+ nfp_net_rss_config_default(dev);
+ update |= NFP_NET_CFG_UPDATE_RSS;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_RSS2)
+ new_ctrl |= NFP_NET_CFG_CTRL_RSS2;
+ else
+ new_ctrl |= NFP_NET_CFG_CTRL_RSS;
+
+ /* Enable device */
+ new_ctrl |= NFP_NET_CFG_CTRL_ENABLE;
+
+ update |= NFP_NET_CFG_UPDATE_GEN | NFP_NET_CFG_UPDATE_RING;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_RINGCFG)
+ new_ctrl |= NFP_NET_CFG_CTRL_RINGCFG;
+
+ nn_cfg_writel(hw, NFP_NET_CFG_CTRL, new_ctrl);
+
+ /* If an error when reconfig we avoid to change hw state */
+ ret = nfp_net_reconfig(hw, new_ctrl, update);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Failed to reconfig PF vnic");
+ return -EIO;
+ }
+
+ hw->ctrl = new_ctrl;
+
+ /* Setup the freelist ring */
+ ret = nfp_net_rx_freelist_setup(dev);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Error with flower PF vNIC freelist setup");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+/* Stop device: disable rx and tx functions to allow for reconfiguring. */
+static int
+nfp_flower_pf_stop(struct rte_eth_dev *dev)
+{
+ uint16_t i;
+ struct nfp_net_hw *hw;
+ struct nfp_net_txq *this_tx_q;
+ struct nfp_net_rxq *this_rx_q;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ nfp_net_disable_queues(dev);
+
+ /* Clear queues */
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ this_tx_q = (struct nfp_net_txq *)dev->data->tx_queues[i];
+ nfp_net_reset_tx_queue(this_tx_q);
+ }
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ this_rx_q = (struct nfp_net_rxq *)dev->data->rx_queues[i];
+ nfp_net_reset_rx_queue(this_rx_q);
+ }
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ /* Configure the physical port down */
+ nfp_eth_set_configured(hw->cpp, hw->nfp_idx, 0);
+ else
+ nfp_eth_set_configured(dev->process_private, hw->nfp_idx, 0);
+
+ return 0;
+}
+
+/* Reset and stop device. The device can not be restarted. */
+static int
+nfp_flower_pf_close(struct rte_eth_dev *dev)
+{
+ uint16_t i;
+ struct nfp_net_hw *hw;
+ struct nfp_pf_dev *pf_dev;
+ struct nfp_net_txq *this_tx_q;
+ struct nfp_net_rxq *this_rx_q;
+ struct rte_pci_device *pci_dev;
+ struct nfp_app_flower *app_flower;
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
+ pf_dev = NFP_NET_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ pci_dev = RTE_ETH_DEV_TO_PCI(dev);
+ app_flower = NFP_APP_PRIV_TO_APP_FLOWER(pf_dev->app_priv);
+
+ /*
+* We assume that the DPDK application is stopping all the
+* threads/queues before calling the device close function.
+*/
+
+ nfp_net_disable_queues(dev);
+
+ /* Clear queues */
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ this_tx_q = (struct nfp_net_txq *)dev->data->tx_queues[i];
+ nfp_net_reset_tx_queue(this_tx_q);
+ }
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ this_rx_q = (struct nfp_net_rxq *)dev->data->rx_queues[i];
+ nfp_net_reset_rx_queue(this_rx_q);
+ }
+
+ /* Cancel possible impending LSC work here before releasing the port*/
+ rte_eal_alarm_cancel(nfp_net_dev_interrupt_delayed_handler, (void
*)dev);
+
+ nn_cfg_writeb(hw, NFP_NET_CFG_LSC, 0xff);
+
+ rte_eth_dev_release_port(dev);
+
+ /* Now it is safe to free all PF resources */
+ PMD_INIT_LOG(INFO, "Freeing PF resources");
+ nfp_cpp_area_free(pf_d
[PATCH v4 07/12] net/nfp: add flower ctrl VNIC related logics
This commit adds the setup/start logic for the ctrl vNIC. This vNIC
is used by the PMD and flower firmware as a communication channel
between driver and firmware. In the case of OVS it is also used to
communicate flow statistics from hardware to the driver.
A rte_eth device is not exposed to DPDK for this vNIC as it is strictly
used internally by flower logic. Rx and Tx logic will be added later for
this vNIC.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 391 +++-
drivers/net/nfp/flower/nfp_flower.h | 6 +
2 files changed, 394 insertions(+), 3 deletions(-)
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 417155e..6cdec87 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -26,6 +26,10 @@
#define MEMPOOL_CACHE_SIZE 512
#define DEFAULT_FLBUF_SIZE 9216
+#define CTRL_VNIC_NB_DESC 64
+#define CTRL_VNIC_RX_FREE_THRESH 32
+#define CTRL_VNIC_TX_FREE_THRESH 32
+
/*
* Simple dev ops functions for the flower PF. Because a rte_device is exposed
* to DPDK the flower logic also makes use of helper functions like
@@ -549,6 +553,308 @@
return ret;
}
+static void
+nfp_flower_cleanup_ctrl_vnic(struct nfp_net_hw *hw)
+{
+ uint32_t i;
+ struct nfp_net_rxq *rxq;
+ struct nfp_net_txq *txq;
+ struct rte_eth_dev *eth_dev;
+
+ eth_dev = hw->eth_dev;
+
+ for (i = 0; i < hw->max_tx_queues; i++) {
+ txq = eth_dev->data->tx_queues[i];
+ if (txq) {
+ rte_free(txq->txbufs);
+ rte_eth_dma_zone_free(eth_dev, "ctrl_tx_ring", i);
+ rte_free(txq);
+ }
+ }
+
+ for (i = 0; i < hw->max_rx_queues; i++) {
+ rxq = eth_dev->data->rx_queues[i];
+ if (rxq) {
+ rte_free(rxq->rxbufs);
+ rte_eth_dma_zone_free(eth_dev, "ctrl_rx_ring", i);
+ rte_free(rxq);
+ }
+ }
+
+ rte_free(eth_dev->data->tx_queues);
+ rte_free(eth_dev->data->rx_queues);
+ rte_free(eth_dev->data);
+ rte_free(eth_dev);
+}
+
+static int
+nfp_flower_init_ctrl_vnic(struct nfp_net_hw *hw)
+{
+ uint32_t i;
+ int ret = 0;
+ uint16_t nb_desc;
+ unsigned int numa_node;
+ struct rte_mempool *mp;
+ uint16_t rx_free_thresh;
+ uint16_t tx_free_thresh;
+ struct nfp_net_rxq *rxq;
+ struct nfp_net_txq *txq;
+ struct nfp_pf_dev *pf_dev;
+ struct rte_eth_dev *eth_dev;
+ const struct rte_memzone *tz;
+ struct nfp_app_flower *app_flower;
+
+ /* Hardcoded values for now */
+ nb_desc = CTRL_VNIC_NB_DESC;
+ rx_free_thresh = CTRL_VNIC_RX_FREE_THRESH;
+ tx_free_thresh = CTRL_VNIC_TX_FREE_THRESH;
+ numa_node = rte_socket_id();
+
+ /* Set up some pointers here for ease of use */
+ pf_dev = hw->pf_dev;
+ app_flower = NFP_APP_PRIV_TO_APP_FLOWER(pf_dev->app_priv);
+
+ ret = nfp_flower_init_vnic_common(hw, "ctrl_vnic");
+ if (ret)
+ goto done;
+
+ /* Allocate memory for the eth_dev of the vNIC */
+ hw->eth_dev = rte_zmalloc("ctrl_vnic_eth_dev",
+ sizeof(struct rte_eth_dev), RTE_CACHE_LINE_SIZE);
+ if (hw->eth_dev == NULL) {
+ ret = -ENOMEM;
+ goto done;
+ }
+
+ /* Grab the pointer to the newly created rte_eth_dev here */
+ eth_dev = hw->eth_dev;
+
+ /* Also allocate memory for the data part of the eth_dev */
+ eth_dev->data = rte_zmalloc("ctrl_vnic_eth_dev_data",
+ sizeof(struct rte_eth_dev_data), RTE_CACHE_LINE_SIZE);
+ if (eth_dev->data == NULL) {
+ ret = -ENOMEM;
+ goto eth_dev_cleanup;
+ }
+
+ eth_dev->data->rx_queues = rte_zmalloc("ethdev->rx_queues",
+ sizeof(eth_dev->data->rx_queues[0]) * hw->max_rx_queues,
+ RTE_CACHE_LINE_SIZE);
+ if (eth_dev->data->rx_queues == NULL) {
+ PMD_INIT_LOG(ERR, "rte_zmalloc failed for ctrl vnic rx queues");
+ ret = -ENOMEM;
+ goto dev_data_cleanup;
+ }
+
+ eth_dev->data->tx_queues = rte_zmalloc("ethdev->tx_queues",
+ sizeof(eth_dev->data->tx_queues[0]) * hw->max_tx_queues,
+ RTE_CACHE_LINE_SIZE);
+ if (eth_dev->data->tx_queues == NULL) {
+ PMD_INIT_LOG(ERR, "rte_zmalloc failed for ctrl vnic tx queues");
+ ret = -ENOMEM;
+ goto rx_queue_cleanup;
+ }
+
+ eth_dev->device = &pf_dev->pci_dev->device;
+ eth_dev->data->nb_tx_queues = hw->max_tx_queues;
+ eth_dev->data->nb_rx_queues = hw->max_rx_queues;
+ eth_dev->data->dev_private = hw;
+
+ /* Create a mbuf pool for the vNIC */
+ app_flower->ctrl_pktmb
[PATCH v4 08/12] net/nfp: move common rxtx function for flower use
This commit move some common Rx and Tx logic to the rxtx header file so
that they can be re-used by flower tx and rx logic.
Signed-off-by: Chaoyong He
Signed-off-by: Heinrich Kuhn
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_rxtx.c | 32 +---
drivers/net/nfp/nfp_rxtx.h | 31 +++
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/net/nfp/nfp_rxtx.c b/drivers/net/nfp/nfp_rxtx.c
index 7414c51..cdcf5c2 100644
--- a/drivers/net/nfp/nfp_rxtx.c
+++ b/drivers/net/nfp/nfp_rxtx.c
@@ -116,12 +116,6 @@
return count;
}
-static inline void
-nfp_net_mbuf_alloc_failed(struct nfp_net_rxq *rxq)
-{
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed++;
-}
-
/*
* nfp_net_set_hash - Set mbuf hash data
*
@@ -583,7 +577,7 @@
* @txq: TX queue to work with
* Returns number of descriptors freed
*/
-static int
+int
nfp_net_tx_free_bufs(struct nfp_net_txq *txq)
{
uint32_t qcp_rd_p;
@@ -774,30 +768,6 @@
return 0;
}
-/* Leaving always free descriptors for avoiding wrapping confusion */
-static inline
-uint32_t nfp_net_nfd3_free_tx_desc(struct nfp_net_txq *txq)
-{
- if (txq->wr_p >= txq->rd_p)
- return txq->tx_count - (txq->wr_p - txq->rd_p) - 8;
- else
- return txq->rd_p - txq->wr_p - 8;
-}
-
-/*
- * nfp_net_txq_full - Check if the TX queue free descriptors
- * is below tx_free_threshold
- *
- * @txq: TX queue to check
- *
- * This function uses the host copy* of read/write pointers
- */
-static inline
-uint32_t nfp_net_nfd3_txq_full(struct nfp_net_txq *txq)
-{
- return (nfp_net_nfd3_free_tx_desc(txq) < txq->tx_free_thresh);
-}
-
/* nfp_net_tx_tso - Set TX descriptor for TSO */
static inline void
nfp_net_nfd3_tx_tso(struct nfp_net_txq *txq, struct nfp_net_nfd3_tx_desc *txd,
diff --git a/drivers/net/nfp/nfp_rxtx.h b/drivers/net/nfp/nfp_rxtx.h
index 5c005d7..a30171f 100644
--- a/drivers/net/nfp/nfp_rxtx.h
+++ b/drivers/net/nfp/nfp_rxtx.h
@@ -330,6 +330,36 @@ struct nfp_net_rxq {
int rx_qcidx;
} __rte_aligned(64);
+static inline void
+nfp_net_mbuf_alloc_failed(struct nfp_net_rxq *rxq)
+{
+ rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed++;
+}
+
+/* Leaving always free descriptors for avoiding wrapping confusion */
+static inline uint32_t
+nfp_net_nfd3_free_tx_desc(struct nfp_net_txq *txq)
+{
+ if (txq->wr_p >= txq->rd_p)
+ return txq->tx_count - (txq->wr_p - txq->rd_p) - 8;
+ else
+ return txq->rd_p - txq->wr_p - 8;
+}
+
+/*
+ * nfp_net_nfd3_txq_full - Check if the TX queue free descriptors
+ * is below tx_free_threshold
+ *
+ * @txq: TX queue to check
+ *
+ * This function uses the host copy* of read/write pointers
+ */
+static inline uint32_t
+nfp_net_nfd3_txq_full(struct nfp_net_txq *txq)
+{
+ return (nfp_net_nfd3_free_tx_desc(txq) < txq->tx_free_thresh);
+}
+
int nfp_net_rx_freelist_setup(struct rte_eth_dev *dev);
uint32_t nfp_net_rx_queue_count(void *rx_queue);
uint16_t nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -355,6 +385,7 @@ int nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t nfp_net_nfdk_xmit_pkts(void *tx_queue,
struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
+int nfp_net_tx_free_bufs(struct nfp_net_txq *txq);
#endif /* _NFP_RXTX_H_ */
/*
--
1.8.3.1
[PATCH v4 09/12] net/nfp: add flower ctrl VNIC rxtx logic
Add a Rx and Tx function for the control vNIC. The logic is mostly
identical to the normal Rx and Tx functionality of the NFP PMD.
This commit also makes use of the ctrl vNIC service logic to
service the ctrl vNIC Rx path.
Signed-off-by: Chaoyong He
Signed-off-by: Heinrich Kuhn
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 15 ++
drivers/net/nfp/flower/nfp_flower.h | 15 ++
drivers/net/nfp/flower/nfp_flower_ctrl.c | 248 +++
drivers/net/nfp/flower/nfp_flower_ctrl.h | 13 ++
drivers/net/nfp/meson.build | 1 +
5 files changed, 292 insertions(+)
create mode 100644 drivers/net/nfp/flower/nfp_flower_ctrl.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_ctrl.h
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 6cdec87..cdaa89a 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -21,6 +21,7 @@
#include "../nfpcore/nfp_nsp.h"
#include "nfp_flower.h"
#include "nfp_flower_ovs_compat.h"
+#include "nfp_flower_ctrl.h"
#define MAX_PKT_BURST 32
#define MEMPOOL_CACHE_SIZE 512
@@ -216,7 +217,21 @@
.link_update= nfp_flower_pf_link_update,
};
+static int
+nfp_flower_ctrl_vnic_service(void *arg)
+{
+ struct nfp_app_flower *app_flower = arg;
+
+ nfp_flower_ctrl_vnic_poll(app_flower);
+
+ return 0;
+}
+
static struct rte_service_spec flower_services[NFP_FLOWER_SERVICE_MAX] = {
+ [NFP_FLOWER_SERVICE_CTRL] = {
+ .name = "flower_ctrl_vnic_service",
+ .callback = nfp_flower_ctrl_vnic_service,
+ },
};
static int
diff --git a/drivers/net/nfp/flower/nfp_flower.h
b/drivers/net/nfp/flower/nfp_flower.h
index f11ef6d..bdc64e3 100644
--- a/drivers/net/nfp/flower/nfp_flower.h
+++ b/drivers/net/nfp/flower/nfp_flower.h
@@ -7,9 +7,18 @@
#define _NFP_FLOWER_H_
enum nfp_flower_service {
+ NFP_FLOWER_SERVICE_CTRL,
NFP_FLOWER_SERVICE_MAX
};
+/*
+ * Flower fallback and ctrl path always adds and removes
+ * 8 bytes of prepended data. Tx descriptors must point
+ * to the correct packet data offset after metadata has
+ * been added
+ */
+#define FLOWER_PKT_DATA_OFFSET 8
+
/* The flower application's private structure */
struct nfp_app_flower {
/* List of rte_service ID's for the flower app */
@@ -29,6 +38,12 @@ struct nfp_app_flower {
/* the eth table as reported by firmware */
struct nfp_eth_table *nfp_eth_table;
+
+ /* Ctrl vNIC Rx counter */
+ uint64_t ctrl_vnic_rx_count;
+
+ /* Ctrl vNIC Tx counter */
+ uint64_t ctrl_vnic_tx_count;
};
int nfp_init_app_flower(struct nfp_pf_dev *pf_dev);
diff --git a/drivers/net/nfp/flower/nfp_flower_ctrl.c
b/drivers/net/nfp/flower/nfp_flower_ctrl.c
new file mode 100644
index 000..100e808
--- /dev/null
+++ b/drivers/net/nfp/flower/nfp_flower_ctrl.c
@@ -0,0 +1,248 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2022 Corigine, Inc.
+ * All rights reserved.
+ */
+
+#include
+#include
+
+#include "../nfp_common.h"
+#include "../nfp_logs.h"
+#include "../nfp_ctrl.h"
+#include "../nfp_rxtx.h"
+#include "nfp_flower.h"
+#include "nfp_flower_ctrl.h"
+
+#define MAX_PKT_BURST 32
+
+static uint16_t
+nfp_flower_ctrl_vnic_recv(void *rx_queue,
+ struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ struct nfp_net_rxq *rxq;
+ struct nfp_net_rx_desc *rxds;
+ struct nfp_net_rx_buff *rxb;
+ struct nfp_net_hw *hw;
+ struct rte_mbuf *mb;
+ struct rte_mbuf *new_mb;
+ uint64_t dma_addr;
+ uint16_t avail = 0;
+ uint16_t nb_hold = 0;
+
+ rxq = rx_queue;
+ if (unlikely(rxq == NULL)) {
+ /*
+* DPDK just checks the queue is lower than max queues
+* enabled. But the queue needs to be configured
+*/
+ PMD_RX_LOG(ERR, "RX Bad queue");
+ return -EINVAL;
+ }
+
+ hw = rxq->hw;
+ while (avail < nb_pkts) {
+ rxb = &rxq->rxbufs[rxq->rd_p];
+ if (unlikely(rxb == NULL)) {
+ PMD_RX_LOG(ERR, "rxb does not exist!");
+ break;
+ }
+
+ rxds = &rxq->rxds[rxq->rd_p];
+ if ((rxds->rxd.meta_len_dd & PCIE_DESC_RX_DD) == 0)
+ break;
+
+ /*
+* Memory barrier to ensure that we won't do other
+* reads before the DD bit.
+*/
+ rte_rmb();
+
+ /*
+* We got a packet. Let's alloc a new mbuf for refilling the
+* free descriptor ring as soon as possible
+*/
+ new_mb = rte_pktmbuf_alloc(rxq->mem_pool);
+ if (unlikely(new_mb == NULL)) {
+ PMD_RX_LOG(ERR,
+ "RX mb
[PATCH v4 10/12] net/nfp: add flower representor framework
This commit adds the framework to support flower representors.
The number of VF representors are parsed from the command line. For
physical port representors the current logic aims to create a
representor for each physical port present on the hardware.
A eth_dev is created for each phyport and VF, and flower firmware
requires a MAC repr cmsg to be transmitted to firmware with
info about the number of physical ports configured.
Reify messages are sent to hardware for each phyport representor.
A rte_ring is also created per representor so that traffic can be
pushed and pulled to this interface.
To up and down the real device represented by a flower representor port
a port mod message is used to convey that info to the firmware. This
message will be used in the dev_ops callbacks of flower representors.
Each cmsg generated by the driver is prepended with a cmsg header.
This commit also adds the logic to fill in the header of cmsgs.
This commit also adds the Rx and Tx path for flower representors. For
Rx packets are dequeued from the representor ring and passed to the
eth_dev. For Tx the first queue of the PF vNIC is used. Metadata about
the representor is added before the packet is sent down to firmware.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 59 +++
drivers/net/nfp/flower/nfp_flower.h | 18 +
drivers/net/nfp/flower/nfp_flower_cmsg.c| 165
drivers/net/nfp/flower/nfp_flower_cmsg.h| 173
drivers/net/nfp/flower/nfp_flower_representor.c | 508
drivers/net/nfp/flower/nfp_flower_representor.h | 39 ++
drivers/net/nfp/meson.build | 2 +
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 31 +-
8 files changed, 983 insertions(+), 12 deletions(-)
create mode 100644 drivers/net/nfp/flower/nfp_flower_cmsg.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_cmsg.h
create mode 100644 drivers/net/nfp/flower/nfp_flower_representor.c
create mode 100644 drivers/net/nfp/flower/nfp_flower_representor.h
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index cdaa89a..7034d45 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -22,6 +22,7 @@
#include "nfp_flower.h"
#include "nfp_flower_ovs_compat.h"
#include "nfp_flower_ctrl.h"
+#include "nfp_flower_representor.h"
#define MAX_PKT_BURST 32
#define MEMPOOL_CACHE_SIZE 512
@@ -939,8 +940,13 @@
unsigned int numa_node;
struct nfp_net_hw *pf_hw;
struct nfp_net_hw *ctrl_hw;
+ struct rte_pci_device *pci_dev;
struct nfp_app_flower *app_flower;
+ struct rte_eth_devargs eth_da = {
+ .nb_representor_ports = 0
+ };
+ pci_dev = pf_dev->pci_dev;
numa_node = rte_socket_id();
/* Allocate memory for the Flower app */
@@ -1033,6 +1039,59 @@
goto ctrl_vnic_cleanup;
}
+ /* Allocate a switch domain for the flower app */
+ if (app_flower->switch_domain_id ==
RTE_ETH_DEV_SWITCH_DOMAIN_ID_INVALID &&
+
rte_eth_switch_domain_alloc(&app_flower->switch_domain_id)) {
+ PMD_INIT_LOG(WARNING,
+ "failed to allocate switch domain for device");
+ }
+
+ /* Now parse PCI device args passed for representor info */
+ if (pci_dev->device.devargs) {
+ ret = rte_eth_devargs_parse(pci_dev->device.devargs->args,
+ ð_da);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "devarg parse failed");
+ goto ctrl_vnic_cleanup;
+ }
+ }
+
+ if (eth_da.nb_representor_ports == 0) {
+ PMD_INIT_LOG(DEBUG, "No representor port need to create.");
+ ret = 0;
+ goto done;
+ }
+
+ /* There always exist phy repr */
+ if (eth_da.nb_representor_ports < app_flower->nfp_eth_table->count) {
+ PMD_INIT_LOG(DEBUG, "Should also create phy representor port.");
+ ret = -ERANGE;
+ goto ctrl_vnic_cleanup;
+ }
+
+ /* Only support VF representor creation via the command line */
+ if (eth_da.type != RTE_ETH_REPRESENTOR_VF) {
+ PMD_DRV_LOG(ERR, "unsupported representor type: %s\n",
+ pci_dev->device.devargs->args);
+ ret = -ENOTSUP;
+ goto ctrl_vnic_cleanup;
+ }
+
+ /* Fill in flower app with repr counts */
+ app_flower->num_phyport_reprs =
(uint8_t)app_flower->nfp_eth_table->count;
+ app_flower->num_vf_reprs = eth_da.nb_representor_ports -
+ app_flower->nfp_eth_table->count;
+
+ PMD_INIT_LOG(INFO, "%d number of VF reprs", app_flower->num_vf_reprs);
+ PMD_INIT_LOG(INFO, "%d number of phyport reprs",
app_flower->num_phyport_repr
[PATCH v4 11/12] net/nfp: move rxtx function to header file
Flower makes use of the same Rx and Tx checksum logic as the normal PMD.
Expose it so that flower can make use of it.
Signed-off-by: Chaoyong He
Signed-off-by: Heinrich Kuhn
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/nfp_common.c| 2 +-
drivers/net/nfp/nfp_ethdev.c| 2 +-
drivers/net/nfp/nfp_ethdev_vf.c | 2 +-
drivers/net/nfp/nfp_rxtx.c | 91 +
drivers/net/nfp/nfp_rxtx.h | 90
5 files changed, 94 insertions(+), 93 deletions(-)
diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index 0e55f0c..e86929c 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -38,9 +38,9 @@
#include "nfpcore/nfp_nsp.h"
#include "nfp_common.h"
+#include "nfp_ctrl.h"
#include "nfp_rxtx.h"
#include "nfp_logs.h"
-#include "nfp_ctrl.h"
#include "nfp_cpp_bridge.h"
#include
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index 4ab89db..a647f66 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -33,9 +33,9 @@
#include "nfpcore/nfp_nsp.h"
#include "nfp_common.h"
+#include "nfp_ctrl.h"
#include "nfp_rxtx.h"
#include "nfp_logs.h"
-#include "nfp_ctrl.h"
#include "nfp_cpp_bridge.h"
#include "flower/nfp_flower.h"
diff --git a/drivers/net/nfp/nfp_ethdev_vf.c b/drivers/net/nfp/nfp_ethdev_vf.c
index d304d78..ceaf618 100644
--- a/drivers/net/nfp/nfp_ethdev_vf.c
+++ b/drivers/net/nfp/nfp_ethdev_vf.c
@@ -19,9 +19,9 @@
#include "nfpcore/nfp_rtsym.h"
#include "nfp_common.h"
+#include "nfp_ctrl.h"
#include "nfp_rxtx.h"
#include "nfp_logs.h"
-#include "nfp_ctrl.h"
static void
nfp_netvf_read_mac(struct nfp_net_hw *hw)
diff --git a/drivers/net/nfp/nfp_rxtx.c b/drivers/net/nfp/nfp_rxtx.c
index cdcf5c2..7a6757c 100644
--- a/drivers/net/nfp/nfp_rxtx.c
+++ b/drivers/net/nfp/nfp_rxtx.c
@@ -17,9 +17,9 @@
#include
#include "nfp_common.h"
+#include "nfp_ctrl.h"
#include "nfp_rxtx.h"
#include "nfp_logs.h"
-#include "nfp_ctrl.h"
#include "nfpcore/nfp_mip.h"
#include "nfpcore/nfp_rtsym.h"
#include "nfpcore/nfp-common/nfp_platform.h"
@@ -208,34 +208,6 @@
}
}
-/* nfp_net_rx_cksum - set mbuf checksum flags based on RX descriptor flags */
-static inline void
-nfp_net_rx_cksum(struct nfp_net_rxq *rxq, struct nfp_net_rx_desc *rxd,
-struct rte_mbuf *mb)
-{
- struct nfp_net_hw *hw = rxq->hw;
-
- if (!(hw->ctrl & NFP_NET_CFG_CTRL_RXCSUM))
- return;
-
- /* If IPv4 and IP checksum error, fail */
- if (unlikely((rxd->rxd.flags & PCIE_DESC_RX_IP4_CSUM) &&
- !(rxd->rxd.flags & PCIE_DESC_RX_IP4_CSUM_OK)))
- mb->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_BAD;
- else
- mb->ol_flags |= RTE_MBUF_F_RX_IP_CKSUM_GOOD;
-
- /* If neither UDP nor TCP return */
- if (!(rxd->rxd.flags & PCIE_DESC_RX_TCP_CSUM) &&
- !(rxd->rxd.flags & PCIE_DESC_RX_UDP_CSUM))
- return;
-
- if (likely(rxd->rxd.flags & PCIE_DESC_RX_L4_CSUM_OK))
- mb->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
- else
- mb->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_BAD;
-}
-
/*
* RX path design:
*
@@ -768,67 +740,6 @@
return 0;
}
-/* nfp_net_tx_tso - Set TX descriptor for TSO */
-static inline void
-nfp_net_nfd3_tx_tso(struct nfp_net_txq *txq, struct nfp_net_nfd3_tx_desc *txd,
- struct rte_mbuf *mb)
-{
- uint64_t ol_flags;
- struct nfp_net_hw *hw = txq->hw;
-
- if (!(hw->cap & NFP_NET_CFG_CTRL_LSO_ANY))
- goto clean_txd;
-
- ol_flags = mb->ol_flags;
-
- if (!(ol_flags & RTE_MBUF_F_TX_TCP_SEG))
- goto clean_txd;
-
- txd->l3_offset = mb->l2_len;
- txd->l4_offset = mb->l2_len + mb->l3_len;
- txd->lso_hdrlen = mb->l2_len + mb->l3_len + mb->l4_len;
- txd->mss = rte_cpu_to_le_16(mb->tso_segsz);
- txd->flags = PCIE_DESC_TX_LSO;
- return;
-
-clean_txd:
- txd->flags = 0;
- txd->l3_offset = 0;
- txd->l4_offset = 0;
- txd->lso_hdrlen = 0;
- txd->mss = 0;
-}
-
-/* nfp_net_tx_cksum - Set TX CSUM offload flags in TX descriptor */
-static inline void
-nfp_net_nfd3_tx_cksum(struct nfp_net_txq *txq, struct nfp_net_nfd3_tx_desc
*txd,
-struct rte_mbuf *mb)
-{
- uint64_t ol_flags;
- struct nfp_net_hw *hw = txq->hw;
-
- if (!(hw->cap & NFP_NET_CFG_CTRL_TXCSUM))
- return;
-
- ol_flags = mb->ol_flags;
-
- /* IPv6 does not need checksum */
- if (ol_flags & RTE_MBUF_F_TX_IP_CKSUM)
- txd->flags |= PCIE_DESC_TX_IP4_CSUM;
-
- switch (ol_flags & RTE_MBUF_F_TX_L4_MASK) {
- case RTE_MBUF_F_TX_UDP_CKSUM:
- txd->flags |= PCIE_DESC_TX_UDP_CSUM;
- break;
- case RTE_MBUF_F_TX_TCP_CKSUM:
- txd->flags |= PCIE_DESC_TX_TCP_CSUM;
- break;
- }
-
-
[PATCH v4 12/12] net/nfp: add flower PF rxtx logic
This commit implements the flower Rx logic. Fallback packets are
multiplexed to the correct representor port based on the prepended
metadata. The Rx poll is set to run on the existing service
infrastructure.
For Tx the existing NFP Tx logic is duplicated to keep the Tx two paths
distinct. Flower fallback also adds 8 bytes of metadata to the start of
the packet that has to be adjusted for in the Tx descriptor.
Signed-off-by: Chaoyong He
Reviewed-by: Niklas Söderlund
---
drivers/net/nfp/flower/nfp_flower.c | 430
drivers/net/nfp/flower/nfp_flower.h | 1 +
2 files changed, 431 insertions(+)
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 7034d45..f321003 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -23,6 +23,7 @@
#include "nfp_flower_ovs_compat.h"
#include "nfp_flower_ctrl.h"
#include "nfp_flower_representor.h"
+#include "nfp_flower_cmsg.h"
#define MAX_PKT_BURST 32
#define MEMPOOL_CACHE_SIZE 512
@@ -218,6 +219,44 @@
.link_update= nfp_flower_pf_link_update,
};
+static void
+nfp_flower_pf_vnic_poll(struct nfp_app_flower *app_flower)
+{
+ uint16_t i;
+ uint16_t count;
+ uint16_t n_rxq;
+ uint16_t port_id;
+ struct nfp_net_hw *pf_hw;
+ struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
+
+ pf_hw = app_flower->pf_hw;
+
+ n_rxq = pf_hw->eth_dev->data->nb_rx_queues;
+ port_id = pf_hw->eth_dev->data->port_id;
+
+ /* Add ability to run Rx queues on multiple service cores? */
+ for (i = 0; i < n_rxq; i++) {
+ count = rte_eth_rx_burst(port_id, i, pkts_burst, MAX_PKT_BURST);
+
+ /*
+* Don't expect packets here but free them in case they have
+* not been multiplexed to a representor
+*/
+ if (unlikely(count > 0))
+ rte_pktmbuf_free_bulk(pkts_burst, count);
+ }
+}
+
+static int
+nfp_flower_pf_vnic_service(void *arg)
+{
+ struct nfp_app_flower *app_flower = arg;
+
+ nfp_flower_pf_vnic_poll(app_flower);
+
+ return 0;
+}
+
static int
nfp_flower_ctrl_vnic_service(void *arg)
{
@@ -229,6 +268,10 @@
}
static struct rte_service_spec flower_services[NFP_FLOWER_SERVICE_MAX] = {
+ [NFP_FLOWER_SERVICE_PF] = {
+ .name = "flower_pf_vnic_service",
+ .callback = nfp_flower_pf_vnic_service,
+ },
[NFP_FLOWER_SERVICE_CTRL] = {
.name = "flower_ctrl_vnic_service",
.callback = nfp_flower_ctrl_vnic_service,
@@ -265,6 +308,389 @@
return ret;
}
+static inline void
+nfp_flower_parse_metadata(struct nfp_net_rxq *rxq,
+ struct nfp_net_rx_desc *rxd,
+ struct rte_mbuf *mbuf,
+ uint32_t *portid)
+{
+ uint32_t meta_info;
+ uint8_t *meta_offset;
+ struct nfp_net_hw *hw;
+
+ hw = rxq->hw;
+ if (!((hw->ctrl & NFP_NET_CFG_CTRL_RSS) ||
+ (hw->ctrl & NFP_NET_CFG_CTRL_RSS2)))
+ return;
+
+ meta_offset = rte_pktmbuf_mtod(mbuf, uint8_t *);
+ meta_offset -= NFP_DESC_META_LEN(rxd);
+ meta_info = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
+ meta_offset += 4;
+
+ while (meta_info) {
+ switch (meta_info & NFP_NET_META_FIELD_MASK) {
+ /* Expect flower firmware to only send packets with META_PORTID
*/
+ case NFP_NET_META_PORTID:
+ *portid = rte_be_to_cpu_32(*(uint32_t *)meta_offset);
+ meta_offset += 4;
+ meta_info >>= NFP_NET_META_FIELD_SIZE;
+ break;
+ default:
+ /* Unsupported metadata can be a performance issue */
+ return;
+ }
+ }
+}
+
+static inline struct nfp_flower_representor *
+nfp_flower_get_repr(struct nfp_net_hw *hw,
+ uint32_t port_id)
+{
+ uint8_t port;
+ struct nfp_app_flower *app_flower;
+
+ /* Obtain handle to app_flower here */
+ app_flower = NFP_APP_PRIV_TO_APP_FLOWER(hw->pf_dev->app_priv);
+
+ switch (NFP_FLOWER_CMSG_PORT_TYPE(port_id)) {
+ case NFP_FLOWER_CMSG_PORT_TYPE_PHYS_PORT:
+ port = NFP_FLOWER_CMSG_PORT_PHYS_PORT_NUM(port_id);
+ return app_flower->phy_reprs[port];
+ case NFP_FLOWER_CMSG_PORT_TYPE_PCIE_PORT:
+ port = NFP_FLOWER_CMSG_PORT_VNIC(port_id);
+ return app_flower->vf_reprs[port];
+ default:
+ break;
+ }
+
+ return NULL;
+}
+
+static uint16_t
+nfp_flower_pf_recv_pkts(void *rx_queue,
+ struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts)
+{
+ /*
+* we need different counters for packets given to the caller
+* and packets sent to re
RE: [PATCH v4] net/igc: add support for secondary processes
>> The RX function was not specified in the secondary process, causing
>> the secondary process to segfault in a multi-process environment.
>>
>> This patch specify RX/TX functions in "dev_init" to support secondary
>> processes.
>>
>> Fixes: 66fde1b943eb ("net/igc: add skeleton")
>> Cc: alvinx.zh...@intel.com
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Zhichao Zeng
>>
>> ---
>> v2:
>> remove unnecessary parameters, move declaration to relevant header
>> file
>> ---
>> v3:
>> remove redundant code, optimize commit log
>> ---
>> v4:
>> rework patch
>> ---
>> drivers/net/igc/igc_ethdev.c | 9 -
>> drivers/net/igc/igc_txrx.c | 8
>> drivers/net/igc/igc_txrx.h | 6 ++
>> 3 files changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/igc/igc_ethdev.c
>> b/drivers/net/igc/igc_ethdev.c index
>> b9933b395d..7f221a5d34 100644
>> --- a/drivers/net/igc/igc_ethdev.c
>> +++ b/drivers/net/igc/igc_ethdev.c
>> @@ -1240,8 +1240,15 @@ eth_igc_dev_init(struct rte_eth_dev *dev)
>> * has already done this work. Only check we don't need a different
>> * RX function.
>> */
>> -if (rte_eal_process_type() != RTE_PROC_PRIMARY)
>> +if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
>> +dev->rx_pkt_burst = igc_recv_pkts;
>> +if (dev->data->scattered_rx)
>> +dev->rx_pkt_burst = igc_recv_scattered_pkts;
>
>Please removed the redundant code in igc_rx_init
Only the main process will execute "igc_rx_init", and the secondary process
will not execute it.
So, the data path of the secondary process is not initialized.
The code that this patch adds to initialize the data path in "dev_init" will
only be executed in the
secondary process. The same code in "igc_rx_init" is not redundant.
May I ask if the commit log is confusing, and should I submit new patch to
correct it?
Regards
Zhichao
RE: [PATCH v4] net/igc: add support for secondary processes
> -Original Message-
> From: Zeng, ZhichaoX
> Sent: Friday, July 1, 2022 11:13 AM
> To: Zhang, Qi Z ; dev@dpdk.org
> Cc: sta...@dpdk.org; Yang, Qiming ;
> alvinx.zh...@intel.com; Guo, Junfeng ; Su, Simei
> ; Burakov, Anatoly ;
> Ferruh Yigit
> Subject: RE: [PATCH v4] net/igc: add support for secondary processes
>
> >> The RX function was not specified in the secondary process, causing
> >> the secondary process to segfault in a multi-process environment.
> >>
> >> This patch specify RX/TX functions in "dev_init" to support secondary
> processes.
> >>
> >> Fixes: 66fde1b943eb ("net/igc: add skeleton")
> >> Cc: alvinx.zh...@intel.com
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Zhichao Zeng
> >>
> >> ---
> >> v2:
> >> remove unnecessary parameters, move declaration to relevant header
> >> file
> >> ---
> >> v3:
> >> remove redundant code, optimize commit log
> >> ---
> >> v4:
> >> rework patch
> >> ---
> >> drivers/net/igc/igc_ethdev.c | 9 -
> >> drivers/net/igc/igc_txrx.c | 8
> >> drivers/net/igc/igc_txrx.h | 6 ++
> >> 3 files changed, 18 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/igc/igc_ethdev.c
> >> b/drivers/net/igc/igc_ethdev.c index
> >> b9933b395d..7f221a5d34 100644
> >> --- a/drivers/net/igc/igc_ethdev.c
> >> +++ b/drivers/net/igc/igc_ethdev.c
> >> @@ -1240,8 +1240,15 @@ eth_igc_dev_init(struct rte_eth_dev *dev)
> >> * has already done this work. Only check we don't need a different
> >> * RX function.
> >> */
> >> - if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> >> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> >> + dev->rx_pkt_burst = igc_recv_pkts;
> >> + if (dev->data->scattered_rx)
> >> + dev->rx_pkt_burst = igc_recv_scattered_pkts;
> >
> >Please removed the redundant code in igc_rx_init
>
> Only the main process will execute "igc_rx_init", and the secondary process
> will not execute it.
> So, the data path of the secondary process is not initialized.
>
> The code that this patch adds to initialize the data path in "dev_init" will
> only be executed in the secondary process. The same code in "igc_rx_init" is
> not redundant.
Ok, I missed this point, the implementation is correct.
Acked-by: Qi Zhang
Applied to dpdk-next-net-intel.
Thanks
Qi
>
> May I ask if the commit log is confusing, and should I submit new patch to
> correct it?
>
> Regards
> Zhichao
RE: [PATCH] doc: announce some raw/ifpga API removal
Hi David, Got, thank you so much. > -Original Message- > From: David Marchand > Sent: Thursday, June 30, 2022 17:41 > To: dev@dpdk.org; Xu, Rosen ; Zhang, Tianfei > > Cc: Ray Kinsella > Subject: [PATCH] doc: announce some raw/ifpga API removal > > rte_pmd_ifpga_get_pci_bus() documentation is vague and it is unclear what > could be done with it. > On the other hand, EAL provides a standard API to retrieve a bus object by > name. > > Announce removal of this driver specific API for v22.11. > > Signed-off-by: David Marchand > --- > A RFC series of the intended changes is available at: > https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&arch > ive=both > > --- > doc/guides/rel_notes/deprecation.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 4e5b23c53d..64d649777a 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -119,6 +119,8 @@ Deprecation Notices > * metrics: The function ``rte_metrics_init`` will have a non-void return >in order to notify errors instead of calling ``rte_exit``. > > +* raw/ifgpa: The ``rte_pmd_ifpga_get_pci_bus`` will be removed in 22.11. > + > * raw/ioat: The ``ioat`` rawdev driver has been deprecated, since it's >functionality is provided through the new ``dmadev`` infrastructure. >To continue to use hardware previously supported by the ``ioat`` rawdev > driver, > -- > 2.36.1
RE: [PATCH] doc: announce some raw/ifpga API removal
Hi David, > -Original Message- > From: Xu, Rosen > Sent: Friday, July 1, 2022 14:16 > To: David Marchand ; dev@dpdk.org; Zhang, > Tianfei ; Huang, Wei > Cc: Ray Kinsella > Subject: RE: [PATCH] doc: announce some raw/ifpga API removal > > Hi David, > > Got, thank you so much. > > > > -Original Message- > > From: David Marchand > > Sent: Thursday, June 30, 2022 17:41 > > To: dev@dpdk.org; Xu, Rosen ; Zhang, Tianfei > > > > Cc: Ray Kinsella > > Subject: [PATCH] doc: announce some raw/ifpga API removal > > > > rte_pmd_ifpga_get_pci_bus() documentation is vague and it is unclear > > what could be done with it. > > On the other hand, EAL provides a standard API to retrieve a bus > > object by name. > > Agree, this API is used in an external application, I can use rte_get_bus_by_name() to replace it. I will submit a patch to remove rte_pmd_ifpga_get_pci_bus() after DPDK22.07 is released. > > Announce removal of this driver specific API for v22.11. > > > > Signed-off-by: David Marchand > > --- > > A RFC series of the intended changes is available at: > > > https://patches.dpdk.org/project/dpdk/list/?series=23811&state=%2A&arc > > h > > ive=both > > > > --- > > doc/guides/rel_notes/deprecation.rst | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 4e5b23c53d..64d649777a 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -119,6 +119,8 @@ Deprecation Notices > > * metrics: The function ``rte_metrics_init`` will have a non-void return > >in order to notify errors instead of calling ``rte_exit``. > > > > +* raw/ifgpa: The ``rte_pmd_ifpga_get_pci_bus`` will be removed in 22.11. > > + > > * raw/ioat: The ``ioat`` rawdev driver has been deprecated, since it's > >functionality is provided through the new ``dmadev`` infrastructure. > >To continue to use hardware previously supported by the ``ioat`` > > rawdev driver, > > -- > > 2.36.1
