* [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
@ 2026-10-10 9:25 liujie5
2026-10-10 9:25 ` [PATCH v1 1/1] " liujie5
0 siblings, 1 reply; 6+ messages in thread
From: liujie5 @ 2026-10-10 9:25 UTC (permalink / raw)
To: stephen; +Cc: dev, liufeng1
From: liufeng1 <liufeng1@sugon.com>
This series adds a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA,
which allows a PCI driver to tell the PCI bus layer that it cannot work
with IOVA as VA and must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a kernel
driver that uses an identity-mapped IOMMU domain (e.g. when the kernel
is booted with iommu=pt). The user-space PMD for such devices must use
IOVA as PA, because the DMA addresses programmed by DPDK must match the
identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode() returns
RTE_IOVA_PA for the device. The requirement is propagated through
rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
liufeng1 (1):
bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 4 ++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 7 insertions(+), 2 deletions(-)
--
2.52.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v1 1/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-10-10 9:25 [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
@ 2026-10-10 9:25 ` liujie5
2026-10-12 7:53 ` Bruce Richardson
2026-10-20 12:03 ` [PATCH v2 0/1] " liujie5
0 siblings, 2 replies; 6+ messages in thread
From: liujie5 @ 2026-10-10 9:25 UTC (permalink / raw)
To: stephen; +Cc: dev, liufeng1, Jie Liu
From: liufeng1 <liufeng1@sugon.com>
Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
driver to tell the PCI bus layer it cannot work with IOVA as VA and
must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a
kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
kernel is booted with iommu=pt). The user-space PMD for such devices
must use IOVA as PA, because the DMA addresses programmed by DPDK must
match the identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
returns RTE_IOVA_PA for the device. The requirement is propagated
through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
---
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 4 ++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
index c04ebddf59..5d5efbbb3e 100644
--- a/drivers/bus/pci/bus_pci_driver.h
+++ b/drivers/bus/pci/bus_pci_driver.h
@@ -140,6 +140,8 @@ struct rte_pci_driver {
#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
#define RTE_PCI_DRV_NEED_IOVA_AS_VA 0x0040
+/** Device driver needs IOVA as PA and cannot work with IOVA as VA */
+#define RTE_PCI_DRV_NEED_IOVA_AS_PA 0x0080
/**
* Register a PCI driver.
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index bcf0a409da..bf7125e214 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -609,6 +609,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
iova_mode = RTE_IOVA_PA;
else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
@@ -620,6 +622,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
default:
if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
return iova_mode;
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index dc8db80d3b..9893306c8e 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -533,8 +533,7 @@ rte_pci_get_iommu_class(void)
iommu_no_va = pci_device_iommu_support_va(dev)
? 0 : 1;
- if (dev->kdrv == RTE_PCI_KDRV_UNKNOWN ||
- dev->kdrv == RTE_PCI_KDRV_NONE)
+ if (dev->kdrv == RTE_PCI_KDRV_NONE)
continue;
RTE_BUS_FOREACH_DRV(drv, &rte_pci_bus) {
enum rte_iova_mode dev_iova_mode;
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-10-10 9:25 ` [PATCH v1 1/1] " liujie5
@ 2026-10-12 7:53 ` Bruce Richardson
2026-10-20 12:03 ` [PATCH v2 0/1] " liujie5
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Richardson @ 2026-10-12 7:53 UTC (permalink / raw)
To: liujie5; +Cc: stephen, dev, liufeng1
On Sat, Oct 10, 2026 at 05:25:25PM +0800, liujie5@linkdatatechnology.com wrote:
> From: liufeng1 <liufeng1@sugon.com>
>
> Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
> driver to tell the PCI bus layer it cannot work with IOVA as VA and
> must use IOVA as PA.
>
> The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
> opposite requirement. Some PCI devices, however, are managed by a
> kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
> kernel is booted with iommu=pt). The user-space PMD for such devices
> must use IOVA as PA, because the DMA addresses programmed by DPDK must
> match the identity mapping programmed by the kernel driver.
>
> Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
> has no way to force IOVA as PA. pci_device_iova_mode() returns
> RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
> IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
> forces users to pass --iova-mode=pa on the command line.
>
> When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
> returns RTE_IOVA_PA for the device. The requirement is propagated
> through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
> rte_eal_init() selects IOVA as PA automatically.
>
> This is a generic mechanism: any PCI driver whose underlying kernel
> driver uses an identity IOMMU domain can set the flag.
>
> Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
> ---
> drivers/bus/pci/bus_pci_driver.h | 2 ++
> drivers/bus/pci/linux/pci.c | 4 ++++
> drivers/bus/pci/pci_common.c | 3 +--
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
> index c04ebddf59..5d5efbbb3e 100644
> --- a/drivers/bus/pci/bus_pci_driver.h
> +++ b/drivers/bus/pci/bus_pci_driver.h
> @@ -140,6 +140,8 @@ struct rte_pci_driver {
> #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
> /** Device driver needs IOVA as VA and cannot work with IOVA as PA */
> #define RTE_PCI_DRV_NEED_IOVA_AS_VA 0x0040
> +/** Device driver needs IOVA as PA and cannot work with IOVA as VA */
> +#define RTE_PCI_DRV_NEED_IOVA_AS_PA 0x0080
>
> /**
> * Register a PCI driver.
> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
> index bcf0a409da..bf7125e214 100644
> --- a/drivers/bus/pci/linux/pci.c
> +++ b/drivers/bus/pci/linux/pci.c
> @@ -609,6 +609,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
> iova_mode = RTE_IOVA_PA;
> else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
> iova_mode = RTE_IOVA_VA;
> + else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
> + iova_mode = RTE_IOVA_PA;
> break;
> }
>
> @@ -620,6 +622,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
> default:
> if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
> iova_mode = RTE_IOVA_VA;
> + else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
> + iova_mode = RTE_IOVA_PA;
> break;
> }
> return iova_mode;
Do we need a sanity check somewhere that we don't have two drivers with
conflicting flags set i.e. one NEED_IOVA_AS_VA and one NEED_IOVA_AS_PA? It
should never happen, I imagine, but things that should never happen have
this annoying habit of sometimes happening! :-)
/Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH v2 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-10-10 9:25 ` [PATCH v1 1/1] " liujie5
2026-10-12 7:53 ` Bruce Richardson
@ 2026-10-20 12:03 ` liujie5
2026-10-20 12:03 ` [PATCH v2 1/1] " liujie5
1 sibling, 1 reply; 6+ messages in thread
From: liujie5 @ 2026-10-20 12:03 UTC (permalink / raw)
To: stephen; +Cc: dev, Jie Liu
From: Jie Liu <liujie5@linkdatatechnology.com>
V2:
Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
driver to tell the PCI bus layer it cannot work with IOVA as VA and
must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a
kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
kernel is booted with iommu=pt). The user-space PMD for such devices
must use IOVA as PA, because the DMA addresses programmed by DPDK must
match the identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
returns RTE_IOVA_PA for the device. The requirement is propagated
through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
If a driver sets both RTE_PCI_DRV_NEED_IOVA_AS_VA and
RTE_PCI_DRV_NEED_IOVA_AS_PA at the same time, a warning is emitted
and the conflicting requirement is ignored (RTE_IOVA_DC), because
the two flags are mutually exclusive.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
liufeng1 (1):
bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 13 +++++++++++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 16 insertions(+), 2 deletions(-)
--
2.52.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2 1/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-10-20 12:03 ` [PATCH v2 0/1] " liujie5
@ 2026-10-20 12:03 ` liujie5
0 siblings, 0 replies; 6+ messages in thread
From: liujie5 @ 2026-10-20 12:03 UTC (permalink / raw)
To: stephen; +Cc: dev, liufeng1, Jie Liu
From: liufeng1 <liufeng1@sugon.com>
Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
driver to tell the PCI bus layer it cannot work with IOVA as VA and
must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a
kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
kernel is booted with iommu=pt). The user-space PMD for such devices
must use IOVA as PA, because the DMA addresses programmed by DPDK must
match the identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
returns RTE_IOVA_PA for the device. The requirement is propagated
through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
If a driver sets both RTE_PCI_DRV_NEED_IOVA_AS_VA and
RTE_PCI_DRV_NEED_IOVA_AS_PA at the same time, a warning is emitted
and the conflicting requirement is ignored (RTE_IOVA_DC), because
the two flags are mutually exclusive.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
---
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 13 +++++++++++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
index c04ebddf59..5d5efbbb3e 100644
--- a/drivers/bus/pci/bus_pci_driver.h
+++ b/drivers/bus/pci/bus_pci_driver.h
@@ -140,6 +140,8 @@ struct rte_pci_driver {
#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
#define RTE_PCI_DRV_NEED_IOVA_AS_VA 0x0040
+/** Device driver needs IOVA as PA and cannot work with IOVA as VA */
+#define RTE_PCI_DRV_NEED_IOVA_AS_PA 0x0080
/**
* Register a PCI driver.
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index bcf0a409da..4e03d81ed2 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -595,6 +595,15 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
{
enum rte_iova_mode iova_mode = RTE_IOVA_DC;
+ if ((pdrv->drv_flags &
+ (RTE_PCI_DRV_NEED_IOVA_AS_VA | RTE_PCI_DRV_NEED_IOVA_AS_PA)) ==
+ (RTE_PCI_DRV_NEED_IOVA_AS_VA | RTE_PCI_DRV_NEED_IOVA_AS_PA)) {
+ RTE_LOG(WARNING, EAL,
+ "PCI driver '%s' sets both NEED_IOVA_AS_VA and NEED_IOVA_AS_PA flags, ignoring\n",
+ pdrv->driver.name);
+ return iova_mode;
+ }
+
switch (pdev->kdrv) {
case RTE_PCI_KDRV_VFIO: {
static int is_vfio_noiommu_enabled = -1;
@@ -609,6 +618,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
iova_mode = RTE_IOVA_PA;
else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
@@ -620,6 +631,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
default:
if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
return iova_mode;
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index dc8db80d3b..9893306c8e 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -533,8 +533,7 @@ rte_pci_get_iommu_class(void)
iommu_no_va = pci_device_iommu_support_va(dev)
? 0 : 1;
- if (dev->kdrv == RTE_PCI_KDRV_UNKNOWN ||
- dev->kdrv == RTE_PCI_KDRV_NONE)
+ if (dev->kdrv == RTE_PCI_KDRV_NONE)
continue;
RTE_BUS_FOREACH_DRV(drv, &rte_pci_bus) {
enum rte_iova_mode dev_iova_mode;
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v9 23/23] net/sxe2: update sxe2 feature matrix docs
@ 2026-06-26 6:49 liujie5
2026-10-20 11:50 ` [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
0 siblings, 1 reply; 6+ messages in thread
From: liujie5 @ 2026-06-26 6:49 UTC (permalink / raw)
To: stephen; +Cc: dev, Jie Liu
From: Jie Liu <liujie5@linkdatatechnology.com>
Update the sxe2.ini feature sheet to accurately reflect the recently
implemented hardware capabilities in the sxe2 PMD.
Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
---
doc/guides/nics/features/sxe2.ini | 56 +++++++++
doc/guides/nics/sxe2.rst | 186 ++++++++++++++++++++++++++++++
2 files changed, 242 insertions(+)
diff --git a/doc/guides/nics/features/sxe2.ini b/doc/guides/nics/features/sxe2.ini
index 09ba2f558c..3c1e6a8a39 100644
--- a/doc/guides/nics/features/sxe2.ini
+++ b/doc/guides/nics/features/sxe2.ini
@@ -7,17 +7,73 @@
; is selected.
;
[Features]
+Speed capabilities = Y
+Link status = Y
+Link status event = Y
+Rx interrupt = Y
Fast mbuf free = P
Free Tx mbuf on demand = Y
Burst mode info = Y
Queue start/stop = Y
+Power mgmt address monitor = Y
Buffer split on Rx = P
Scattered Rx = Y
+Traffic manager = Y
CRC offload = Y
+VLAN offload = Y
+QinQ offload = P
L3 checksum offload = Y
L4 checksum offload = Y
+Timestamp offload = P
+Inner L3 checksum = P
+Inner L4 checksum = P
Rx descriptor status = Y
Tx descriptor status = Y
+MTU update = Y
+TSO = P
+Promiscuous mode = Y
+Allmulticast mode = Y
+Unicast MAC filter = Y
+RSS hash = Y
+RSS key update = Y
+RSS reta update = Y
+VLAN filter = Y
+Inline crypto = Y
+Packet type parsing = Y
+Timesync = Y
+Basic stats = Y
+Extended stats = Y
+FW version = Y
+Module EEPROM dump = Y
+Multiprocess aware = Y
Linux = Y
x86-32 = Y
x86-64 = Y
+
+[rte_flow items]
+eth = P
+geneve = Y
+gre = Y
+gtpu = Y
+ipv4 = Y
+ipv6 = Y
+ipv6_frag_ext = Y
+nvgre = Y
+sctp = Y
+tcp = Y
+udp = Y
+vlan = P
+vxlan = Y
+vxlan_gpe = Y
+
+[rte_flow actions]
+count = Y
+drop = Y
+mark = Y
+passthru = Y
+port_representor = Y
+queue = Y
+represented_port = Y
+rss = Y
+send_to_kernel = Y
+port_id = Y
diff --git a/doc/guides/nics/sxe2.rst b/doc/guides/nics/sxe2.rst
index 539072b076..270556037b 100644
--- a/doc/guides/nics/sxe2.rst
+++ b/doc/guides/nics/sxe2.rst
@@ -35,3 +35,189 @@ preventing unauthorized access to random physical memory.
This capability allows the PMD to coexist with kernel network interfaces
which remain functional, although they stop receiving unicast packets
as long as they share the same MAC address.
+
+Configuration
+-------------
+
+Runtime Configuration
+~~~~~~~~~~~~~~~~~~~~~
+
+- ``Traffic Management Scheduling Levels``
+
+ The DPDK Traffic Management (rte_tm) APIs can be used to configure the Tx scheduler on the NIC.
+ The ``sched-layer-mode`` parameter can be used to set the number of scheduling levels
+ in the transmit scheduling hierarchy.
+ The provided value must be between 0 and 3.
+ If the value provided is greater than the number of levels supported by the HW,
+ the driver will use the hardware maximum value.
+
+- ``flow-duplicate-pattern`` parameter [int]
+
+ This parameter controls whether duplicate flow rules (rules with the same pattern items)
+ are allowed on the switch engine flow type.
+ Value ``0`` rejects duplicates; values ``1`` and ``2`` allow duplicates
+ but differ in which rule takes effect when multiple identical rules exist.
+
+ There are three options to choose:
+
+ - 0. Prevent insertion of rules with the same pattern items.
+ In this case, only the first rule is inserted and the following
+ rules are rejected and error code EEXIST is returned.
+
+ - 1. Allow insertion of rules with the same pattern items.
+ In this case, all rules are inserted but only the first rule
+ takes effect, the next rule takes effect only if the previous
+ rules are deleted.
+
+ - 2. Allow insertion of rules with the same pattern items.
+ In this case, all rules are inserted but only the last rule
+ takes effect, the previous rule takes effect only if the last
+ rule is deleted.
+
+ This option only applies to the switch engine flow type.
+ For the Fnav flow engine type, duplicate rules are always rejected.
+
+ When multiple PFs and VFs are bound to the driver, the same-priority
+ pattern can be applied to different ports (PF or VF).
+ This parameter controls whether duplicate rules across ports are
+ allowed and which rule takes effect when multiple identical rules
+ exist.
+
+ When only a single PF or VF is present (one port), sending an
+ identical pattern on the same port always returns error code EEXIST,
+ regardless of the parameter value.
+
+ By default, the PMD will set this value to 1 (allow duplicates,
+ first-added takes effect).
+
+- ``fnav-stat-type`` parameter [int]
+
+ This parameter controls the Fnav flow engine statistics type used
+ for flow rule hit counting (via ``rte_flow_query``).
+
+ - 1: Only count the number of packets.
+ - 2: Only count the number of bytes.
+ - 3: Count both packets and bytes (default).
+
+ Default value is 3 (count both packets and bytes).
+
+- ``drv-sw-stats`` parameter [int]
+
+ This parameter controls whether per-packet software statistics
+ (SW stats) are collected in the Rx data path.
+
+ Hardware packet statistic counters may be inaccurate for certain
+ packet types due to hardware design limitations.
+ When accuracy of Rx packet classification statistics is critical,
+ enabling this parameter allows the driver to accumulate statistics
+ in software as packets are received, providing an alternative
+ statistical path that bypasses hardware counter inaccuracies.
+
+ - 0: Disable software statistics collection (default).
+ The basic port statistics (``ipackets``, ``ibytes``) are reported
+ from the hardware counters.
+ - 1: Enable software statistics collection.
+ Per-packet software statistics are accumulated for unicast,
+ multicast, broadcast, and dropped packets in the Rx data path.
+
+ When enabled, the following extended statistics (xstats) are available:
+ ``rx_sw_unicast_packets``, ``rx_sw_multicast_packets``,
+ ``rx_sw_broadcast_packets``, ``rx_sw_drop_packets``,
+ and ``rx_sw_drop_bytes``.
+
+- ``no-sched-mode`` parameter [int]
+
+ This parameter enables non-scheduling mode (no-sched mode).
+ When enabled, the transmit path bypasses the hardware scheduling module
+ and packets are sent directly out through the port.
+ This results in lower transmit latency and higher throughput,
+ but Traffic Management (rte_tm) APIs are not supported in this mode.
+
+ - 0: Disable non-scheduling mode (default).
+ The transmit path goes through the hardware scheduling hierarchy.
+ Traffic Management (rte_tm) APIs can be used to configure the Tx scheduler.
+ - 1: Enable non-scheduling mode.
+ The transmit path bypasses the hardware scheduling module.
+ Packets are sent directly from the port at full speed without scheduling.
+ Traffic Management (rte_tm) APIs are not available in this mode.
+
+- ``rx-low-latency`` parameter [int]
+
+ This parameter controls the interrupt throttling (ITR) interval
+ for Rx queue interrupts.
+
+ When enabled, the driver sets a shorter interrupt coalescing timeout
+ (``SXE2_ITR_INTERVAL_LOW``, approximately 1 μs),
+ reducing the time between packet arrival and interrupt delivery to the CPU.
+ This lowers receive latency at the cost of increased CPU interrupt rate.
+
+ When disabled (default), the driver uses the normal interrupt throttling
+ interval (``SXE2_ITR_INTERVAL_NORMAL``, approximately 20 μs),
+ which reduces the CPU interrupt rate at the expense of higher receive latency.
+
+ - 0: Disable Rx low latency (default).
+ Normal interrupt throttling interval (~20 μs) is used.
+ - 1: Enable Rx low latency.
+ Low interrupt throttling interval (~1 μs) is used
+ for reduced receive latency.
+
+- ``function-flow-direct`` parameter [int]
+
+ This parameter controls whether flow rules from different functional units
+ (DPDK vs kernel driver) are isolated or combined when both drivers
+ control the same physical port.
+
+ When the DPDK PMD and the kernel network driver coexist on the same port,
+ flow rules may originate from either driver.
+ This parameter determines how the source VSI (Virtual Switch Interface)
+ of each flow rule is handled during hardware programming.
+
+ - 0 (default): Isolate flow rules between DPDK and kernel.
+ When ``flow_isolated`` is enabled (``rte_flow_isolate()`` called),
+ kernel-side flow rules take priority and DPDK-side flow rules are suppressed.
+ When ``flow_isolated`` is disabled, DPDK-side flow rules take priority
+ and kernel-side flow rules are suppressed.
+ Only one functional unit's flows are active at a time.
+
+ - 1: Allow direct flow rules from both DPDK and kernel simultaneously.
+ Both DPDK and kernel source VSIs are preserved in the hardware flow table.
+ Flow rules from both sides are programmed without isolation.
+
+ This option only applies to FNAV and ACL flow engine types
+ and does not apply to PF bond devices.
+
+Extended Statistics (xstats)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The PMD provides the following extended statistics (xstats) for detailed
+monitoring of receive-side packet classification and software-level accounting.
+The software statistics path is provided as a workaround for hardware
+counter inaccuracies on certain packet types --- it accumulates per-packet
+statistics directly in the Rx data path, ensuring that unicast, multicast,
+broadcast, and drop counts reflect the actual packets processed by the driver.
+
+Receive Software Statistics
+ These counters are collected in the Rx data path when ``drv-sw-stats=1``
+ is configured (see the ``drv-sw-stats`` devarg above).
+ When ``drv-sw-stats`` is disabled (default), these xstats report zero.
+
+ - ``rx_sw_unicast_packets``: Number of unicast packets received.
+ - ``rx_sw_multicast_packets``: Number of multicast packets received.
+ - ``rx_sw_broadcast_packets``: Number of broadcast packets received.
+ - ``rx_sw_drop_packets``: Number of packets dropped in the Rx data path.
+ - ``rx_sw_drop_bytes``: Number of bytes dropped in the Rx data path.
+
+ When ``drv-sw-stats`` is enabled, the basic counters ``ipackets`` and
+ ``ibytes`` (from ``rte_eth_stats``) also reflect the software-accumulated
+ packet and byte counts. Otherwise, they are reported from hardware counters.
+
+Fnav Flow Engine Statistics
+ The Fnav flow engine statistics type is controlled by the ``fnav-stat-type``
+ devarg (see above). Depending on the configuration:
+
+ - ``fnav-stat-type=1``: Only packet count is available.
+ - ``fnav-stat-type=2``: Only byte count is available.
+ - ``fnav-stat-type=3`` (default): Both packet and byte counts are available.
+
+ Flow query results (via ``rte_flow_query``) expose these per-flow counters
+ through the query API, not via xstats.
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-06-26 6:49 [PATCH v9 23/23] net/sxe2: update sxe2 feature matrix docs liujie5
@ 2026-10-20 11:50 ` liujie5
2026-10-20 11:50 ` [PATCH v1 1/1] " liujie5
0 siblings, 1 reply; 6+ messages in thread
From: liujie5 @ 2026-10-20 11:50 UTC (permalink / raw)
To: stephen; +Cc: dev, liufeng1
From: liufeng1 <liufeng1@sugon.com>
This series adds a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA,
which allows a PCI driver to tell the PCI bus layer that it cannot work
with IOVA as VA and must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a kernel
driver that uses an identity-mapped IOMMU domain (e.g. when the kernel
is booted with iommu=pt). The user-space PMD for such devices must use
IOVA as PA, because the DMA addresses programmed by DPDK must match the
identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode() returns
RTE_IOVA_PA for the device. The requirement is propagated through
rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
liufeng1 (1):
bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 4 ++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 7 insertions(+), 2 deletions(-)
--
2.52.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v1 1/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
2026-10-20 11:50 ` [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
@ 2026-10-20 11:50 ` liujie5
0 siblings, 0 replies; 6+ messages in thread
From: liujie5 @ 2026-10-20 11:50 UTC (permalink / raw)
To: stephen; +Cc: dev, liufeng1, Jie Liu
From: liufeng1 <liufeng1@sugon.com>
Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
driver to tell the PCI bus layer it cannot work with IOVA as VA and
must use IOVA as PA.
The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
opposite requirement. Some PCI devices, however, are managed by a
kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
kernel is booted with iommu=pt). The user-space PMD for such devices
must use IOVA as PA, because the DMA addresses programmed by DPDK must
match the identity mapping programmed by the kernel driver.
Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
has no way to force IOVA as PA. pci_device_iova_mode() returns
RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
forces users to pass --iova-mode=pa on the command line.
When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
returns RTE_IOVA_PA for the device. The requirement is propagated
through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
rte_eal_init() selects IOVA as PA automatically.
This is a generic mechanism: any PCI driver whose underlying kernel
driver uses an identity IOMMU domain can set the flag.
Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
---
drivers/bus/pci/bus_pci_driver.h | 2 ++
drivers/bus/pci/linux/pci.c | 4 ++++
drivers/bus/pci/pci_common.c | 3 +--
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
index c04ebddf59..5d5efbbb3e 100644
--- a/drivers/bus/pci/bus_pci_driver.h
+++ b/drivers/bus/pci/bus_pci_driver.h
@@ -140,6 +140,8 @@ struct rte_pci_driver {
#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
/** Device driver needs IOVA as VA and cannot work with IOVA as PA */
#define RTE_PCI_DRV_NEED_IOVA_AS_VA 0x0040
+/** Device driver needs IOVA as PA and cannot work with IOVA as VA */
+#define RTE_PCI_DRV_NEED_IOVA_AS_PA 0x0080
/**
* Register a PCI driver.
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index bcf0a409da..bf7125e214 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -609,6 +609,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
iova_mode = RTE_IOVA_PA;
else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
@@ -620,6 +622,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
default:
if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
iova_mode = RTE_IOVA_VA;
+ else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
+ iova_mode = RTE_IOVA_PA;
break;
}
return iova_mode;
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index dc8db80d3b..9893306c8e 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -533,8 +533,7 @@ rte_pci_get_iommu_class(void)
iommu_no_va = pci_device_iommu_support_va(dev)
? 0 : 1;
- if (dev->kdrv == RTE_PCI_KDRV_UNKNOWN ||
- dev->kdrv == RTE_PCI_KDRV_NONE)
+ if (dev->kdrv == RTE_PCI_KDRV_NONE)
continue;
RTE_BUS_FOREACH_DRV(drv, &rte_pci_bus) {
enum rte_iova_mode dev_iova_mode;
--
2.52.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-20 12:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-10 9:25 [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
2026-10-10 9:25 ` [PATCH v1 1/1] " liujie5
2026-10-12 7:53 ` Bruce Richardson
2026-10-20 12:03 ` [PATCH v2 0/1] " liujie5
2026-10-20 12:03 ` [PATCH v2 1/1] " liujie5
-- strict thread matches above, loose matches on Subject: below --
2026-06-26 6:49 [PATCH v9 23/23] net/sxe2: update sxe2 feature matrix docs liujie5
2026-10-20 11:50 ` [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
2026-10-20 11:50 ` [PATCH v1 1/1] " liujie5
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.