ethdev: introduce shared Rx queue
Subsystems (2)
RFC 1/1 ethdev: introduce shared Rx queue
In eth PMD driver model, each RX queue was pre-loaded with mbufs for saving incoming packets. When number of SF or VF scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
To save memory and speed up, this patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying offloading flag RTE_ETH_RX_OFFLOAD_SHARED_RXQ. Polling a member port in shared RX queue receives packets for all member ports. Source port is identified by mbuf->port.
Queue number of ports in shared group should be identical. Queue index is 1:1 mapped in shared group.
Shared RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
--- lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 2 files changed, 8 insertions(+)
lib/ethdev/rte_ethdev.c +1 -0
@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STR
lib/ethdev/rte_ethdev.h +7 -0
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or rx_offload_capa
@@ -1373,6 +1374,12 @@ struct rte_eth_conf {#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000#define DEV_RX_OFFLOAD_RSS_HASH 0x00080000#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT 0x00100000 +/** +* RXQ is shared within ports in switch domain to save memory and avoid +* polling every port. Any port in group could be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \
Signature · 1 line
2.25.1
Quoted 12 lines · Xueming Li
In eth PMD driver model, each RX queue was pre-loaded with mbufs for saving incoming packets. When number of SF or VF scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
To save memory and speed up, this patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying offloading flag
RTE_ETH_RX_OFFLOAD_SHARED_RXQ. Polling a member port in shared RX queue receives packets for all member ports. Source port is identified bymbuf->port.
Quoted 8 lines
Queue number of ports in shared group should be identical. Queue index is 1:1 mapped in shared group.
Shared RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Signed-off-by Xueming Li <[email protected]>
It looks like it could be useful to artificial benchmarks, but absolutely useless for real life. SFs and VFs are used by VMs (or containers?) to have its own part of HW. If so, SF or VF Rx and Tx queues live in a VM and cannot be shared.
Sharing makes sense for representors, but it is not mentioned in the description.
Hi Andrew,
Quoted 24 lines
-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Wednesday, July 28, 2021 3:57 PM
To: Xueming(Steven) Li <[email protected]>
Cc: [email protected]; Slava Ovsiienko <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Ferruh Yigit <[email protected]>
Subject: Re: [RFC] ethdev: introduce shared Rx queueQuoted 15 lines · Xueming Li
In eth PMD driver model, each RX queue was pre-loaded with mbufs for saving incoming packets. When number of SF or VF scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
To save memory and speed up, this patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying offloading flag
RTE_ETH_RX_OFFLOAD_SHARED_RXQ. Polling a member port in shared RX queue receives packets for all member ports. Source port is identified bymbuf->port.Queue number of ports in shared group should be identical. Queue index is 1:1 mapped in shared group.
Quoted 8 lines
Quoted 5 lines
Shared RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Signed-off-by Xueming Li <[email protected]>It looks like it could be useful to artificial benchmarks, but absolutely useless for real life. SFs and VFs are used by VMs (or containers?) to have its own part of HW. If so, SF or VF Rx and Tx queues live in a VM and cannot be shared.
Thanks for looking at this! Agree, SF and VF can't be shared.
Quoted 2 lines
Sharing makes sense for representors, but it is not mentioned in the description.
Yes, the major target is representors, ports in same switch domain, I'll emphasis this in next version.
PATCH 1/1 ethdev: introduce shared Rx queue
In reply to Xueming LiIn current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from all member ports. Source port is identified by mbuf->port.
Port queue number in a shared group should be identical. Queue index is 1:1 mapped in shared group.
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)
doc/guides/nics/features.rst +11 -0
@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsing
doc/guides/nics/features/default.ini +1 -0
@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =
doc/guides/prog_guide/switch_representation.rst +10 -0
@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev) <https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_ +- Memory usage of representors is huge when number of representor grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache miss and + latency. Shared Rx queue can be used to share Rx queue between PF and + representors in same switch domain. ``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting the + offloading flag in device Rx mode or Rx queue configuration to enable + shared Rx queue. Polling any member port of shared Rx queue can return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------
lib/ethdev/rte_ethdev.c +1 -0
@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STR
lib/ethdev/rte_ethdev.h +7 -0
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or rx_offload_capa
@@ -1373,6 +1374,12 @@ struct rte_eth_conf {#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000#define DEV_RX_OFFLOAD_RSS_HASH 0x00080000#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT 0x00100000 +/** +* Rx queue is shared among ports in same switch domain to save memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \
Signature · 1 line
2.25.1
Quoted 12 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from all member ports. Source port is identified by
mbuf->port.
Quoted 6 lines
Port queue number in a shared group should be identical. Queue index is 1:1 mapped in shared group.
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
If it is for a generic case, how the flow ordering will be maintained?
Quoted 105 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +10
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev) <https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_ +- Memory usage of representors is huge when number of representor grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache miss and + latency. Shared Rx queue can be used to share Rx queue between PF and + representors in same switch domain. ``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting the + offloading flag in device Rx mode or Rx queue configuration to enable + shared Rx queue. Polling any member port of shared Rx queue can return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +7
-1@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or rx_offload_capa @@ -1373,6 +1374,12 @@ struct rte_eth_conf {#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000#define DEV_RX_OFFLOAD_RSS_HASH 0x00080000#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT 0x00100000 +/** +* Rx queue is shared among ports in same switch domain to save memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Hi,
Quoted 25 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from all member ports. Source port is identified by
mbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.
Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted.
Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 118 lines
Quoted 118 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +15
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache miss +and + latency. Shared Rx queue can be used to share Rx queue between PF +and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c index renamed from lib/ethdev/rte_ethdev.c +0
-0
9d95cd11e1..1361ff759a100644lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h index renamed from lib/ethdev/rte_ethdev.h +0
-0
d2b27c351f..a578c9db9d100644lib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch +domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 34 lines · Xueming(Steven) Li
Hi,
Quoted 25 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from all member ports. Source port is identified by
mbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Quoted 8 lines
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted.
Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
My question was if create a generic RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues. If this offload is only useful for representor case, Can we make this offload specific
to representor the case by changing its name and scope.
Quoted 119 lines
Quoted 119 lines
Quoted 119 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +15
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache miss +and + latency. Shared Rx queue can be used to share Rx queue between PF +and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c index renamed from lib/ethdev/rte_ethdev.c +0
-0
9d95cd11e1..1361ff759a100644lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h index renamed from lib/ethdev/rte_ethdev.h +0
-0
d2b27c351f..a578c9db9d100644lib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch +domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 50 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 39 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Quoted 7 lines
Quoted 4 lines
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in rx_burst result, lookup source stream according to mbuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.
All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 77 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Wednesday, August 11, 2021 8:04 PM
To: Xueming(Steven) Li <[email protected]>; Jerin Jacob <[email protected]>
Cc: dpdk-dev <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 52 lines · Xueming(Steven) Li
Quoted 52 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 40 lines · Xueming(Steven) Li
Hi,
Quoted 27 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
Not quite sure that I understood your question. The control path of
is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ
offload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained forrespective receive queues.
Quoted 6 lines
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to
process, this will accelerates the performance if traffic come from
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all
Quoted 5 lines
forwarding engine. Will sent patches soon.
Quoted 1 line
All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
This has been mentioned in commit log, the shared rxq is supposed to be polling in single thread(core) - I think it should be "MUST". Result is unexpected if there are multiple cores pooling, that's why I added a polling schedule check in testpmd. Similar for rx/tx burst function, a queue can't be polled on multiple thread(core), and for performance concern, no such check in eal api.
If users want to utilize multiple cores to distribute workloads, it's possible to define more groups, queues in different group could be could be polled on multiple cores.
It's possible to poll every member port in group, but not necessary, any port in group could be polled to get packets for all ports in group.
If the member port subject to hot plug/remove, it's possible to create a vdev with same queue number, copy rxq object and poll vdev as a dedicate proxy for the group.
Quoted 3 lines
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Yes, we considered different options in design stage. One possible solution is to cache received packets in rings, this can be done on eth layer, but I'm afraid less benefits, user still has to be a ware of multiple core polling.
This can be done as a wrapper PMD later, more efforts.
Quoted 3 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
This feature supports both PF and representor, and yes, major issue is memory of representors. Poll all representors also introduces more core cache miss latency. This feature essentially aggregates all ports in group as one port. On the other hand, it's useful for rte flow to create offloading flows using representor as a regular port ID.
It's great if any new solution/suggestion, my head buried in PMD code :)
Quoted 129 lines
Quoted 129 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 94 lines
-----Original Message-----
From: dev <[email protected]> On Behalf Of Xueming(Steven) Li
Sent: Wednesday, August 11, 2021 8:59 PM
To: Ferruh Yigit <[email protected]>; Jerin Jacob <[email protected]>
Cc: dpdk-dev <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 82 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Wednesday, August 11, 2021 8:04 PM
To: Xueming(Steven) Li <[email protected]>; Jerin Jacob <[email protected]>
Cc: dpdk-dev <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 54 lines · Xueming(Steven) Li
Quoted 54 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 41 lines · Xueming(Steven) Li
Hi,
Quoted 28 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets
from all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Not quite sure that I understood your question. The control path
of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will
be supplied from shared Rx queue in my PMD implementation.My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained forrespective receive queues.
Quoted 8 lines
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to
process, this will accelerates the performance if traffic come from
limited ports. I'll introduce some common api to do shard rxq
forwarding, call it with packets handling callback, so it suites for
all
Quoted 8 lines
Quoted 5 lines
forwarding engine. Will sent patches soon.
Quoted 1 line
All ports will put the packets in to the same queue (share queue),
right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?This has been mentioned in commit log, the shared rxq is supposed to be polling in single thread(core) - I think it should be "MUST". Result is unexpected if there are multiple cores pooling, that's why I added a polling schedule check in testpmd.
V2 with testpmd code uploaded, please check.
Quoted 161 lines
Similar for rx/tx burst function, a queue can't be polled on multiple thread(core), and for performance concern, no such check in eal api.
If users want to utilize multiple cores to distribute workloads, it's possible to define more groups, queues in different group could be could be polled on multiple cores.
It's possible to poll every member port in group, but not necessary, any port in group could be polled to get packets for all ports in group.
If the member port subject to hot plug/remove, it's possible to create a vdev with same queue number, copy rxq object and poll vdev as a dedicate proxy for the group.
Quoted 3 lines
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Yes, we considered different options in design stage. One possible solution is to cache received packets in rings, this can be done on eth layer, but I'm afraid less benefits, user still has to be a ware of multiple core polling.
This can be done as a wrapper PMD later, more efforts.Quoted 3 lines
Overall, is this for optimizing memory for the port represontors? If
so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?This feature supports both PF and representor, and yes, major issue is memory of representors. Poll all representors also introduces more core cache miss latency. This feature essentially aggregates all ports in group as one port.
On the other hand, it's useful for rte flow to create offloading flows using representor as a regular port ID.It's great if any new solution/suggestion, my head buried in PMD code :)
Quoted 131 lines
Quoted 131 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 125 lines
Quoted 125 lines
Quoted 125 lines
Quoted 125 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.t
xtQuoted 1 line
`_
+- Memory usage of representors is huge when number of
doc/guides/prog_guide/switch_representation.rst +16
-0+representor grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue +between PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. +Setting the + offloading flag in device Rx mode or Rx queue configuration +to enable + shared Rx queue. Polling any member port of shared Rx queue +can return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 95 lines · Xueming(Steven) Li
Quoted 76 lines
-----Original Message-----
From: Ferruh Yigit <[email protected]>
Sent: Wednesday, August 11, 2021 8:04 PM
To: Xueming(Steven) Li <[email protected]>; Jerin Jacob <[email protected]>
Cc: dpdk-dev <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 52 lines · Xueming(Steven) Li
Quoted 52 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 40 lines · Xueming(Steven) Li
Hi,
Quoted 27 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
Not quite sure that I understood your question. The control path of
is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ
offload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained forrespective receive queues.
Quoted 6 lines
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to
process, this will accelerates the performance if traffic come from
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for allQuoted 5 lines
forwarding engine. Will sent patches soon.
Quoted 1 line
All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
This has been mentioned in commit log, the shared rxq is supposed to be polling in single thread(core) - I think it should be "MUST". Result is unexpected if there are multiple cores pooling, that's why I added a polling schedule check in testpmd. Similar for rx/tx burst function, a queue can't be polled on multiple thread(core), and for performance concern, no such check in eal api.
If users want to utilize multiple cores to distribute workloads, it's possible to define more groups, queues in different group could be could be polled on multiple cores.
It's possible to poll every member port in group, but not necessary, any port in group could be polled to get packets for all ports in group.
If the member port subject to hot plug/remove, it's possible to create a vdev with same queue number, copy rxq object and poll vdev as a dedicate proxy for the group.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Yes, we considered different options in design stage. One possible solution is to cache received packets in rings, this can be done on eth layer, but I'm afraid less benefits, user still has to be a ware of multiple core polling.
This can be done as a wrapper PMD later, more efforts.
For people want to use shared rxq to save memory, they need to be conscious on the core polling rule: dedicate core for shared rxq, like the rule for rxq and txq.
I'm afraid specific changes in application is a must, but not too much:
polling one port per group is sufficient. Protections in data plane will definitely hurt performance :(
Quoted 9 lines
Quoted 4 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
This feature supports both PF and representor, and yes, major issue is memory of representors. Poll all representors also introduces more core cache miss latency. This feature essentially aggregates all ports in group as one port. On the other hand, it's useful for rte flow to create offloading flows using representor as a regular port ID.
As discussion with Jerin below, the major memory consumed by PF or representor is mbufs pre-filled to rxq. PMD can't assume all representors shares same memory pool, or share rxqs internally in PMD - user might schedule representors to different cores. Defining shared rxq flag and group looks a good direction.
Quoted 132 lines
It's great if any new solution/suggestion, my head buried in PMD code :)
Quoted 129 lines
Quoted 129 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 66 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.
Quoted 6 lines
All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
Quoted 134 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 72 lines · Xueming(Steven) Li
Quoted 70 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
Quoted 6 lines
Quoted 2 lines
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate fwd_engine to show how to use this feature.
Quoted 136 lines
Quoted 135 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
On Tue, 2021-09-28 at 15:05 +0530, Jerin Jacob wrote:
On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li <[email protected]<mailto:[email protected]>> wrote:
On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit wrote:
On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:
-----Original Message-----
From: Jerin Jacob <[email protected]<mailto:[email protected]>>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]<mailto:[email protected]>>
Andrew Rybchenko <[email protected]<mailto:[email protected]>>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue
On Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li <[email protected]<mailto:[email protected]>> wrote:
Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]<mailto:[email protected]>>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]<mailto:[email protected]>>
NBU-Contact-Thomas Monjalon <[email protected]<mailto:[email protected]>>; Andrew Rybchenko
<[email protected]<mailto:[email protected]>>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue
On Mon, Aug 9, 2021 at 5:18 PM Xueming Li <[email protected]<mailto:[email protected]>> wrote:
In current DPDK framework, each RX queue is pre-loaded with mbufs
for incoming packets. When number of representors scale out in a
switch domain, the memory consumption became significant. Most
important, polling all ports leads to high cache miss, high
latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group.
Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified by mbuf->port.
Port queue number in a shared group should be identical. Queue
index is
1:1 mapped in shared group.
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is
almost same as before, PF and representor port still needed, rte flows not impacted.
Queues still needed for each member port, descriptors(mbuf) will be
supplied from shared Rx queue in my PMD implementation.
My question was if create a generic RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple ethdev receive queues land into the same
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet in rx_burst result, lookup source stream according to mbuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.
All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd
application. Instead, testpmd can use aggregated ports probably as
separate fwd_engine to show how to use this feature.
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction.
Does your PMD support this?
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
---
doc/guides/nics/features.rst | 11 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c | 1 +
lib/ethdev/rte_ethdev.h | 7 +++++++
5 files changed, 30 insertions(+)
(quoted diff) +0 -0
b/doc/guides/nics/features.rst index a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4 checksum.
``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``.
+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same switch domain.
+
+* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:
Packet type parsing
(quoted diff) +0 -0
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
(quoted diff) +0 -0
b/doc/guides/prog_guide/switch_representation.rst
index ff6aa91c80..45bf5a3a10 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model (switchdev)
<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
`_
+- Memory usage of representors is huge when number of representor
+grows,
+ because PMD always allocate mbuf for each descriptor of Rx queue.
+ Polling the large number of ports brings more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of device info. Setting
+the
+ offloading flag in device Rx mode or Rx queue configuration to
+enable
+ shared Rx queue. Polling any member port of shared Rx queue can
+return
+ packets of all ports in group, port ID is saved in ``mbuf.port``.
+
Basic SR-IOV
------------
lib/ethdev/rte_ethdev.c +0 -0
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSUM),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPLIT),
+ RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};
#undef RTE_RX_OFFLOAD_BIT2STR
lib/ethdev/rte_ethdev.h +0 -0
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags.
* Only offloads set on rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH 0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT 0x00100000
+/**
+ * Rx queue is shared among ports in same switch domain to save
+memory,
+ * avoid polling each port. Any port in group can be used to receive packets.
+ * Real source port number saved in mbuf->port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000
#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLOAD_UDP_CKSUM | \
--
2.25.1
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.
Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.
Quoted 137 lines
Quoted 137 lines
Quoted 136 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.
Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.
Quoted 137 lines
Quoted 137 lines
Quoted 136 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 87 lines · Xueming(Steven) Li
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.
Quoted 6 lines
Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
Not unfortunately. More than that, every application needs to change to support this model.
Quoted 3 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.
We are thinking of implementing this PMD when it comes to it, ie. without application change in fastpath
logic.
Quoted 141 lines
Quoted 139 lines
Quoted 139 lines
Quoted 138 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 95 lines · Jerin Jacob
Quoted 87 lines · Xueming(Steven) Li
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.Quoted 6 lines
Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
Quoted 2 lines
Not unfortunately. More than that, every application needs to change to support this model.
Both strategies need user application to resolve port ID from mbuf and process accordingly.
This one doesn't demand aggregated port, no polling schedule change.
Quoted 8 lines
Quoted 4 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie. without application change in fastpath
logic.
Fastpath have to resolve port ID anyway and forwarding according to logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.
Let's defer part 2 until some PMD really support it and tested, how do you think?
Quoted 142 lines
Quoted 142 lines
Quoted 140 lines
Quoted 140 lines
Quoted 139 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 97 lines · Xueming(Steven) Li
Quoted 95 lines · Jerin Jacob
Quoted 93 lines · Xueming(Steven) Li
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
Quoted 6 lines
Quoted 2 lines
Not unfortunately. More than that, every application needs to change to support this model.
Both strategies need user application to resolve port ID from mbuf and process accordingly.
This one doesn't demand aggregated port, no polling schedule change.
I was thinking, mbuf will be updated from driver/aggregator port as when it comes to application.
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie. without application change in fastpath
logic.
Quoted 6 lines
Fastpath have to resolve port ID anyway and forwarding according to logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.
Let's defer part 2 until some PMD really support it and tested, how do you think?
We are not planning to use this feature so either way it is OK to me. I leave to ethdev maintainers decide between 1 vs 2.
I do have a strong opinion not changing the testpmd basic forward engines for this feature.I would like to keep it simple as fastpath optimized and would like to add a separate Forwarding engine as means to verify this feature.
Quoted 144 lines
Quoted 143 lines
Quoted 143 lines
Quoted 141 lines
Quoted 141 lines
Quoted 140 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 129 lines · Xueming(Steven) Li
Quoted 8 lines · Jerin Jacob
Quoted 6 lines · Xueming(Steven) Li
Quoted 5 lines · Jerin Jacob
Quoted 3 lines · Xueming(Steven) Li
Quoted 2 lines · Ferruh Yigit
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas MonjalonQuoted 41 lines
Quoted 41 lines
Quoted 41 lines
Quoted 41 lines
Quoted 41 lines
Quoted 41 lines
Quoted 41 lines
Quoted 41 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 37 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land intothe same
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 27 lines
Quoted 27 lines
Quoted 26 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.
All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 6 lines
Quoted 2 lines
Not unfortunately. More than that, every application needs to change to support this model.
Both strategies need user application to resolve port ID from mbuf and process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it comes to application.
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie. without application change in fastpath
logic.Quoted 6 lines
Fastpath have to resolve port ID anyway and forwarding according to logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.
Let's defer part 2 until some PMD really support it and tested, how do you think?
Quoted 6 lines
We are not planning to use this feature so either way it is OK to me. I leave to ethdev maintainers decide between 1 vs 2.
I do have a strong opinion not changing the testpmd basic forward engines for this feature.I would like to keep it simple as fastpath optimized and would like to add a separate Forwarding engine as means to verify this feature.
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.
Quoted 148 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 1 line
Quoted 1 line
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its
name and
Quoted 132 lines
Quoted 131 lines
Quoted 131 lines
Quoted 129 lines
Quoted 129 lines
Quoted 128 lines
Quoted 127 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 196 lines · Konstantin
Quoted 189 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
Quoted 2 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueQuoted 65 lines · Xueming(Steven) Li
Hi,
Quoted 39 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueQuoted 25 lines · Xueming Li
In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Quoted 8 lines
Quoted 4 lines
Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 2 lines
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is
almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be
supplied from shared Rx queue in my PMD implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 2 lines
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet inrx_burstresult, lookup source stream according tombuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 6 lines
I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.
Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.
-1 :)
There was some internal requirement from test team, they need to verify all features like packet content, rss, vlan, checksum, rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.
Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its
name and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 175 lines
Quoted 175 lines
Quoted 175 lines
Quoted 175 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
| 11 +++++++++++
doc/guides/nics/features/default.ini
| 1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
| 1 +
lib/ethdev/rte_ethdev.h
| 7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 198 lines · Xueming(Steven) Li
Quoted 196 lines · Konstantin
Quoted 195 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
Quoted 2 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueQuoted 65 lines · Xueming(Steven) Li
Hi,
Quoted 47 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could take advantage.
Quoted 2 lines
If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question. The control path of is
almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be
supplied from shared Rx queue in my PMD implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 2 lines
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet inrx_burstresult, lookup source stream according tombuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.
Quoted 6 lines
Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.-1 :)
There was some internal requirement from test team, they need to verify
Internal QA requirements may not be the driving factor :-)
Quoted 214 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its
name and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 175 lines
Quoted 175 lines
Quoted 175 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
| 11 +++++++++++
doc/guides/nics/features/default.ini
| 1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
| 1 +
lib/ethdev/rte_ethdev.h
| 7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 199 lines · Jerin Jacob
Quoted 198 lines · Xueming(Steven) Li
Quoted 196 lines · Konstantin
Quoted 195 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
Quoted 2 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueQuoted 65 lines · Xueming(Steven) Li
Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 2 lines
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet inrx_burstresult, lookup source stream according tombuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.-1 :)
There was some internal requirement from test team, they need to verifyInternal QA requirements may not be the driving factor :-)
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
Quoted 215 lines
Quoted 215 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its
name and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 175 lines
Quoted 175 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 210 lines · Xueming(Steven) Li
Quoted 206 lines · Jerin Jacob
Quoted 204 lines · Xueming(Steven) Li
Quoted 196 lines · Konstantin
Quoted 189 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
Quoted 2 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>; NBU-Contact-Thomas
MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
<[email protected]> wrote:Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 2 lines
receive queue, In that case, how the flow order is
maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet inrx_burstresult, lookup source stream according tombuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 6 lines
I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.-1 :)
There was some internal requirement from test team, they need to verify
Quoted 6 lines
Quoted 1 line
Internal QA requirements may not be the driving factor :-)
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
In addition to additional if check, The real concern is polluting the common forward engine for the not common feature.
If you really want to reuse the existing application without any application change,
I think, you need to hook this to eventdev
http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34
Where eventdev drivers does this thing in addition to other features, Ie. t has ports (which is kind of aggregator),
it can receive the packets from any queue with mbuf->port as actually received port.
That is in terms of mapping:
- event queue will be dummy it will be as same as Rx queue
- Rx adapter will be also a dummy
- event ports aggregate multiple queues and connect to core via event port
- On Rxing the packet, mbuf->port will be the actual Port which is received. app/test-eventdev written to use this model.
Quoted 217 lines
Quoted 216 lines
Quoted 216 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 175 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 213 lines · Jerin Jacob
Quoted 212 lines · Xueming(Steven) Li
Quoted 209 lines · Jerin Jacob
Quoted 198 lines · Xueming(Steven) Li
Quoted 196 lines · Konstantin
Quoted 195 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
Quoted 2 lines · Xueming(Steven) Li
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>; NBU-Contact-Thomas
MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
<[email protected]> wrote:Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
receive queue, In that case, how the flow order is
maintained for respective receive queues.I guess the question is testpmd forward stream? The
forwarding logic has to be changed slightly in case
of shared rxq.
basically for each packet in rx_burst result, lookup
source stream according to mbuf->port, forwarding to
target fs.
Packets from same source port could be grouped as a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do
shard rxq forwarding, call it with packets handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.Quoted 6 lines
Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.-1 :)
There was some internal requirement from test team, they need to verifyInternal QA requirements may not be the driving factor :-)
Quoted 7 lines
Quoted 4 lines
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
In addition to additional if check, The real concern is polluting the common forward engine for the not common feature.
Okay, removed changes to common forward engines in v4, please check.
Quoted 6 lines
If you really want to reuse the existing application without any application change,
I think, you need to hook this to eventdev
http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34
Quoted 10 lines
Where eventdev drivers does this thing in addition to other features, Ie. t has ports (which is kind of aggregator),
it can receive the packets from any queue withmbuf->portas actually received port.
That is in terms of mapping:
- event queue will be dummy it will be as same as Rx queue
- Rx adapter will be also a dummy
- event ports aggregate multiple queues and connect to core via event port
- On Rxing the packet,mbuf->portwill be the actual Port which is received. app/test-eventdev written to use this model.
Is this the optional aggregator api we discussed? already there, patch 2/6.
I was trying to make common forwarding engines perfect to support any case, but since you all have concerns, removed in v4.
Quoted 220 lines
Quoted 220 lines
Quoted 219 lines
Quoted 219 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
scope.
It works for both PF and representors in same switch
domain, for application like OVS, few changes to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 220 lines · Xueming(Steven) Li
Quoted 218 lines · Jerin Jacob
Quoted 216 lines · Xueming(Steven) Li
Quoted 203 lines · Jerin Jacob
Quoted 202 lines · Xueming(Steven) Li
Quoted 199 lines · Konstantin
Quoted 189 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
Quoted 3 lines · Ferruh Yigit
On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>; NBU-Contact-Thomas
MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
<[email protected]> wrote:Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
receive queue, In that case, how the flow order is
maintained for respective receive queues.I guess the question is testpmd forward stream? The
forwarding logic has to be changed slightly in case
of shared rxq.
basically for each packet in rx_burst result, lookup
source stream according to mbuf->port, forwarding to
target fs.
Packets from same source port could be grouped as a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 16 lines
limited ports. I'll introduce some common api to do
shard rxq forwarding, call it with packets handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue
(share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 6 lines
I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
Quoted 2 lines
-1 :)
There was some internal requirement from test team, they need to verifyInternal QA requirements may not be the driving factor :-)
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
Quoted 4 lines
Quoted 2 lines
In addition to additional if check, The real concern is polluting the common forward engine for the not common feature.
Okay, removed changes to common forward engines in v4, please check.
Thanks.
Quoted 18 lines
Quoted 7 lines
If you really want to reuse the existing application without any application change,
I think, you need to hook this to eventdev
http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34Quoted 10 lines
Where eventdev drivers does this thing in addition to other features, Ie. t has ports (which is kind of aggregator),
it can receive the packets from any queue withmbuf->portas actually received port.
That is in terms of mapping:
- event queue will be dummy it will be as same as Rx queue
- Rx adapter will be also a dummy
- event ports aggregate multiple queues and connect to core via event port
- On Rxing the packet,mbuf->portwill be the actual Port which is received. app/test-eventdev written to use this model.
Quoted 4 lines
Is this the optional aggregator api we discussed? already there, patch 2/6.
I was trying to make common forwarding engines perfect to support any case, but since you all have concerns, removed in v4.
The point was, If we take eventdev Rx adapter path, This all thing can be implemented
without adding any new APIs in ethdev as similar functionality is supported ethdeev-eventdev
Rx adapter. Now two things,
1) Aggregator API is not required, We will be taking the eventdev Rx adapter route this implement it
2) Another mode it is possible to implement it with eventdev Rx adapter. So I leave to ethdev
maintainers to decide if this path is required or not. No strong opinion on this.
Quoted 223 lines
Quoted 222 lines
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port
represontors? If so can't we
have a port representor specific solution, reducing
scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
scope.
It works for both PF and representors in same switch
domain, for application like OVS, few changes to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 257 lines · Jerin Jacob
Quoted 220 lines · Xueming(Steven) Li
Quoted 218 lines · Jerin Jacob
Quoted 216 lines · Xueming(Steven) Li
Quoted 203 lines · Jerin Jacob
Quoted 202 lines · Xueming(Steven) Li
Quoted 199 lines · Konstantin
Quoted 189 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
Quoted 5 lines · Xueming(Steven) Li
On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit wrote:
On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>; NBU-Contact-Thomas
MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
<[email protected]> wrote:Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
receive queue, In that case, how the flow order is
maintained for respective receive queues.I guess the question is testpmd forward stream? The
forwarding logic has to be changed slightly in case
of shared rxq.
basically for each packet in rx_burst result, lookup
source stream according to mbuf->port, forwarding to
target fs.
Packets from same source port could be grouped as a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 22 lines
limited ports. I'll introduce some common api to do
shard rxq forwarding, call it with packets handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue
(share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent way to
the application?Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule
polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 6 lines
I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
Quoted 2 lines
-1 :)
There was some internal requirement from test team, they need to verifyInternal QA requirements may not be the driving factor :-)
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
Quoted 4 lines
Quoted 2 lines
In addition to additional if check, The real concern is polluting the common forward engine for the not common feature.
Okay, removed changes to common forward engines in v4, please check.
Thanks.
Quoted 18 lines
Quoted 7 lines
If you really want to reuse the existing application without any application change,
I think, you need to hook this to eventdev
http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34Quoted 10 lines
Where eventdev drivers does this thing in addition to other features, Ie. t has ports (which is kind of aggregator),
it can receive the packets from any queue withmbuf->portas actually received port.
That is in terms of mapping:
- event queue will be dummy it will be as same as Rx queue
- Rx adapter will be also a dummy
- event ports aggregate multiple queues and connect to core via event port
- On Rxing the packet,mbuf->portwill be the actual Port which is received. app/test-eventdev written to use this model.Quoted 4 lines
Is this the optional aggregator api we discussed? already there, patch 2/6.
I was trying to make common forwarding engines perfect to support any case, but since you all have concerns, removed in v4.The point was, If we take eventdev Rx adapter path, This all thing can be implemented
without adding any new APIs in ethdev as similar functionality is supported ethdeev-eventdev
Rx adapter. Now two things,
Quoted 6 lines
1) Aggregator API is not required, We will be taking the eventdev Rx adapter route this implement it
2) Another mode it is possible to implement it with eventdev Rx adapter. So I leave to ethdev
maintainers to decide if this path is required or not. No strong opinion on this.
Seems you are expert of event, is this the Rx burst api? rte_event_dequeue_burst(dev_id, port_id, ev[], nb_events, timeout)
Two concerns from user perspective:
1. By using ethdev-eventdev wrapper, it impacts performance.
2. For user application like OVS, using event api just when shared rxq enable looks strange.
Maybe I missed something?
There should be more feedkback and idea on how to aggregate ports after the fundamental(offload bit and group) start to work, agree to remove the aggregator api for now.
Quoted 226 lines
Quoted 226 lines
Quoted 225 lines
Quoted 225 lines
Quoted 224 lines
Quoted 224 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port
represontors? If so can't we
have a port representor specific solution, reducing
scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
scope.
It works for both PF and representors in same switch
domain, for application like OVS, few changes to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 266 lines · Xueming(Steven) Li
Quoted 257 lines · Jerin Jacob
Quoted 220 lines · Xueming(Steven) Li
Quoted 218 lines · Jerin Jacob
Quoted 216 lines · Xueming(Steven) Li
Quoted 203 lines · Jerin Jacob
Quoted 202 lines · Xueming(Steven) Li
Quoted 199 lines · Konstantin
Quoted 189 lines
Quoted 13 lines · Xueming(Steven) Li
Quoted 11 lines · Jerin Jacob
Quoted 9 lines · Xueming(Steven) Li
Quoted 7 lines · Jerin Jacob
On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li
<[email protected]> wrote:On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit wrote:
On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>; NBU-Contact-Thomas
MonjalonQuoted 72 lines
Quoted 72 lines
Quoted 72 lines
Quoted 72 lines
Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
<[email protected]> wrote:Hi,
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit
<[email protected]>;
NBU-Contact-Thomas Monjalon
<[email protected]>; Andrew Rybchenko
<[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
introduce shared Rx queueOn Mon, Aug 9, 2021 at 5:18 PM Xueming Li
<[email protected]> wrote:In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question.
The control path of is
almost same as before, PF and representor port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
receive queue, In that case, how the flow order is
maintained for respective receive queues.I guess the question is testpmd forward stream? The
forwarding logic has to be changed slightly in case
of shared rxq.
basically for each packet in rx_burst result, lookup
source stream according to mbuf->port, forwarding to
target fs.
Packets from same source port could be grouped as a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 29 lines
limited ports. I'll introduce some common api to do
shard rxq forwarding, call it with packets handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue
(share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent way to
the application?Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule
polling on the
aggregated port instead of all member ports.The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd
application. Instead, testpmd can use aggregated ports
probably as
separate fwd_engine to show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 6 lines
I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
Quoted 2 lines
-1 :)
There was some internal requirement from test team, they need to verifyInternal QA requirements may not be the driving factor :-)
It will be a test requirement for any driver to face, not internal. The performance difference almost zero in v3, only an "unlikely if" test on each burst. Shared Rxq is a low level feature, reusing all current FWD engines to verify driver high level features is important IMHO.
Quoted 4 lines
Quoted 2 lines
In addition to additional if check, The real concern is polluting the common forward engine for the not common feature.
Okay, removed changes to common forward engines in v4, please check.
Thanks.
Quoted 18 lines
Quoted 7 lines
If you really want to reuse the existing application without any application change,
I think, you need to hook this to eventdev
http://code.dpdk.org/dpdk/latest/source/lib/eventdev/rte_eventdev.h#L34Quoted 10 lines
Where eventdev drivers does this thing in addition to other features, Ie. t has ports (which is kind of aggregator),
it can receive the packets from any queue withmbuf->portas actually received port.
That is in terms of mapping:
- event queue will be dummy it will be as same as Rx queue
- Rx adapter will be also a dummy
- event ports aggregate multiple queues and connect to core via event port
- On Rxing the packet,mbuf->portwill be the actual Port which is received. app/test-eventdev written to use this model.Quoted 4 lines
Is this the optional aggregator api we discussed? already there, patch 2/6.
I was trying to make common forwarding engines perfect to support any case, but since you all have concerns, removed in v4.The point was, If we take eventdev Rx adapter path, This all thing can be implemented
without adding any new APIs in ethdev as similar functionality is supported ethdeev-eventdev
Rx adapter. Now two things,Quoted 6 lines
1) Aggregator API is not required, We will be taking the eventdev Rx adapter route this implement it
2) Another mode it is possible to implement it with eventdev Rx adapter. So I leave to ethdev
maintainers to decide if this path is required or not. No strong opinion on this.
Quoted 2 lines
Seems you are expert of event, is this the Rx burst api?
rte_event_dequeue_burst(dev_id, port_id, ev[], nb_events, timeout)
Yes.
Quoted 3 lines
Two concerns from user perspective:
1. By using ethdev-eventdev wrapper, it impacts performance.
It is not a wrapper. If HW doing the work then there will not be any regression with the Rx adapter.
Like tx_burst, packet/event comes through rte_event_dequeue_burst() aka single callback function pointer overhead.
Quoted 8 lines
2. For user application like OVS, using event api just when shared rxq enable looks strange.
Maybe I missed something?
There should be more feedkback and idea on how to aggregate ports after the fundamental(offload bit and group) start to work, agree to remove the aggregator api for now.
OK.
Quoted 228 lines
Quoted 227 lines
Quoted 227 lines
Quoted 226 lines
Quoted 226 lines
Quoted 225 lines
Quoted 225 lines
all features like packet content, rss, vlan, checksum,
rte_flow... to be working based on shared rx queue. Based on the patch, I believe the impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port
represontors? If so can't we
have a port representor specific solution, reducing
scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
scope.
It works for both PF and representors in same switch
domain, for application like OVS, few changes to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 149 lines
Quoted 149 lines
Quoted 148 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 48 lines
Quoted 33 lines
In current DPDK framework, each RX queue is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption became
significant. Most
important, polling all ports leads to high
cache miss, high
latency and low throughput.This patch introduces shared RX queue. Ports
with same
configuration in a switch domain could share
RX queue set by specifying sharing group.
Polling any queue using same shared RX queue
receives packets from
all member ports. Source port is identified
by mbuf->port.Port queue number in a shared group should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain could take advantage.
Quoted 2 lines
If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your question. The control path of is
almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be
supplied from shared Rx queue in my PMD implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land intothe same
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 2 lines
receive queue, In that case, how the flow order is maintained for respective receive queues.
I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq.
basically for each packet inrx_burstresult, lookup source stream according tombuf->port, forwarding to target fs.
Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if trafficcome from
Quoted 42 lines
Quoted 38 lines
Quoted 30 lines
Quoted 23 lines
Quoted 17 lines
Quoted 12 lines
Quoted 5 lines
limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will happen if there are
multiple cores polling, won't it cause problem?Quoted 4 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to the application?Quoted 5 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 6 lines
The v3 still has testpmd changes in fastpath. Right? IMO, For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 7 lines
Good point to discuss :) There are two strategies to polling a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 3 lines
Not unfortunately. More than that, every application needs to change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it
comes to application.Quoted 11 lines
Quoted 10 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie.
without application change in fastpath
logic.Quoted 8 lines
Fastpath have to resolve port ID anyway and forwarding according to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Let's defer part 2 until some PMD really support it and tested, how do
you think?We are not planning to use this feature so either way it is OK to me.
I leave to ethdev maintainers decide between 1 vs 2.I do have a strong opinion not changing the testpmd basic forward engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this feature.
Quoted 8 lines
Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.-1 :)
There was some internal requirement from test team, they need to verify all features like packet content, rss, vlan, checksum,rte_flow... to be working based on shared rx queue.
Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though different fwd_stream (TX through different HW queue). In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute basic fwd cases with it.
BTW, as a side note, the code below looks bogus to me:
+void
+forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx,
+ struct rte_mbuf **pkts_burst, packet_fwd_cb fwd)
+{
+ uint16_t i, nb_fs_rx = 1, port;
+
+ /* Locate real source fs according to mbuf->port. */
+ for (i = 0; i < nb_rx; ++i) {
+ rte_prefetch0(pkts_burst[i + 1]);
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.
Quoted 210 lines
Based on the patch, I believe the
impact has been minimized.Quoted 207 lines
Quoted 207 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its
name and
Quoted 186 lines
Quoted 185 lines
Quoted 185 lines
Quoted 183 lines
Quoted 183 lines
Quoted 182 lines
Quoted 181 lines
Quoted 1 line
scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 175 lines
Quoted 175 lines
Quoted 175 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
| 11 +++++++++++
doc/guides/nics/features/default.ini
| 1 +
doc/guides/prog_guide/switch_representation.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
| 1 +
lib/ethdev/rte_ethdev.h
| 7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner packet L4
checksum.
``tx_offload_capa,tx_queue_offload_capa:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand =
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representation
.rst
b/doc/guides/prog_guide/switch_representation
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representation
.rst
+++
b/doc/guides/prog_guide/switch_representation
.rst
@@ -123,6 +123,16 @@ thought as a software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver model
(switchdev)<https://www.kernel.org/doc/Documentation/net
working/switchdev.txt
`_+- Memory usage of representors is huge when
number of representor
+grows,
+ because PMD always allocate mbuf for each
descriptor of Rx queue.
+ Polling the large number of ports brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability of
device info. Setting
+the
+ offloading flag in device Rx mode or Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member port
of shared Rx queue can
+return
+ packets of all ports in group, port ID is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**< Do
not start queue with rte_eth_dev_start(). */
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**< Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@ struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_OFFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 196 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 60 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet inrx_burstresult,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according tombuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 15 lines
Quoted 7 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?Quoted 5 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.
Quoted 4 lines
Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
The shared Rxq is low level feature, need to make sure driver higher level features working properly. fwd-engines like csum checks input packet and enable L3/L4 checksum and tunnel offloads accordingly, other engines do their own feature verification. All test automation could be reused with these engines supported seamlessly.
Quoted 3 lines
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
Yes, each mbuf in burst come from differnt port, testpmd current fwd- engines relies heavily on source forwarding stream, that's why the patch devide burst result mbufs into sub-burst and use orginal fwd- engine callback to handle. How to handle is not changed.
Quoted 6 lines
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality. But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.
Shared Rxq is a ethdev feature that impacts how packets get handled. It's natural to update forwarding engines to avoid broken. The new macro is introduced to minimize performance impact, I'm also wondering is there an elegant solution :) Current performance penalty is one "if unlikely" per burst.
Think in reverse direction, if we don't update fwd-engines here, all malfunction when shared rxq enabled, users can't verify driver features, are you expecting this?
Quoted 264 lines
BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Quoted 246 lines
Based on the patch, I believe the
impact has been minimized.Quoted 243 lines
Quoted 243 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
Quoted 219 lines
Quoted 219 lines
Quoted 218 lines
Quoted 217 lines
Quoted 1 line
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes to
apply.Quoted 210 lines
Quoted 210 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ`
`.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.ini
+++
b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representa
tion
.rst
b/doc/guides/prog_guide/switch_representa
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representa
tion
.rst
+++
b/doc/guides/prog_guide/switch_representa
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver
model
(switchdev)<https://www.kernel.org/doc/Documentation
/net
working/switchdev.txt
`_+- Memory usage of representors is huge
when
number of representor
+grows,
+ because PMD always allocate mbuf for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used
to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability
of
device info. Setting
+the
+ offloading flag in device Rx mode or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member
port
of shared Rx queue can
+return
+ packets of all ports in group, port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**<
Do
not start queue with rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@
struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 223 lines
Quoted 196 lines
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet inrx_burstresult,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according tombuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 15 lines
Quoted 7 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?Quoted 5 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Quoted 4 lines
Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.The shared Rxq is low level feature, need to make sure driver higher level features working properly. fwd-engines like csum checks input packet and enable L3/L4 checksum and tunnel offloads accordingly, other engines do their own feature verification. All test automation could be reused with these engines supported seamlessly.
Quoted 3 lines
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).Yes, each mbuf in burst come from differnt port, testpmd current fwd- engines relies heavily on source forwarding stream, that's why the patch devide burst result mbufs into sub-burst and use orginal fwd- engine callback to handle. How to handle is not changed.
Quoted 6 lines
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality. But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.
Quoted 2 lines
Shared Rxq is a ethdev feature that impacts how packets get handled. It's natural to update forwarding engines to avoid broken.
Why is that?
All it affects the way you RX the packets.
So why *all* FWD engines have to be updated?
Let say what specific you are going to test with macswap vs macfwd mode for that feature? I still think one specific FWD engine is enough to cover majority of test cases.
Quoted 2 lines
The new macro is introduced to minimize performance impact, I'm also wondering is there an elegant solution :)
I think Jerin suggested a good alternative with eventdev.
As another approach - might be consider to add an RX callback that will return packets only for one particular port (while keeping packets for other ports cached internally).
As a 'wild' thought - change testpmd fwd logic to allow multiple TX queues per fwd_stream and add a function to do TX switching logic. But that's probably quite a big change that needs a lot of work.
Quoted 2 lines
Current performance penalty
is one "if unlikely" per burst.
It is not only about performance impact.
It is about keeping test-pmd code simple and maintainable.
Quoted 4 lines
Think in reverse direction, if we don't update fwd-engines here, all malfunction when shared rxq enabled, users can't verify driver features, are you expecting this?
I expect developers not to rewrite whole test-pmd fwd code for each new ethdev feature. Specially for the feature that is not widely used.
Quoted 265 lines
Quoted 265 lines
BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Quoted 246 lines
Based on the patch, I believe the
impact has been minimized.Quoted 243 lines
Quoted 243 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
Quoted 219 lines
Quoted 219 lines
Quoted 218 lines
Quoted 217 lines
Quoted 1 line
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes to
apply.Quoted 210 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ`
`.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.ini
+++
b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representa
tion
.rst
b/doc/guides/prog_guide/switch_representa
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representa
tion
.rst
+++
b/doc/guides/prog_guide/switch_representa
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver
model
(switchdev)<https://www.kernel.org/doc/Documentation
/net
working/switchdev.txt
`_+- Memory usage of representors is huge
when
number of representor
+grows,
+ because PMD always allocate mbuf for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used
to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability
of
device info. Setting
+the
+ offloading flag in device Rx mode or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member
port
of shared Rx queue can
+return
+ packets of all ports in group, port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**<
Do
not start queue with rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@
struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 267 lines · Konstantin
Quoted 267 lines
Quoted 234 lines
Quoted 225 lines
Quoted 221 lines
Quoted 212 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
In current DPDK framework, each RX
queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX
queue.
Ports
with same
configuration in a switch domain
could
share
RX queue set by specifying sharing
group.
Polling any queue using same shared
RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be
polled
on
same thread.Multiple groups is supported by group
ID.Is this offload specific to the
representor? If
so can this name be changed
specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the
flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload,
multiple
ethdev receive queues land intothe same
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
receive queue, In that case, how the flow
order
is
maintained for respective receive queues.I guess the question is testpmd forward
stream?
The
forwarding logic has to be changed slightly
in
case
of shared rxq.
basically for each packet in rx_burst result,
lookup
source stream according to mbuf->port,
forwardingQuoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
to
target fs.
Packets from same source port could be
grouped as
a
small burst to process, this will accelerates
the
performance if trafficcome from
Quoted 63 lines
Quoted 57 lines
Quoted 46 lines
Quoted 35 lines
Quoted 26 lines
Quoted 19 lines
Quoted 9 lines
limited ports. I'll introduce some common api
to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches
soon.All ports will put the packets in to the same
queue
(share queue), right? Does
this means only single core will poll only,
what
will
happen if there are
multiple cores polling, won't it cause problem?Quoted 6 lines
And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent
way
to
the application?Quoted 8 lines
Discussed with Jerin, new API introduced in v3
2/8
that
aggregate ports
in same group into one new port. Users could
schedule
polling on the
aggregated port instead of all member ports.Quoted 10 lines
The v3 still has testpmd changes in fastpath.
Right?
IMO,
For this
feature, we should not change fastpath of testpmd
application. Instead, testpmd can use aggregated
ports
probably as
separatefwd_engineto show how to use this
feature.Quoted 10 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction.
Does your PMD support this?Quoted 5 lines
Not unfortunately. More than that, every application needs
to
change
to support this model.Quoted 7 lines
Both strategies need user application to resolve port ID from
mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule
change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 25 lines
Quoted 9 lines
Quoted 8 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo
it.
This is an optional API, not supported by my PMD yet.Quoted 6 lines
We are thinking of implementing this PMD when it comes to
it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq.
Fortunately, in testpmd, this can be done with an abstract
API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK
to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 8 lines
-1 :)
There was some internal requirement from test team, they need to
verify
all features like packet content, rss, vlan, checksum,rte_flow...
to
be working based on shared rx queue.Quoted 5 lines
Then I suppose you'll need to write really comprehensive fwd- engine
to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.The shared Rxq is low level feature, need to make sure driver higher
level features working properly. fwd-engines like csum checks input packet and enable L3/L4 checksum and tunnel offloads accordingly, other engines do their own feature verification. All test automation
could be reused with these engines supported seamlessly.Quoted 4 lines
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different
HW queue).Yes, each mbuf in burst come from differnt port, testpmd current fwd-
engines relies heavily on source forwarding stream, that's why the patch devide burst result mbufs into sub-burst and use orginal fwd- engine callback to handle. How to handle is not changed.Quoted 7 lines
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality. But current implementation looks very case specific. And as I don't think it is a common case, I don't see much point to
pollute
basic fwd cases with it.
Quoted 7 lines
Quoted 3 lines
Shared Rxq is a ethdev feature that impacts how packets get handled.
It's natural to update forwarding engines to avoid broken.Why is that?
All it affects the way you RX the packets.
So why *all* FWD engines have to be updated?
People will ask why some FWD engine can't work?
Quoted 2 lines
Let say what specific you are going to test with macswap vs macfwd mode for that feature?
If people want to test NIC with real switch, or make sure L2 layer not get corrupted.
Quoted 2 lines
I still think one specific FWD engine is enough to cover majority of test cases.
Yes, rxonly should be sufficient to verify the fundametal, but to verify csum, timing, need others. Some back2back test system need io forwarding, real switch depolyment need macswap...
Quoted 10 lines
Quoted 4 lines
The new macro is introduced to minimize performance impact, I'm also
wondering is there an elegant solution :)I think Jerin suggested a good alternative with eventdev. As another approach - might be consider to add an RX callback that will return packets only for one particular port (while keeping packets
for other ports cached internally).
This and the aggreate port API could be options in ethdev layer later. It can't be the fundamental due performance loss and potential cache miss.
Quoted 11 lines
As a 'wild' thought - change testpmd fwd logic to allow multiple TX queues
perfwd_streamand add a function to do TX switching logic. But that's probably quite a big change that needs a lot of work.Quoted 2 lines
Current performance penalty
is one "if unlikely" per burst.It is not only about performance impact.
It is about keeping test-pmd code simple and maintainable.Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Think in reverse direction, if we don't update fwd-engines here, all
malfunction when shared rxq enabled, users can't verify driver features, are you expecting this?I expect developers not to rewrite whole test-pmd fwd code for each new ethdev feature.
Here just abstract duplicated code from fwd-engines, an improvement, keep test-pmd code simple and mantainable.
Quoted 1 line
Specially for the feature that is not widely used.
Based on the huge memory saving, performance and latency gains, it will be popular to users.
But the test-pmd is not critical to this feature, I'm ok to drop the fwd-engine support if you agree.
Quoted 313 lines
Quoted 312 lines
Quoted 312 lines
BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Quoted 292 lines
Based on the patch, I believe the
impact has been minimized.Quoted 289 lines
Quoted 289 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Overall, is this for optimizing memory for the
port
represontors? If so can't we
have a port representor specific solution,
reducing
scope can reduce the
complexity it brings?Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
If this offload is only useful for
representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 265 lines
Quoted 264 lines
Quoted 264 lines
Quoted 262 lines
Quoted 262 lines
Quoted 261 lines
Quoted 260 lines
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes
to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_represe
ntat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git
a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload
_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports
in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_
RXQ`
`.
+* **[provides] mbuf**:
``mbuf.port``.
+
+
..
_nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.in
i
b/doc/guides/nics/features/default.in
i
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.in
i
+++
b/doc/guides/nics/features/default.in
i
@@ -19,6 +19,7 @@ Free Tx mbuf on
demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_repres
enta
tion
.rst
b/doc/guides/prog_guide/switch_repres
enta
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_repres
enta
tion
.rst
+++
b/doc/guides/prog_guide/switch_repres
enta
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for
applications.
.. [1] `Ethernet switch device
driver
model
(switchdev)<https://www.kernel.org/doc/Documenta
tion
/net
working/switchdev.txt
`_+- Memory usage of representors is
huge
when
number of representor
+grows,
+ because PMD always allocate mbuf
for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be
used
to
share Rx queue between
+PF and
+ representors in same switch
domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading
capability
of
device info. Setting
+the
+ offloading flag in device Rx mode
or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any
member
port
of shared Rx queue can
+return
+ packets of all ports in group,
port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const
struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_
UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HA
SH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BU
FFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ
),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start;
/**<
Do
not start queue with
rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number
of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to
be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12
@@
struct
rte_eth_conf {
#define
DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define
RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port
in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define
RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_
RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 274 lines · Konstantin
Quoted 271 lines
Quoted 270 lines
Quoted 234 lines
Quoted 225 lines
Quoted 221 lines
Quoted 212 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
Quoted 70 lines
In current DPDK framework, each RX
queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX
queue.
Ports
with same
configuration in a switch domain
could
share
RX queue set by specifying sharing
group.
Polling any queue using same shared
RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be
polled
on
same thread.Multiple groups is supported by group
ID.Is this offload specific to the
representor? If
so can this name be changed
specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the
flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload,
multiple
ethdev receive queues land intothe same
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
receive queue, In that case, how the flow
order
is
maintained for respective receive queues.I guess the question is testpmd forward
stream?
The
forwarding logic has to be changed slightly
in
case
of shared rxq.
basically for each packet in rx_burst result,
lookup
source stream according to mbuf->port,
forwardingQuoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
to
target fs.
Packets from same source port could be
grouped as
a
small burst to process, this will accelerates
the
performance if trafficcome from
Quoted 63 lines
Quoted 57 lines
Quoted 46 lines
Quoted 35 lines
Quoted 26 lines
Quoted 25 lines
limited ports. I'll introduce some common api
to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches
soon.All ports will put the packets in to the same
queue
(share queue), right? Does
this means only single core will poll only,
what
will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent
way
to
the application?Quoted 8 lines
Discussed with Jerin, new API introduced in v3
2/8
that
aggregate ports
in same group into one new port. Users could
schedule
polling on the
aggregated port instead of all member ports.Quoted 10 lines
The v3 still has testpmd changes in fastpath.
Right?
IMO,
For this
feature, we should not change fastpath of testpmd
application. Instead, testpmd can use aggregated
ports
probably as
separatefwd_engineto show how to use this
feature.Quoted 10 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction.
Does your PMD support this?Quoted 5 lines
Not unfortunately. More than that, every application needs
to
change
to support this model.Quoted 7 lines
Both strategies need user application to resolve port ID from
mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule
change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 25 lines
Quoted 9 lines
Quoted 8 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo
it.
This is an optional API, not supported by my PMD yet.Quoted 6 lines
We are thinking of implementing this PMD when it comes to
it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq.
Fortunately, in testpmd, this can be done with an abstract
API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK
to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 8 lines
-1 :)
There was some internal requirement from test team, they need to
verify
all features like packet content, rss, vlan, checksum,rte_flow...
to
be working based on shared rx queue.Quoted 5 lines
Then I suppose you'll need to write really comprehensive fwd- engine
to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.The shared Rxq is low level feature, need to make sure driver higher
level features working properly. fwd-engines like csum checks input packet and enable L3/L4 checksum and tunnel offloads accordingly, other engines do their own feature verification. All test automation
could be reused with these engines supported seamlessly.Quoted 4 lines
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different
HW queue).Yes, each mbuf in burst come from differnt port, testpmd current fwd-
engines relies heavily on source forwarding stream, that's why the patch devide burst result mbufs into sub-burst and use orginal fwd- engine callback to handle. How to handle is not changed.Quoted 7 lines
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality. But current implementation looks very case specific. And as I don't think it is a common case, I don't see much point to
pollute
basic fwd cases with it.Shared Rxq is a ethdev feature that impacts how packets get handled.
It's natural to update forwarding engines to avoid broken.
Quoted 5 lines
Quoted 3 lines
Why is that?
All it affects the way you RX the packets.
So why *all* FWD engines have to be updated?People will ask why some FWD engine can't work?
It can be documented: which fwd engine supposed to work properly with this feature, which not.
BTW, as I understand, as long as RX queues are properly assigned to lcores, any fwd engine will continue to work.
Just for engines that are not aware about this feature packets can be send out via wrong TX queue.
Quoted 5 lines
Quoted 2 lines
Let say what specific you are going to test with macswap vs macfwd mode for that feature?
If people want to test NIC with real switch, or make sure L2 layer not get corrupted.
I understand that, what I am saying that you probably don't need both to test this feature.
Quoted 6 lines
Quoted 2 lines
I still think one specific FWD engine is enough to cover majority of test cases.
Yes, rxonly should be sufficient to verify the fundametal, but to verify csum, timing, need others. Some back2back test system need io forwarding, real switch depolyment need macswap...
Ok, but nothing stops you to pickup for your purposes a FWD engine with most comprehensive functionality:
macswap, 5tswap, even 5tswap+csum update ....
Quoted 39 lines
Quoted 7 lines
Quoted 6 lines
The new macro is introduced to minimize performance impact, I'm also
wondering is there an elegant solution :)Quoted 5 lines
I think Jerin suggested a good alternative with eventdev. As another approach - might be consider to add an RX callback that will return packets only for one particular port (while keeping packets
for other ports cached internally).This and the aggreate port API could be options in ethdev layer later. It can't be the fundamental due performance loss and potential cache miss.
Quoted 11 lines
As a 'wild' thought - change testpmd fwd logic to allow multiple TX queues
perfwd_streamand add a function to do TX switching logic. But that's probably quite a big change that needs a lot of work.Quoted 2 lines
Current performance penalty
is one "if unlikely" per burst.It is not only about performance impact.
It is about keeping test-pmd code simple and maintainable.Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Think in reverse direction, if we don't update fwd-engines here, all
malfunction when shared rxq enabled, users can't verify driver features, are you expecting this?I expect developers not to rewrite whole test-pmd fwd code for each new ethdev feature.
Here just abstract duplicated code from fwd-engines, an improvement, keep test-pmd code simple and mantainable.
Quoted 7 lines
Quoted 1 line
Specially for the feature that is not widely used.
Based on the huge memory saving, performance and latency gains, it will be popular to users.
But the test-pmd is not critical to this feature, I'm ok to drop the fwd-engine support if you agree.
Not sure fully understand you here...
If you saying that you decided to demonstrate this feature via some other app/example and prefer to abandon these changes in testpmd -
then, yes I don't see any problems with that.
On Thu, 2021-09-30 at 09:59 +0000, Ananyev, Konstantin wrote:
On Wed, 2021-09-29 at 10:20 +0000, Ananyev, Konstantin wrote:
In current DPDK framework, each RX
queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.
This patch introduces shared RX
queue.
Ports
with same
configuration in a switch domain
could
share
RX queue set by specifying sharing
group.
Polling any queue using same shared
RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.
Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.
Share RX queue is supposed to be
polled
on
same thread.
Multiple groups is supported by group
ID.
Is this offload specific to the
representor? If
so can this name be changed
specifically to
representor?
Yes, PF and representor in switch domain
could
take advantage.
If it is for a generic case, how the
flow
ordering will be maintained?
Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload,
multiple
ethdev receive queues land into
the same
receive queue, In that case, how the flow
order
is
maintained for respective receive queues.
I guess the question is testpmd forward
stream?
The
forwarding logic has to be changed slightly
in
case
of shared rxq.
basically for each packet in rx_burst result,
lookup
source stream according to mbuf->port,
forwarding
to
target fs.
Packets from same source port could be
grouped as
a
small burst to process, this will accelerates
the
performance if traffic
come from
limited ports. I'll introduce some common api
to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches
soon.
All ports will put the packets in to the same
queue
(share queue), right? Does
this means only single core will poll only,
what
will
happen if there are
multiple cores polling, won't it cause problem?
And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent
way
to
the application?
Discussed with Jerin, new API introduced in v3
2/8
that
aggregate ports
in same group into one new port. Users could
schedule
polling on the
aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath.
Right?
IMO,
For this
feature, we should not change fastpath of testpmd
application. Instead, testpmd can use aggregated
ports
probably as
separate fwd_engine to show how to use this
feature.
Good point to discuss :) There are two strategies to
polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as
before.
My testpmd patches are efforts towards this
direction.
Does your PMD support this?
Not unfortunately. More than that, every application
needs
to
change
to support this model.
Both strategies need user application to resolve port ID
from
mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling
schedule
change.
I was thinking, mbuf will be updated from driver/aggregator
port as
when it
comes to application.
2. polling aggregated port
Besides forwarding engine, need more work to to
demo
it.
This is an optional API, not supported by my PMD
yet.
We are thinking of implementing this PMD when it comes
to
it,
ie.
without application change in fastpath
logic.
Fastpath have to resolve port ID anyway and forwarding
according
to
logic. Forwarding engine need to adapt to support shard
Rxq.
Fortunately, in testpmd, this can be done with an
abstract
API.
Let's defer part 2 until some PMD really support it and
tested,
how do
you think?
We are not planning to use this feature so either way it is
OK
to
me.
I leave to ethdev maintainers decide between 1 vs 2.
I do have a strong opinion not changing the testpmd basic
forward
engines
for this feature.I would like to keep it simple as fastpath
optimized and would
like to add a separate Forwarding engine as means to verify
this
feature.
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.
-1 :)
There was some internal requirement from test team, they need
to
verify
all features like packet content, rss, vlan, checksum,
rte_flow...
to
be working based on shared rx queue.
Then I suppose you'll need to write really comprehensive fwd-
engine
to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all
available fwd-engines to verify this feature.
The shared Rxq is low level feature, need to make sure driver
higher
level features working properly. fwd-engines like csum checks input
packet and enable L3/L4 checksum and tunnel offloads accordingly,
other engines do their own feature verification. All test
automation
could be reused with these engines supported seamlessly.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though different fwd_stream (TX through
different
HW queue).
Yes, each mbuf in burst come from differnt port, testpmd current
fwd-
engines relies heavily on source forwarding stream, that's why the
patch devide burst result mbufs into sub-burst and use orginal fwd-
engine callback to handle. How to handle is not changed.
In theory, if implemented in generic and extendable way - that
might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point
to
pollute
basic fwd cases with it.
Shared Rxq is a ethdev feature that impacts how packets get
handled.
It's natural to update forwarding engines to avoid broken.
Why is that?
All it affects the way you RX the packets.
So why *all* FWD engines have to be updated?
People will ask why some FWD engine can't work?
It can be documented: which fwd engine supposed to work properly
with this feature, which not.
BTW, as I understand, as long as RX queues are properly assigned to lcores,
any fwd engine will continue to work.
Just for engines that are not aware about this feature packets can be send
out via wrong TX queue.
Let say what specific you are going to test with macswap vs macfwd
mode for that feature?
If people want to test NIC with real switch, or make sure L2 layer not
get corrupted.
I understand that, what I am saying that you probably don't need both to test this feature.
I still think one specific FWD engine is enough to cover majority of
test cases.
Yes, rxonly should be sufficient to verify the fundametal, but to
verify csum, timing, need others. Some back2back test system need io
forwarding, real switch depolyment need macswap...
Ok, but nothing stops you to pickup for your purposes a FWD engine with most comprehensive functionality:
macswap, 5tswap, even 5tswap+csum update ....
The new macro is introduced to minimize performance impact, I'm
also
wondering is there an elegant solution :)
I think Jerin suggested a good alternative with eventdev.
As another approach - might be consider to add an RX callback that
will return packets only for one particular port (while keeping
packets
for other ports cached internally).
This and the aggreate port API could be options in ethdev layer later.
It can't be the fundamental due performance loss and potential cache
miss.
As a 'wild' thought - change testpmd fwd logic to allow multiple TX
queues
per fwd_stream and add a function to do TX switching logic.
But that's probably quite a big change that needs a lot of work.
Current performance penalty
is one "if unlikely" per burst.
It is not only about performance impact.
It is about keeping test-pmd code simple and maintainable.
Think in reverse direction, if we don't update fwd-engines here,
all
malfunction when shared rxq enabled, users can't verify driver
features, are you expecting this?
I expect developers not to rewrite whole test-pmd fwd code for each
new ethdev feature.
Here just abstract duplicated code from fwd-engines, an improvement,
keep test-pmd code simple and mantainable.
Specially for the feature that is not widely used.
Based on the huge memory saving, performance and latency gains, it will
be popular to users.
But the test-pmd is not critical to this feature, I'm ok to drop the
fwd-engine support if you agree.
Not sure fully understand you here...
If you saying that you decided to demonstrate this feature via some other app/example
and prefer to abandon these changes in testpmd -
then, yes I don't see any problems with that.
Hi Ananyev & Jerin,
New v4 posted with a dedicate fwd engine to demonstrate this feature, do you have time to check?
Thanks,
Xueming
Quoted 222 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 60 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet inrx_burstresult,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according tombuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 15 lines
Quoted 7 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?Quoted 5 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);
Quoted 3 lines
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.
Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 248 lines
Quoted 247 lines
Based on the patch, I believe the
impact has been minimized.Quoted 243 lines
Quoted 243 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
Quoted 219 lines
Quoted 219 lines
Quoted 218 lines
Quoted 217 lines
Quoted 1 line
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes to
apply.Quoted 210 lines
Quoted 210 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ`
`.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.ini
+++
b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representa
tion
.rst
b/doc/guides/prog_guide/switch_representa
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representa
tion
.rst
+++
b/doc/guides/prog_guide/switch_representa
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver
model
(switchdev)<https://www.kernel.org/doc/Documentation
/net
working/switchdev.txt
`_+- Memory usage of representors is huge
when
number of representor
+grows,
+ because PMD always allocate mbuf for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used
to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability
of
device info. Setting
+the
+ offloading flag in device Rx mode or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member
port
of shared Rx queue can
+return
+ packets of all ports in group, port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**<
Do
not start queue with rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@
struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 233 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 222 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet inrx_burstresult,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according tombuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 15 lines
Quoted 7 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?Quoted 5 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);
Quoted 7 lines
Quoted 3 lines
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.
Quoted 249 lines
Quoted 249 lines
Quoted 248 lines
Based on the patch, I believe the
impact has been minimized.Quoted 243 lines
Quoted 243 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
Quoted 219 lines
Quoted 219 lines
Quoted 218 lines
Quoted 217 lines
Quoted 1 line
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes to
apply.Quoted 210 lines
Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ`
`.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.ini
+++
b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representa
tion
.rst
b/doc/guides/prog_guide/switch_representa
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representa
tion
.rst
+++
b/doc/guides/prog_guide/switch_representa
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver
model
(switchdev)<https://www.kernel.org/doc/Documentation
/net
working/switchdev.txt
`_+- Memory usage of representors is huge
when
number of representor
+grows,
+ because PMD always allocate mbuf for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used
to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability
of
device info. Setting
+the
+ offloading flag in device Rx mode or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member
port
of shared Rx queue can
+return
+ packets of all ports in group, port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**<
Do
not start queue with rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@
struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 5 lines · Konstantin
Quoted 5 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM
<snip>
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
(quoted diff) +3
-0+ /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 8 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.
The main point we need to take from all this is that when prefetching you need to measure perf impact of it.
In terms of the specific case of prefetching one past the end of the array, I would take the view that this is harmless in almost all cases. Unlike any prefetch of "NULL" as in the referenced mail, reading one past the end (or other small number of elements past the end) is far less likely to cause a TLB miss - and it's basically just reproducing behaviour we would expect off a HW prefetcher (though those my explicitly never cross page boundaries). However, if you feel it's just cleaner to put in an additional condition to remove the prefetch for the end case, that's ok also - again so long as it doesn't affect performance. [Since prefetch is a hint, I'm not sure if compilers or CPUs may be legally allowed to skip the branch and blindly prefetch in all cases?]
/Bruce
Quoted 41 lines
-----Original Message-----
From: Richardson, Bruce <[email protected]>
Sent: Wednesday, September 29, 2021 12:08 PM
To: Ananyev, Konstantin <[email protected]>
Cc: Xueming(Steven) Li <[email protected]>; [email protected]; NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 5 lines · Konstantin
Quoted 5 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM<snip>
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
(quoted diff) +3
-0+ /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 8 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.The main point we need to take from all this is that when prefetching you need to measure perf impact of it.
Quoted 11 lines
In terms of the specific case of prefetching one past the end of the array, I would take the view that this is harmless in almost all cases. Unlike any prefetch of "NULL" as in the referenced mail, reading one past the end (or other small number of elements past the end) is far less likely to cause a TLB miss - and it's basically just reproducing behaviour we would expect off a HW prefetcher (though those my explicitly never cross page boundaries). However, if you feel it's just cleaner to put in an additional condition to remove the prefetch for the end case, that's ok also - again so long as it doesn't affect performance. [Since prefetch is a hint, I'm not sure if compilers or CPUs may be legally allowed to skip the branch and blindly prefetch in all cases?]
Please look at the code.
It doesn't prefetch next element beyond array boundaries.
It first reads address from the element that is beyond array boundaries (which is a bug by itself). Then it prefetches that bogus address.
We simply don't know is this address is valid and where it points to.
In other words, it doesn't do:rte_prefetch0(&pkts_burst[i + 1]);
It does:rte_prefetch0(pkts_burst[i + 1]);
Quoted 59 lines · Konstantin
Quoted 41 lines
-----Original Message-----
From: Richardson, Bruce <[email protected]>
Sent: Wednesday, September 29, 2021 12:08 PM
To: Ananyev, Konstantin <[email protected]>
Cc: Xueming(Steven) Li <[email protected]>; [email protected]; NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 5 lines · Konstantin
Quoted 5 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM<snip>
Quoted 12 lines
Quoted 11 lines
Quoted 7 lines
(quoted diff) +3
-0+ /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 8 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.The main point we need to take from all this is that when prefetching you need to measure perf impact of it.
Quoted 11 lines
In terms of the specific case of prefetching one past the end of the array, I would take the view that this is harmless in almost all cases. Unlike any prefetch of "NULL" as in the referenced mail, reading one past the end (or other small number of elements past the end) is far less likely to cause a TLB miss - and it's basically just reproducing behaviour we would expect off a HW prefetcher (though those my explicitly never cross page boundaries). However, if you feel it's just cleaner to put in an additional condition to remove the prefetch for the end case, that's ok also - again so long as it doesn't affect performance. [Since prefetch is a hint, I'm not sure if compilers or CPUs may be legally allowed to skip the branch and blindly prefetch in all cases?]
Please look at the code.
It doesn't prefetch next element beyond array boundaries.
It first reads address from the element that is beyond array boundaries (which is a bug by itself). Then it prefetches that bogus address.
We simply don't know is this address is valid and where it points to.
Quoted 6 lines
In other words, it doesn't do:
rte_prefetch0(&pkts_burst[i + 1]);It does:
rte_prefetch0(pkts_burst[i + 1]);
Apologies, yes, you are right, and that is a bug.
/Bruce
Quoted 240 lines · Konstantin
Quoted 232 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 222 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet in rx_burst result,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according to mbuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 15 lines
Quoted 7 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does
this means only single core will poll only, what will
happen if there are
multiple cores polling, won't it cause problem?Quoted 5 lines
And if this requires specific changes in the application, I am not sure about
the solution, can't this work in a transparent way to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);Quoted 7 lines
Quoted 3 lines
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 7 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.
Thanks for the link!
From instruction spec, "The PREFETCHh instruction is merely a hint and does not affect program behavior."
There are 3 choices here:
1: no prefetch. D$ miss will happen on each packet, time cost depends on where data sits(close or far) and burst size.
2: prefetch with loop end check to avoid random address. Pro is free of TLB miss per burst, Cons is "if" instruction per packet. Cost depends on burst size.
3: brute force prefetch, cost is TLB miss, but no addtional instructions per packet. Not sure how random the last address could be in testpmd and how many TLB miss could happen.
Based on my expericen of performance optimization, IIRC, option 3 has the best performance. But for this case, result depends on how many sub-burst inside and how sub-burst get processed, maybe callback will flush prefetch data completely or not. So it's hard to get a conclusion, what I said is that the code in PMD driver should have a reason.
On the other hand, the latency and throughput saving of this featue on multiple ports is huge, I perfer to down play this prefetch discussion if you agree.
Quoted 251 lines
Quoted 250 lines
Quoted 250 lines
Quoted 249 lines
Based on the patch, I believe the
impact has been minimized.Quoted 243 lines
Quoted 243 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Overall, is this for optimizing memory for the port represontors? If so can't we
have a port representor specific solution, reducing scope can reduce the
complexity it brings?Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If this offload is only useful for representor
case, Can we make this offload specific to
representor the case by changing itsname and
Quoted 222 lines
Quoted 221 lines
Quoted 221 lines
Quoted 219 lines
Quoted 219 lines
Quoted 218 lines
Quoted 217 lines
scope.
It works for both PF and representors in same
switch
domain, for application like OVS, few changes to
apply.Signed-off-by: Xueming Li
<[email protected]>
---
doc/guides/nics/features.rst
11 +++++++++++
doc/guides/nics/features/default.ini
1 +
doc/guides/prog_guide/switch_representat
ion.
rst | 10 ++++++++++
lib/ethdev/rte_ethdev.c
1 +
lib/ethdev/rte_ethdev.h
7 +++++++
5 files changed, 30 insertions(+)diff --git a/doc/guides/nics/features.rst
b/doc/guides/nics/features.rst index
a96e12d155..2e2a9b1554 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -624,6 +624,17 @@ Supports inner
packet L4
checksum.
``tx_offload_capa,tx_queue_offload_cap
a:DE
V_TX_OFFLOAD_OUTER_UDP_CKSUM``.+.. _nic_features_shared_rx_queue:
+
+Shared Rx queue
+---------------
+
+Supports shared Rx queue for ports in
same
switch domain.
+
+* **[uses]
rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ`
`.
+* **[provides] mbuf**: ``mbuf.port``.
+
+
.. _nic_features_packet_type_parsing:Packet type parsing
diff --git
a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 754184ddd4..ebeb4c1851 100644
---
a/doc/guides/nics/features/default.ini
+++
b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@ Free Tx mbuf on demand
=
Queue start/stop =
Runtime Rx queue setup =
Runtime Tx queue setup =
+Shared Rx queue =
Burst mode info =
Power mgmt address monitor =
MTU update =
diff --git
a/doc/guides/prog_guide/switch_representa
tion
.rst
b/doc/guides/prog_guide/switch_representa
tion
.rst
index ff6aa91c80..45bf5a3a10 100644
---
a/doc/guides/prog_guide/switch_representa
tion
.rst
+++
b/doc/guides/prog_guide/switch_representa
tion
.rst
@@ -123,6 +123,16 @@ thought as a
software
"patch panel" front-end for applications.
.. [1] `Ethernet switch device driver
model
(switchdev)<https://www.kernel.org/doc/Documentation
/net
working/switchdev.txt
`_+- Memory usage of representors is huge
when
number of representor
+grows,
+ because PMD always allocate mbuf for
each
descriptor of Rx queue.
+ Polling the large number of ports
brings
more CPU load, cache
+miss and
+ latency. Shared Rx queue can be used
to
share Rx queue between
+PF and
+ representors in same switch domain.
+``RTE_ETH_RX_OFFLOAD_SHARED_RXQ``
+ is present in Rx offloading capability
of
device info. Setting
+the
+ offloading flag in device Rx mode or
Rx
queue configuration to
+enable
+ shared Rx queue. Polling any member
port
of shared Rx queue can
+return
+ packets of all ports in group, port ID
is
saved in ``mbuf.port``.
+
Basic SR-IOV
------------diff --git a/lib/ethdev/rte_ethdev.c
b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..1361ff759a 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -127,6 +127,7 @@ static const struct {
RTE_RX_OFFLOAD_BIT2STR(OUTER_UDP_
CKSU
M),
RTE_RX_OFFLOAD_BIT2STR(RSS_HASH),
RTE_ETH_RX_OFFLOAD_BIT2STR(BUFFER
_SPL
IT),
+
RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ),
};#undef RTE_RX_OFFLOAD_BIT2STR
diff --git a/lib/ethdev/rte_ethdev.h
b/lib/ethdev/rte_ethdev.h
index d2b27c351f..a578c9db9d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct
rte_eth_rxconf {
uint8_t rx_drop_en; /**< Drop
packets
if no descriptors are available. */
uint8_t rx_deferred_start; /**<
Do
not start queue with rte_eth_dev_start().
*/
uint16_t rx_nseg; /**< Number of
descriptions in rx_seg array.
*/
+ uint32_t shared_group; /**<
Shared
port group index in
+ switch domain. */
/**
* Per-queue Rx offloads to be
set
using DEV_RX_OFFLOAD_* flags.
* Only offloads set on
rx_queue_offload_capa or
rx_offload_capa @@ -1373,6 +1374,12 @@
struct
rte_eth_conf {
#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM
0x00040000
#define DEV_RX_OFFLOAD_RSS_HASH
0x00080000
#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
0x00100000
+/**
+ * Rx queue is shared among ports in
same
switch domain to save
+memory,
+ * avoid polling each port. Any port in
group can be used to receive packets.
+ * Real source port number saved in
mbuf-
port field.
+ */
+#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ
0x00200000#define DEV_RX_OFFLOAD_CHECKSUM
(DEV_RX_OFFLOAD_IPV4_CKSUM | \
DEV_RX_O
FFLO
AD_UDP_CKSUM | \
--
2.25.1
Quoted 258 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 1:09 PM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue>Quoted 240 lines · Konstantin
Quoted 232 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 222 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet in rx_burst result,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according to mbuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 21 lines
Quoted 20 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue
(share queue), right? Does
this means only single core will poll only, what
will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent way
to
the application?Quoted 6 lines
Discussed with Jerin, new API introduced in v3 2/8 that
aggregate ports
in same group into one new port. Users could schedule polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);Quoted 7 lines
Quoted 3 lines
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 7 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.
Quoted 12 lines
Thanks for the link!
From instruction spec, "The PREFETCHh instruction is merely a hint and does not affect program behavior."
There are 3 choices here:
1: no prefetch. D$ miss will happen on each packet, time cost depends on where data sits(close or far) and burst size.
2: prefetch with loop end check to avoid random address. Pro is free of TLB miss per burst, Cons is "if" instruction per packet. Cost depends on burst size.
3: brute force prefetch, cost is TLB miss, but no addtional instructions per packet. Not sure how random the last address could be in testpmd and how many TLB miss could happen.
There are plenty of standard techniques to avoid that issue while keeping prefetch() in place.
Probably the easiest one:
for (i=0; i < nb_rx - 1; i++) {
prefetch(pkt[i+1];
/* do your stuff with pkt[i[ here */
}/* do your stuff with pkt[nb_rx - 1]; */
Quoted 11 lines
Based on my expericen of performance optimization, IIRC, option 3 has the best performance. But for this case, result depends on how many sub-burst inside and how sub-burst get processed, maybe callback will flush prefetch data completely or not. So it's hard to get a conclusion, what I said is that the code in PMD driver should have a reason.
On the other hand, the latency and throughput saving of this featue on multiple ports is huge, I perfer to down play this prefetch discussion if you agree.
Honestly, I don't know how else to explain to you that there is a bug in that piece of code. From my perspective it is a trivial bug, with a trivial fix.
But you simply keep ignoring the arguments.
Till it get fixed and other comments addressed - my vote is NACK for these series. I don't think we need bogus code in testpmd.
Quoted 274 lines · Konstantin
Quoted 257 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 1:09 PM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue>Quoted 240 lines · Konstantin
Quoted 232 lines
-----Original Message-----
From: Xueming(Steven) Li <[email protected]>
Sent: Wednesday, September 29, 2021 10:13 AM
To: [email protected]; Ananyev, Konstantin <[email protected]>
Cc: NBU-Contact-Thomas Monjalon <[email protected]>; [email protected]; [email protected]; Yigit, Ferruh <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 222 lines · Konstantin
Quoted 189 lines
Quoted 185 lines
Quoted 176 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
Quoted 61 lines
In current DPDK framework, each RX queue
is
pre-loaded with mbufs
for incoming packets. When number of
representors scale out in a
switch domain, the memory consumption
became
significant. Most
important, polling all ports leads to
high
cache miss, high
latency and low throughput.This patch introduces shared RX queue.
Ports
with same
configuration in a switch domain could
share
RX queue set by specifying sharing group.
Polling any queue using same shared RX
queue
receives packets from
all member ports. Source port is
identified
by mbuf->port.Port queue number in a shared group
should be
identical. Queue
index is
1:1 mapped in shared group.Share RX queue is supposed to be polled
on
same thread.Multiple groups is supported by group ID.
Is this offload specific to the
representor? If
so can this name be changed specifically to
representor?Yes, PF and representor in switch domain
could
take advantage.If it is for a generic case, how the flow
ordering will be maintained?Not quite sure that I understood your
question.
The control path of is
almost same as before, PF and representor
port
still needed, rte flows not impacted.
Queues still needed for each member port,
descriptors(mbuf) will be
supplied from shared Rx queue in my PMD
implementation.Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQ offload, multiple
ethdev receive queues land intothe same
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
receive queue, In that case, how the flow order
is
maintained for respective receive queues.Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
I guess the question is testpmd forward stream?
The
forwarding logic has to be changed slightly in
case
of shared rxq.
basically for each packet in rx_burst result,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
lookup
source stream according to mbuf->port, forwarding
to
target fs.
Packets from same source port could be grouped as
a
small burst to process, this will accelerates the
performance if trafficcome from
Quoted 51 lines
Quoted 46 lines
Quoted 36 lines
Quoted 28 lines
Quoted 27 lines
limited ports. I'll introduce some common api to
do
shard rxq forwarding, call it with packets
handling
callback, so it suites for
all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue
(share queue), right? Does
this means only single core will poll only, what
will
happen if there are
multiple cores polling, won't it cause problem?And if this requires specific changes in the
application, I am not sure about
the solution, can't this work in a transparent way
to
the application?Discussed with Jerin, new API introduced in v3 2/8
that
aggregate ports
in same group into one new port. Users could schedule
polling on the
aggregated port instead of all member ports.Quoted 7 lines
The v3 still has testpmd changes in fastpath. Right? IMO,
For this
feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as
separatefwd_engineto show how to use this feature.Quoted 9 lines
Good point to discuss :) There are two strategies to polling
a shared
Rxq:
1. polling each member port
All forwarding engines can be reused to work as before.
My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 4 lines
Not unfortunately. More than that, every application needs to
change
to support this model.Quoted 5 lines
Both strategies need user application to resolve port ID from mbuf and
process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as
when it
comes to application.Quoted 20 lines
Quoted 7 lines
Quoted 6 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it.
This is an optional API, not supported by my PMD yet.Quoted 5 lines
We are thinking of implementing this PMD when it comes to it,
ie.
without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according
to
logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.Quoted 4 lines
Let's defer part 2 until some PMD really support it and tested,
how do
you think?We are not planning to use this feature so either way it is OK to
me.
I leave to ethdev maintainers decide between 1 vs 2.Quoted 8 lines
I do have a strong opinion not changing the testpmd basic forward
engines
for this feature.I would like to keep it simple as fastpath optimized and would
like to add a separate Forwarding engine as means to verify this
feature.Quoted 3 lines
+1 to that.
I don't think it a 'common' feature.
So separate FWD mode seems like a best choice to me.Quoted 6 lines
-1 :)
There was some internal requirement from test team, they need to verify
all features like packet content, rss, vlan, checksum,rte_flow... to
be working based on shared rx queue.Then I suppose you'll need to write really comprehensive fwd-engine to satisfy your test team :)
Speaking seriously, I still don't understand why do you need all available fwd-engines to verify this feature.
From what I understand, main purpose of your changes to test-pmd:
allow to fwd packet though differentfwd_stream(TX through different HW queue).
In theory, if implemented in generic and extendable way - that might be a useful add-on to tespmd fwd functionality.
But current implementation looks very case specific.
And as I don't think it is a common case, I don't see much point to pollute
basic fwd cases with it.BTW, as a side note, the code below looks bogus to me:
(quoted diff) +3
-0+void +forward_shared_rxq(struct fwd_stream *fs, uint16_t nb_rx, + struct rte_mbuf **pkts_burst, packet_fwd_cbfwd)
(quoted diff) +6
-0+{ + uint16_t i, nb_fs_rx = 1, port; + + /* Locate real source fs according to mbuf->port. */ + for (i = 0; i < nb_rx; ++i) { + rte_prefetch0(pkts_burst[i + 1]);Quoted 7 lines
Quoted 3 lines
you access pkt_burst[] beyond array boundaries,
also you ask cpu to prefetch some unknown and possibly invalid address.Sorry I forgot this topic. It's too late to prefetch current packet, so perfetch next is better. Prefetch an invalid address at end of a look doesn't hurt, it's common in DPDK.
Quoted 7 lines
First of all it is usually never 'OK' to access array beyond its bounds.
Second prefetching invalid address *does* hurt performance badly on many CPUs
(TLB misses, consumed memory bandwidth etc.).
As a reference: https://lwn.net/Articles/444346/
If some existing DPDK code really does that - then I believe it is an issue and has to be addressed. More important - it is really bad attitude to submit bogus code to DPDK community and pretend that it is 'OK'.Quoted 12 lines
Thanks for the link!
From instruction spec, "The PREFETCHh instruction is merely a hint and does not affect program behavior."
There are 3 choices here:
1: no prefetch. D$ miss will happen on each packet, time cost depends on where data sits(close or far) and burst size.
2: prefetch with loop end check to avoid random address. Pro is free of TLB miss per burst, Cons is "if" instruction per packet. Cost depends on burst size.
3: brute force prefetch, cost is TLB miss, but no addtional instructions per packet. Not sure how random the last address could be in testpmd and how many TLB miss could happen.There are plenty of standard techniques to avoid that issue while keeping
prefetch()in place.
Probably the easiest one:
Quoted 6 lines
for (i=0; i < nb_rx - 1; i++) { prefetch(pkt[i+1]; /* do your stuff with pkt[i[ here */ }/* do your stuff with pkt[nb_rx - 1]; */
Thanks, will update in next version.
Quoted 20 lines
Quoted 8 lines
Based on my expericen of performance optimization, IIRC, option 3 has the best performance. But for this case, result depends on how many sub-burst inside and how sub-burst get processed, maybe callback will flush prefetch data completely or not. So it's hard to get a conclusion, what I said is that the code in PMD driver should have a reason.
Quoted 4 lines
On the other hand, the latency and throughput saving of this featue on multiple ports is huge, I perfer to down play this prefetch discussion if you agree.
Honestly, I don't know how else to explain to you that there is a bug in that piece of code. From my perspective it is a trivial bug, with a trivial fix.
But you simply keep ignoring the arguments.
Till it get fixed and other comments addressed - my vote is NACK for these series. I don't think we need bogus code in testpmd.
Quoted 122 lines · Jerin Jacob
Quoted 97 lines · Xueming(Steven) Li
Quoted 95 lines · Jerin Jacob
Quoted 93 lines · Xueming(Steven) Li
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?Quoted 6 lines
Quoted 2 lines
Not unfortunately. More than that, every application needs to change to support this model.
Both strategies need user application to resolve port ID from mbuf and process accordingly.
This one doesn't demand aggregated port, no polling schedule change.I was thinking, mbuf will be updated from driver/aggregator port as when it comes to application.
Quoted 14 lines
Quoted 9 lines
Quoted 5 lines
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.We are thinking of implementing this PMD when it comes to it, ie. without application change in fastpath
logic.Fastpath have to resolve port ID anyway and forwarding according to logic. Forwarding engine need to adapt to support shard Rxq. Fortunately, in testpmd, this can be done with an abstract API.
Quoted 5 lines
Quoted 2 lines
Let's defer part 2 until some PMD really support it and tested, how do you think?
We are not planning to use this feature so either way it is OK to me. I leave to ethdev maintainers decide between 1 vs 2.
A better driver should support both, but specific driver could select either one. 1 brings less changes to application, 2 brings better performance with additional steps.
Quoted 151 lines
I do have a strong opinion not changing the testpmd basic forward engines for this feature.I would like to keep it simple as fastpath optimized and would like to add a separate Forwarding engine as means to verify this feature.
Quoted 144 lines
Quoted 143 lines
Quoted 143 lines
Quoted 141 lines
Quoted 141 lines
Quoted 140 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
Quoted 76 lines · Jerin Jacob
Quoted 75 lines · Xueming(Steven) Li
Quoted 72 lines · Ferruh Yigit
Quoted 55 lines · Xueming(Steven) Li
Quoted 55 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 11, 2021 4:03 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 43 lines · Xueming(Steven) Li
Hi,
Quoted 26 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Monday, August 9, 2021 9:51 PM
To: Xueming(Steven) Li <[email protected]>
Cc: dpdk-dev <[email protected]>; Ferruh Yigit <[email protected]>; NBU-Contact-Thomas Monjalon <[email protected]>; Andrew Rybchenko <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queueQuoted 16 lines · Xueming Li
In current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same
configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from
all member ports. Source port is identified bymbuf->port.Port queue number in a shared group should be identical. Queue index is
1:1 mapped in shared group.Quoted 5 lines
Quoted 3 lines
Share RX queue is supposed to be polled on same thread.
Multiple groups is supported by group ID.
Is this offload specific to the representor? If so can this name be changed specifically to representor?
Yes, PF and representor in switch domain could take advantage.
Quoted 1 line
If it is for a generic case, how the flow ordering will be maintained?
Not quite sure that I understood your question. The control path of is almost same as before, PF and representor port still needed, rte flows not impacted. Queues still needed for each member port, descriptors(mbuf) will be supplied from shared Rx queue in my PMD implementation.
Quoted 9 lines
Quoted 2 lines
My question was if create a generic
RTE_ETH_RX_OFFLOAD_SHARED_RXQoffload, multiple ethdev receive queues land into the same receive queue, In that case, how the flow order is maintained for respective receive queues.I guess the question is testpmd forward stream? The forwarding logic has to be changed slightly in case of shared rxq. basically for each packet in
rx_burstresult, lookup source stream according tombuf->port, forwarding to target fs. Packets from same source port could be grouped as a small burst to process, this will accelerates the performance if traffic come from limited ports. I'll introduce some common api to do shard rxq forwarding, call it with packets handling callback, so it suites for all forwarding engine. Will sent patches soon.All ports will put the packets in to the same queue (share queue), right? Does this means only single core will poll only, what will happen if there are multiple cores polling, won't it cause problem?
And if this requires specific changes in the application, I am not sure about the solution, can't this work in a transparent way to the application?
Quoted 8 lines
Quoted 3 lines
Discussed with Jerin, new API introduced in v3 2/8 that aggregate ports in same group into one new port. Users could schedule polling on the aggregated port instead of all member ports.
The v3 still has testpmd changes in fastpath. Right? IMO, For this feature, we should not change fastpath of testpmd application. Instead, testpmd can use aggregated ports probably as separate
fwd_engineto show how to use this feature.
Good point to discuss :) There are two strategies to polling a shared Rxq:
1. polling each member port
All forwarding engines can be reused to work as before. My testpmd patches are efforts towards this direction. Does your PMD support this?
2. polling aggregated port
Besides forwarding engine, need more work to to demo it. This is an optional API, not supported by my PMD yet.
Quoted 137 lines
Quoted 137 lines
Quoted 136 lines
Overall, is this for optimizing memory for the port represontors? If so can't we have a port representor specific solution, reducing scope can reduce the complexity it brings?
Quoted 128 lines
Quoted 2 lines
If this offload is only useful for representor case, Can we make this offload specific to representor the case by changing its name and scope.
It works for both PF and representors in same switch domain, for application like OVS, few changes to apply.
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Quoted 123 lines
Signed-off-by Xueming Li <[email protected]>--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)(quoted diff) +0
-0
b/doc/guides/nics/features.rstindexa96e12d155..2e2a9b1554100644doc/guides/nics/features.rst +11
-0@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsingdoc/guides/nics/features/default.ini +1
-0@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =doc/guides/prog_guide/switch_representation.rst +0
-0@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev)<https://www.kernel.org/doc/Documentation/networking/switchdev.txt
Quoted 1 line
`_
+- Memory usage of representors is huge when number of representor
doc/guides/prog_guide/switch_representation.rst +16
-0+grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache +miss and + latency. Shared Rx queue can be used to share Rx queue between +PF and + representors in same switch domain. +``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting +the + offloading flag in device Rx mode or Rx queue configuration to +enable + shared Rx queue. Polling any member port of shared Rx queue can +return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------lib/ethdev/rte_ethdev.c +1
-0@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STRlib/ethdev/rte_ethdev.h +2
-0@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in +switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or
rx_offload_capa@@ -1373,6 +1374,12 @@ structrte_eth_conf{ #defineDEV_RX_OFFLOAD_OUTER_UDP_CKSUM0x00040000
#defineDEV_RX_OFFLOAD_RSS_HASH0x00080000
#defineRTE_ETH_RX_OFFLOAD_BUFFER_SPLIT0x00100000lib/ethdev/rte_ethdev.h +7
-1+/** +* Rx queue is shared among ports in same switch domain to save +memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \ --2.25.1
PATCH v2 1/15 ethdev: introduce shared Rx queue
In reply to Xueming LiIn current DPDK framework, each RX queue is pre-loaded with mbufs for incoming packets. When number of representors scale out in a switch domain, the memory consumption became significant. Most important, polling all ports leads to high cache miss, high latency and low throughput.
This patch introduces shared RX queue. Ports with same configuration in a switch domain could share RX queue set by specifying sharing group. Polling any queue using same shared RX queue receives packets from all member ports. Source port is identified by mbuf->port.
Port queue number in a shared group should be identical. Queue index is 1:1 mapped in shared group.
Share RX queue must be polled on single thread or core.
Multiple groups is supported by group ID.
---
Rx queue object could be used as shared Rx queue object, it's important to clear all queue control callback api that using queue object:
https://mails.dpdk.org/archives/dev/2021-July/215574.html
--- doc/guides/nics/features.rst | 11 +++++++++++ doc/guides/nics/features/default.ini | 1 + doc/guides/prog_guide/switch_representation.rst | 10 ++++++++++ lib/ethdev/rte_ethdev.c | 1 + lib/ethdev/rte_ethdev.h | 7 +++++++ 5 files changed, 30 insertions(+)
doc/guides/nics/features.rst +11 -0
@@ -624,6 +624,17 @@ Supports inner packet L4 checksum. ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +.. _nic_features_shared_rx_queue: + +Shared Rx queue +--------------- + +Supports shared Rx queue for ports in same switch domain. + +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:RTE_ETH_RX_OFFLOAD_SHARED_RXQ``. +* **[provides] mbuf**: ``mbuf.port``. + + .. _nic_features_packet_type_parsing: Packet type parsing
doc/guides/nics/features/default.ini +1 -0
@@ -19,6 +19,7 @@ Free Tx mbuf on demand = Queue start/stop = Runtime Rx queue setup = Runtime Tx queue setup = +Shared Rx queue = Burst mode info = Power mgmt address monitor = MTU update =
doc/guides/prog_guide/switch_representation.rst +10 -0
@@ -123,6 +123,16 @@ thought as a software "patch panel" front-end for applications. .. [1] `Ethernet switch device driver model (switchdev) <https://www.kernel.org/doc/Documentation/networking/switchdev.txt>`_ +- Memory usage of representors is huge when number of representor grows, + because PMD always allocate mbuf for each descriptor of Rx queue. + Polling the large number of ports brings more CPU load, cache miss and + latency. Shared Rx queue can be used to share Rx queue between PF and + representors in same switch domain. ``RTE_ETH_RX_OFFLOAD_SHARED_RXQ`` + is present in Rx offloading capability of device info. Setting the + offloading flag in device Rx mode or Rx queue configuration to enable + shared Rx queue. Polling any member port of shared Rx queue can return + packets of all ports in group, port ID is saved in ``mbuf.port``. + Basic SR-IOV ------------
lib/ethdev/rte_ethdev.c +1 -0
@@ -127,6 +127,7 @@ static const struct {RTE_RX_OFFLOAD_BIT2STR (OUTER_UDP_CKSUM ),RTE_RX_OFFLOAD_BIT2STR (RSS_HASH ),RTE_ETH_RX_OFFLOAD_BIT2STR (BUFFER_SPLIT ), + RTE_ETH_RX_OFFLOAD_BIT2STR(SHARED_RXQ), };#undef RTE_RX_OFFLOAD_BIT2STR
lib/ethdev/rte_ethdev.h +7 -0
@@ -1047,6 +1047,7 @@ struct rte_eth_rxconf {uint8_t rx_drop_en;/**< Drop packets if no descriptors are available. */ uint8_t rx_deferred_start;/**< Do not start queue with rte_eth_dev_start(). */ uint16_t rx_nseg;/**< Number of descriptions in rx_seg array. */ +uint32_t shared_group;/**< Shared port group index in switch domain. */ /** * Per-queue Rx offloads to be set using DEV_RX_OFFLOAD_* flags. * Only offloads set on rx_queue_offload_capa or rx_offload_capa
@@ -1373,6 +1374,12 @@ struct rte_eth_conf {#define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM 0x00040000#define DEV_RX_OFFLOAD_RSS_HASH 0x00080000#define RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT 0x00100000 +/** +* Rx queue is shared among ports in same switch domain to save memory, +* avoid polling each port. Any port in group can be used to receive packets. +* Real source port number saved in mbuf->port field. +*/ +#define RTE_ETH_RX_OFFLOAD_SHARED_RXQ 0x00200000#define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \ DEV_RX_OFFLOAD_UDP_CKSUM | \
Signature · 1 line
2.25.1
PATCH v2 2/15 app/testpmd: dump port and queue info for each packet
In case of shared Rx queue, port number of mbufs returned from one rx burst could be different.
To support shared Rx queue, this patch dumps mbuf->port and queue for each packet.
--- app/test-pmd/util.c | 1 + 1 file changed, 1 insertion(+)
app/test-pmd/util.c +1 -0
@@ -100,6 +100,7 @@ dump_pkt_burst(uint16_t port_id, uint16_t queue, struct rte_mbuf *pkts[],struct rte_flow_restore_info info = {0 , }; mb = pkts[i]; +MKDUMPSTR (print_buf, buf_size, cur_len,"port %u, " , mb->port); eth_hdr =rte_pktmbuf_read (mb,0 ,sizeof (_eth_hdr), &_eth_hdr); eth_type =RTE_BE_TO_CPU_16 (eth_hdr->ether_type); packet_type = mb->packet_type;
Signature · 1 line
2.25.1
PATCH v2 3/15 app/testpmd: new parameter to enable shared Rx queue
In reply to Xueming LiAdds "--rxq-share" parameter to enable shared rxq for each rxq.
Default shared rxq group 0 is used, RX queues in same switch domain shares same rxq according to queue index.
Shared Rx queue is enabled only if device support offloading flag RTE_ETH_RX_OFFLOAD_SHARED_RXQ.
--- app/test-pmd/config.c | 6 +++++- app/test-pmd/parameters.c | 4 ++++ app/test-pmd/testpmd.c | 14 ++++++++++++++ app/test-pmd/testpmd.h | 2 ++ doc/guides/testpmd_app_ug/run_app.rst | 5 +++++ 5 files changed, 30 insertions(+), 1 deletion(-)
app/test-pmd/config.c +5 -1
@@ -2709,7 +2709,11 @@ rxtx_config_display(void)printf (" RX threshold registers: pthresh=%d hthresh=%d " " wthresh=%d\n" , pthresh_tmp, hthresh_tmp, wthresh_tmp); -printf (" RX Offloads=0x%" PRIx64"\n" , offloads_tmp); +printf (" RX Offloads=0x%" PRIx64, offloads_tmp); +if (rx_conf->offloads &RTE_ETH_RX_OFFLOAD_SHARED_RXQ ) +printf (" share group=%u" , + rx_conf->shared_group); +printf ("\n" ); }/* per tx queue config only for first queue to be less verbose */
app/test-pmd/parameters.c +4 -0
@@ -166,6 +166,7 @@ usage(char* progname)printf (" --tx-ip=src,dst: IP addresses in Tx-only mode\n" );printf (" --tx-udp=src[,dst]: UDP ports in Tx-only mode\n" );printf (" --eth-link-speed: force link speed.\n" ); +printf (" --rxq-share: share rxq between PF and representors\n" );printf (" --disable-link-check: disable check on link status when " "starting/stopping ports.\n" );printf (" --disable-device-start: do not automatically start port\n" );
@@ -602,6 +603,7 @@ launch_args_parse(int argc, char** argv) { "rxpkts", 1, 0, 0 }, { "txpkts", 1, 0, 0 }, { "txonly-multi-flow", 0, 0, 0 }, + { "rxq-share", 0, 0, 0 }, { "eth-link-speed", 1, 0, 0 }, { "disable-link-check", 0, 0, 0 }, { "disable-device-start", 0, 0, 0 },
@@ -1256,6 +1258,8 @@ launch_args_parse(int argc, char** argv) }if (!strcmp (lgopts[opt_idx].name,"txonly-multi-flow" )) txonly_multi_flow =1 ; +if (!strcmp (lgopts[opt_idx].name,"rxq-share" )) + rxq_share =1 ;if (!strcmp (lgopts[opt_idx].name,"no-flush-rx" )) no_flush_rx =1 ;if (!strcmp (lgopts[opt_idx].name,"eth-link-speed" )) {
app/test-pmd/testpmd.c +14 -0
@@ -223,6 +223,9 @@ uint8_t rx_pkt_nb_segs; /**< Number of segments to split */uint16_t rx_pkt_seg_offsets[MAX_SEGS_BUFFER_SPLIT ];uint8_t rx_pkt_nb_offs;/**< Number of specified offsets */ +uint8_t rxq_share; +/**< Create shared rxq for PF and representors. */ +/* * Configuration of packet segments used by the "txonly" processing engine. */
@@ -1441,6 +1444,11 @@ init_config_port_offloads(portid_t pid, uint32_t socket_id) port->dev_conf.txmode.offloads &= ~DEV_TX_OFFLOAD_MBUF_FAST_FREE ; +if (rxq_share && + (port->dev_info.rx_offload_capa &RTE_ETH_RX_OFFLOAD_SHARED_RXQ )) + port->dev_conf.rxmode.offloads |= +RTE_ETH_RX_OFFLOAD_SHARED_RXQ ; +/* Apply Rx offloads configuration */ for (i =0 ; i < port->dev_info.max_rx_queues; i++) port->rx_conf[i].offloads = port->dev_conf.rxmode.offloads;
@@ -3334,6 +3342,12 @@ rxtx_port_config(struct rte_port *port)for (qid =0 ; qid < nb_rxq; qid++) { offloads = port->rx_conf[qid].offloads; port->rx_conf[qid] = port->dev_info.default_rxconf; + +if (rxq_share >0 && + (port->dev_info.rx_offload_capa & +RTE_ETH_RX_OFFLOAD_SHARED_RXQ )) + offloads |=RTE_ETH_RX_OFFLOAD_SHARED_RXQ ; +if (offloads !=0 ) port->rx_conf[qid].offloads = offloads;
app/test-pmd/testpmd.h +2 -0
@@ -477,6 +477,8 @@ extern enum tx_pkt_split tx_pkt_split;extern uint8_t txonly_multi_flow; +extern uint8_t rxq_share; +extern uint16_t nb_pkt_per_burst;extern uint16_t nb_pkt_flowgen_clones;extern uint16_t mb_mempool_cache;
doc/guides/testpmd_app_ug/run_app.rst +5 -0
@@ -384,6 +384,11 @@ The command line options are: Generate multiple flows in txonly mode. +* ``--rxq-share`` + + Create all queues in shared RX queue mode if device supports, queues in + same switch domain are shared according queue ID. + * ``--eth-link-speed`` Set a forced link speed to the ethernet port::
Signature · 1 line
2.25.1
PATCH v2 4/15 app/testpmd: make sure shared Rx queue polled on same core
In reply to Xueming LiShared rxqs uses one set rx queue internally, queues must be polled from one core.
Stops forwarding if shared rxq being scheduled on multiple cores.
--- app/test-pmd/config.c | 91 ++++++++++++++++++++++++++++++++++++++++++ app/test-pmd/testpmd.c | 4 +- app/test-pmd/testpmd.h | 2 + 3 files changed, 96 insertions(+), 1 deletion(-)
app/test-pmd/config.c +91 -0
@@ -2885,6 +2885,97 @@ port_rss_hash_key_update(portid_t port_id, char rss_type[], uint8_t *hash_key, } } +/* +* Check whether a shared rxq scheduled on other lcores. +*/ +static bool +fwd_stream_on_other_lcores (uint16_t domain_id,portid_t src_port, +queueid_t src_rxq,lcoreid_t src_lc) +{ +streamid_t sm_id; +streamid_t nb_fs_per_lcore; +lcoreid_t nb_fc; +lcoreid_t lc_id; +struct fwd_stream *fs; +struct rte_port *port; +struct rte_eth_rxconf *rxq_conf; + + nb_fc = cur_fwd_config.nb_fwd_lcores; +for (lc_id = src_lc +1 ; lc_id < nb_fc; lc_id++) { + sm_id = fwd_lcores[lc_id]->stream_idx; + nb_fs_per_lcore = fwd_lcores[lc_id]->stream_nb; +for (; sm_id < fwd_lcores[lc_id]->stream_idx + nb_fs_per_lcore; + sm_id++) { + fs = fwd_streams[sm_id]; + port = &ports[fs->rx_port]; + rxq_conf = &port->rx_conf[fs->rx_queue]; +if ((rxq_conf->offloads &RTE_ETH_RX_OFFLOAD_SHARED_RXQ ) + ==0 ) +/* Not shared rxq. */ +continue ; +if (domain_id != port->dev_info.switch_info.domain_id) +continue ; +if (fs->rx_queue != src_rxq) +continue ; +printf ("Shared RX queue can't be scheduled on different cores:\n" ); +printf (" lcore %hhu Port %hu queue %hu\n" , + src_lc, src_port, src_rxq); +printf (" lcore %hhu Port %hu queue %hu\n" , + lc_id, fs->rx_port, fs->rx_queue); +printf (" please use --nb-cores=%hu to limit forwarding cores\n" , + nb_rxq); +return true; + } + } +return false; +} + +/* +* Check shared rxq configuration. +* +* Shared group must not being scheduled on different core. +*/ +bool +pkt_fwd_shared_rxq_check (void ) +{ +streamid_t sm_id; +streamid_t nb_fs_per_lcore; +lcoreid_t nb_fc; +lcoreid_t lc_id; +struct fwd_stream *fs; +uint16_t domain_id; +struct rte_port *port; +struct rte_eth_rxconf *rxq_conf; + + nb_fc = cur_fwd_config.nb_fwd_lcores; +/* +* Check streams on each core, make sure the same switch domain + +* group + queue doesn't get scheduled on other cores. +*/ +for (lc_id =0 ; lc_id < nb_fc; lc_id++) { + sm_id = fwd_lcores[lc_id]->stream_idx; + nb_fs_per_lcore = fwd_lcores[lc_id]->stream_nb; +for (; sm_id < fwd_lcores[lc_id]->stream_idx + nb_fs_per_lcore; + sm_id++) { + fs = fwd_streams[sm_id]; +/* Update lcore info stream being scheduled. */ + fs->lcore = fwd_lcores[lc_id]; + port = &ports[fs->rx_port]; + rxq_conf = &port->rx_conf[fs->rx_queue]; +if ((rxq_conf->offloads &RTE_ETH_RX_OFFLOAD_SHARED_RXQ ) + ==0 ) +/* Not shared rxq. */ +continue ; +/* Check shared rxq not scheduled on remaining cores. */ + domain_id = port->dev_info.switch_info.domain_id; +if (fwd_stream_on_other_lcores (domain_id, fs->rx_port, + fs->rx_queue, lc_id)) +return false; + } + } +return true; +} +/* * Setup forwarding configuration for each logical core. */
app/test-pmd/testpmd.c +3 -1
@@ -2169,10 +2169,12 @@ start_packet_forwarding(int with_tx_first)fwd_config_setup (); +pkt_fwd_config_display (&cur_fwd_config); +if (!pkt_fwd_shared_rxq_check ()) +return ;if (!no_flush_rx)flush_fwd_rx_queues (); -pkt_fwd_config_display (&cur_fwd_config);rxtx_config_display ();fwd_stats_reset ();
app/test-pmd/testpmd.h +2 -0
@@ -144,6 +144,7 @@ struct fwd_stream {uint64_t core_cycles;/**< used for RX and TX processing */ struct pkt_burst_stats rx_burst_stats;struct pkt_burst_stats tx_burst_stats; +struct fwd_lcore *lcore;/**< Lcore being scheduled. */ };/**
@@ -785,6 +786,7 @@ void port_summary_header_display(void);void rx_queue_infos_display (portid_t port_idi,uint16_t queue_id);void tx_queue_infos_display (portid_t port_idi,uint16_t queue_id);void fwd_lcores_config_display (void ); +bool pkt_fwd_shared_rxq_check (void );void pkt_fwd_config_display (struct fwd_config *cfg);void rxtx_config_display (void );void fwd_config_setup (void );
Signature · 1 line
2.25.1
PATCH v2 5/15 app/testpmd: adds common forwarding for shared Rx queue
In reply to Xueming LiBy enabling shared Rx queue, received packets come from all member ports in same shared Rx queue.
This patch adds a common forwarding function for shared Rx queue, groups source forwarding stream by looking up local streams on current lcore with packet source port(mbuf->port) and queue, then invokes callback to handle received packets for source stream.
--- app/test-pmd/testpmd.c | 69 ++++++++++++++++++++++++++++++++++++++++++ app/test-pmd/testpmd.h | 4 +++ 2 files changed, 73 insertions(+)
app/test-pmd/testpmd.c +69 -0
@@ -2034,6 +2034,75 @@ flush_fwd_rx_queues(void) } } +/** +* Get packet source stream by source port and queue. +* All streams of same shared Rx queue locates on same core. +*/ +static struct fwd_stream * +forward_stream_get (struct fwd_stream *fs,uint16_t port) +{ +streamid_t sm_id; +struct fwd_lcore *fc; +struct fwd_stream **fsm; +streamid_t nb_fs; + + fc = fs->lcore; + fsm = &fwd_streams[fc->stream_idx]; + nb_fs = fc->stream_nb; +for (sm_id =0 ; sm_id < nb_fs; sm_id++) { +if (fsm[sm_id]->rx_port == port && + fsm[sm_id]->rx_queue == fs->rx_queue) +return fsm[sm_id]; + } +return NULL ; +} + +/** +* Forward packet by source port and queue. +*/ +static void +forward_by_port (struct fwd_stream *src_fs,uint16_t port,uint16_t nb_rx, +struct rte_mbuf **pkts,packet_fwd_cb fwd) +{ +struct fwd_stream *fs =forward_stream_get (src_fs, port); + +if (fs !=NULL ) { + fs->rx_packets += nb_rx; +fwd (fs, nb_rx, pkts); + }else { +/* Source stream not found, drop all packets. */ + src_fs->fwd_dropped += nb_rx; +while (nb_rx >0 ) +rte_pktmbuf_free (pkts[--nb_rx]); + } +} + +/** +* Forward packets from shared Rx queue. +* +* Source port of packets are identified by mbuf->port. +*/ +void +forward_shared_rxq (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst,packet_fwd_cb fwd) +{ +uint16_t i, nb_fs_rx =1 , port; + +/* Locate real source fs according to mbuf->port. */ +for (i =0 ; i < nb_rx; ++i) { +rte_prefetch0 (pkts_burst[i +1 ]); + port = pkts_burst[i]->port; +if (i +1 == nb_rx || pkts_burst[i +1 ]->port != port) { +/* Forward packets with same source port. */ +forward_by_port (fs, port, nb_fs_rx, + &pkts_burst[i +1 - nb_fs_rx], fwd); + nb_fs_rx =1 ; + }else { + nb_fs_rx++; + } + } +} +static void run_pkt_fwd_on_lcore (struct fwd_lcore *fc,packet_fwd_t pkt_fwd) {
app/test-pmd/testpmd.h +4 -0
@@ -272,6 +272,8 @@ struct fwd_lcore {typedef void (*port_fwd_begin_t )(portid_t pi);typedef void (*port_fwd_end_t )(portid_t pi);typedef void (*packet_fwd_t )(struct fwd_stream *fs); +typedef void (*packet_fwd_cb )(struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts);struct fwd_engine {const char *fwd_mode_name;/**< Forwarding mode name. */
@@ -897,6 +899,8 @@ char *list_pkt_forwarding_modes(void);char *list_pkt_forwarding_retry_modes (void );void set_pkt_forwarding_mode (const char *fwd_mode);void start_packet_forwarding (int with_tx_first); +void forward_shared_rxq (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst,packet_fwd_cb fwd);void fwd_stats_display (void );void fwd_stats_reset (void );void stop_packet_forwarding (void );
Signature · 1 line
2.25.1
PATCH v2 6/15 app/testpmd: add common fwd wrapper function
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1. get_start_cycles
2. rte_eth_rx_burst(...,nb_pkt_per_burst)
3. if rxq_share do forward_shared_rxq(), otherwise do fwd directly
4. get_end_cycle
--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
app/test-pmd/testpmd.h +24 -0
@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void remove_tx_dynf_callback (portid_t portid);int update_jumbo_frame_offload (portid_t portid); +static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) +{ +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc); + +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 )) +forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); +else + (*fwd)(fs, nb_rx, pkts_burst); +get_end_cycles (fs, start_tsc); +} +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function.
Signature · 1 line
2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 32 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly
4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h +8
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void remove_tx_dynf_callback (portid_t portid);int update_jumbo_frame_offload (portid_t portid); +static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) +{ +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))
See below. It reads a global memory.
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1045
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);
New function pointer in fastpath.
IMO, We should not create performance regression for the existing forward engine.
Can we have a new forward engine just for shared memory testing?
Quoted 9 lines
app/test-pmd/testpmd.h +3
-1+get_end_cycles (fs, start_tsc); +} +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 54 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 31 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h index renamed from app/test-pmd/testpmd.h +0
-0
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
Quoted 8 lines
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1045
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around record_core_cycles to minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.
From test perspective, better to have all forward engine to verify shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding engines seamlessly.
Quoted 9 lines
Quoted 9 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 59 lines · Xueming(Steven) Li
Quoted 59 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 31 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h index renamed from app/test-pmd/testpmd.h +0
-0
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);
Quoted 7 lines
Quoted 4 lines
New function pointer in fastpath.
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.
Are you saying there is zero % regression? If not, could you share the data?
Quoted 3 lines
From test perspective, better to have all forward engine to verify shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding engines seamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone.
I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 73 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 18, 2021 7:48 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 63 lines · Xueming(Steven) Li
Quoted 63 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 31 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h index renamed from app/test-pmd/testpmd.h +0
-0
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1045
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.Are you saying there is zero % regression? If not, could you share the data?
Almost zero, here is a quick single core result of rxonly:
32.2Mpps, 58.9cycles/packet Revert the patch to rxonly.c: 32.1Mpps 59.9cycles/packet The result doesn't make sense and I realized that I used batch mbuf free, apply it now: 32.2Mpps, 58.9cycles/packet
There were small digit jumps between testpmd restart, I picked the best one. The result is almost same, seems the cost of each packet is small enough. BTW, I'm testing with default burst size and queue depth.
Quoted 19 lines
Quoted 4 lines
From test perspective, better to have all forward engine to verify
shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding enginesseamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone. I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 83 lines · Xueming(Steven) Li
Quoted 74 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 18, 2021 7:48 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 63 lines · Xueming(Steven) Li
Quoted 63 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 31 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h index renamed from app/test-pmd/testpmd.h +0
-0
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_t portid);void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1045
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.Are you saying there is zero % regression? If not, could you share the data?
Almost zero, here is a quick single core result of rxonly:
Quoted 8 lines
32.2Mpps, 58.9cycles/packet Revert the patch to rxonly.c: 32.1Mpps 59.9cycles/packet The result doesn't make sense and I realized that I used batch mbuf free, apply it now: 32.2Mpps, 58.9cycles/packetThere were small digit jumps between testpmd restart, I picked the best one. The result is almost same, seems the cost of each packet is small enough. BTW, I'm testing with default burst size and queue depth.
I tested this on octeontx2 with iofwd with single core with 100Gbps Without this patch - 73.5mpps
With this patch - 72.8 mpps
We are taking the shared queue runtime option without a separate fwd engine. and to have zero performance impact and no compile time flag Then I think, only way to have a function template .
Example change to outline function template principle.
static inline__pkt_burst_io_forward(struct fwd_stream *fs, const u64 flag) {
Introduce new checks under
if (flags & SHARED_QUEUE)
}
Have two versions of io_fwd_engine.packet_fwd per engine.
- first version
static pkt_burst_io_forward(struct fwd_stream *fs)
{
return __pkt_burst_io_forward(fs, 0);
}- Second version
static pkt_burst_io_forward_shared_queue(struct fwd_stream *fs)
{
return __pkt_burst_io_forward(fs, SHARED_QUEUE);
}Update io_fwd_engine.packet_fwd in slowpath to respective version based on offload.
If shared offoad is not selected, pkt_burst_io_forward() will be selected and __pkt_burst_io_forward() will be a compile time version of !SHARED_QUEUE aka same as existing coe.
Quoted 20 lines
Quoted 20 lines
Quoted 5 lines
From test perspective, better to have all forward engine to verify
shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding enginesseamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone. I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 127 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Thursday, August 26, 2021 7:28 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 86 lines · Xueming(Steven) Li
Quoted 77 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 18, 2021 7:48 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 64 lines · Xueming(Steven) Li
Quoted 64 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 32 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h +0
-0index
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_tportid); void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1042
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
app/test-pmd/testpmd.h void add_tx_dynf_callback(portid_t portid); · line 1045
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.Are you saying there is zero % regression? If not, could you share the data?
Almost zero, here is a quick single core result of rxonly:
Quoted 8 lines
32.2Mpps, 58.9cycles/packet Revert the patch to rxonly.c: 32.1Mpps 59.9cycles/packet The result doesn't make sense and I realized that I used batch mbuf free, apply it now: 32.2Mpps, 58.9cycles/packetThere were small digit jumps between testpmd restart, I picked the best one. The result is almost same, seems the cost of each packet is small enough. BTW, I'm testing with default burst size and queue depth.
I tested this on octeontx2 with iofwd with single core with 100Gbps Without this patch - 73.5mpps With this patch - 72.8 mpps
We are taking the shared queue runtime option without a separate fwd engine.
and to have zero performance impact and no compile time flag Then I think, only way to have a function template . Example change to outline function template principle.static inline
__pkt_burst_io_forward(struct fwd_stream *fs, const u64 flag){Introduce new checks under
if (flags &SHARED_QUEUE)}
Have two versions of io_fwd_engine.packet_fwd per engine.
- first version
static pkt_burst_io_forward(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, 0); }- Second version
Quoted 8 lines
static pkt_burst_io_forward_shared_queue(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, SHARED_QUEUE); }Update io_fwd_engine.packet_fwd in slowpath to respective version based on offload.
If shared offoad is not selected,
pkt_burst_io_forward()will be selected and__pkt_burst_io_forward()will be a compile time version of !SHARED_QUEUE aka same as existing coe.
Thanks for testing and suggestion. So the only difference here in above code is access to rxq_shared changed to function parameter, right? Have you tested this performance? If not, I could verify.
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 7 lines
From test perspective, better to have all forward engine to verify shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding engines
seamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone. I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 143 lines
-----Original Message-----
From: dev <[email protected]> On Behalf Of Xueming(Steven) Li
Sent: Sunday, August 29, 2021 3:08 PM
To: Jerin Jacob <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 132 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Thursday, August 26, 2021 7:28 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 86 lines · Xueming(Steven) Li
Quoted 77 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 18, 2021 7:48 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 64 lines · Xueming(Steven) Li
Quoted 64 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 32 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h +0
-0index
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_tportid); void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
app/test-pmd/testpmd.h
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.Are you saying there is zero % regression? If not, could you share the data?
Almost zero, here is a quick single core result of rxonly:
Quoted 8 lines
32.2Mpps, 58.9cycles/packet Revert the patch to rxonly.c: 32.1Mpps 59.9cycles/packet The result doesn't make sense and I realized that I used batch mbuf free, apply it now: 32.2Mpps, 58.9cycles/packetThere were small digit jumps between testpmd restart, I picked the best one. The result is almost same, seems the cost of each packet is small enough. BTW, I'm testing with default burst size and queue depth.
I tested this on octeontx2 with iofwd with single core with 100Gbps Without this patch - 73.5mpps With this patch - 72.8 mpps
We are taking the shared queue runtime option without a separate fwd engine.
and to have zero performance impact and no compile time flag Then I think, only way to have a function template . Example change to outline function template principle.static inline
__pkt_burst_io_forward(struct fwd_stream *fs, const u64 flag){Introduce new checks under
if (flags &SHARED_QUEUE)}
Have two versions of io_fwd_engine.packet_fwd per engine.
- first version
static pkt_burst_io_forward(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, 0); }- Second version
static pkt_burst_io_forward_shared_queue(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, SHARED_QUEUE); }
Quoted 8 lines
Quoted 5 lines
Update io_fwd_engine.packet_fwd in slowpath to respective version based on offload.
If shared offoad is not selected,
pkt_burst_io_forward()will be
selected and__pkt_burst_io_forward()will be a compile time version of !SHARED_QUEUE aka same as existing coe.Thanks for testing and suggestion. So the only difference here in above code is access to
rxq_sharedchanged to function parameter, right? Have you tested this performance? If not, I could verify.
Performance result looks better by removing this wrapper and hide global variable access like you suggested, thanks! Tried to add rxq_share bit field in struct fwd_stream, same result as the static function selection, looks less changes.
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 9 lines
From test perspective, better to have all forward engine to verify shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding engines
seamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone. I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper function
Quoted 148 lines · Xueming(Steven) Li
Quoted 148 lines
-----Original Message-----
From: dev <[email protected]> On Behalf Of Xueming(Steven) Li
Sent: Sunday, August 29, 2021 3:08 PM
To: Jerin Jacob <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 137 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Thursday, August 26, 2021 7:28 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 86 lines · Xueming(Steven) Li
Quoted 77 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Wednesday, August 18, 2021 7:48 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 64 lines · Xueming(Steven) Li
Quoted 64 lines
-----Original Message-----
From: Jerin Jacob <[email protected]>
Sent: Tuesday, August 17, 2021 5:37 PM
To: Xueming(Steven) Li <[email protected]>
Cc: Jack Min <[email protected]>; dpdk-dev <[email protected]>; Xiaoyun Li <[email protected]>
Subject: Re: [dpdk-dev] [PATCH v2 06/15] app/testpmd: add common fwd wrapper functionQuoted 32 lines · Xueming Li
From: Xiaoyu Min <[email protected]>
Added an inline common wrapper function for all fwd engines which do the following in common:
1.
get_start_cycles
2.rte_eth_rx_burst(...,nb_pkt_per_burst)
3. ifrxq_sharedoforward_shared_rxq(), otherwise do fwd directly 4.get_end_cycleSigned-off-by Xiaoyu Min <[email protected]>--- app/test-pmd/testpmd.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)app/test-pmd/testpmd.h +0
-0index
13141dfed9..b685ac48d6100644app/test-pmd/testpmd.h +0
-0@@ -1022,6 +1022,30 @@ void add_tx_dynf_callback(portid_tportid); void
remove_tx_dynf_callback(portid_t portid); intupdate_jumbo_frame_offload(portid_t portid);app/test-pmd/testpmd.h +7
-0+static inline void +do_burst_fwd (struct fwd_stream *fs,packet_fwd_cb fwd) { +struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; +uint16_t nb_rx; +uint64_t start_tsc =0 ; + +get_start_cycles (&start_tsc);app/test-pmd/testpmd.h
Quoted 10 lines
app/test-pmd/testpmd.h +10
-0+ +/* +* Receive a burst of packets and forward them. +*/ + nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, + pkts_burst, nb_pkt_per_burst); +inc_rx_burst_stats (fs, nb_rx); +if (unlikely (nb_rx ==0 )) +return ; +if (unlikely (rxq_share >0 ))See below. It reads a global memory.
app/test-pmd/testpmd.h
Quoted 3 lines
app/test-pmd/testpmd.h +3
-0+forward_shared_rxq (fs, nb_rx, pkts_burst, fwd); + else + (*fwd)(fs, nb_rx, pkts_burst);New function pointer in fastpath.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
IMO, We should not create performance regression for the existing forward engine. Can we have a new forward engine just for shared memory testing?
Yes, fully aware of the performance concern, the global could be defined around
record_core_cyclesto minimize the impacts. Based on test data, the impacts almost invisible in legacy mode.Are you saying there is zero % regression? If not, could you share the data?
Almost zero, here is a quick single core result of rxonly:
Quoted 8 lines
32.2Mpps, 58.9cycles/packet Revert the patch to rxonly.c: 32.1Mpps 59.9cycles/packet The result doesn't make sense and I realized that I used batch mbuf free, apply it now: 32.2Mpps, 58.9cycles/packetThere were small digit jumps between testpmd restart, I picked the best one. The result is almost same, seems the cost of each packet is small enough. BTW, I'm testing with default burst size and queue depth.
I tested this on octeontx2 with iofwd with single core with 100Gbps Without this patch - 73.5mpps With this patch - 72.8 mpps
We are taking the shared queue runtime option without a separate fwd engine.
and to have zero performance impact and no compile time flag Then I think, only way to have a function template . Example change to outline function template principle.static inline
__pkt_burst_io_forward(struct fwd_stream *fs, const u64 flag){Introduce new checks under
if (flags &SHARED_QUEUE)}
Have two versions of io_fwd_engine.packet_fwd per engine.
- first version
static pkt_burst_io_forward(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, 0); }- Second version
static pkt_burst_io_forward_shared_queue(struct fwd_stream *fs) { return __pkt_burst_io_forward(fs, SHARED_QUEUE); }Update io_fwd_engine.packet_fwd in slowpath to respective version based on offload.
If shared offoad is not selected,
pkt_burst_io_forward()will be
selected and__pkt_burst_io_forward()will be a compile time version of !SHARED_QUEUE aka same as existing coe.
Quoted 5 lines
Quoted 2 lines
Thanks for testing and suggestion. So the only difference here in above code is access to
rxq_sharedchanged to function parameter, right? Have you tested this performance? If not, I could verify.Performance result looks better by removing this wrapper and hide global variable access like you suggested, thanks! Tried to add
rxq_sharebit field in structfwd_stream, same result as the static function selection, looks less changes.
The changes reflected in v3, also consolidated patches for each forwarding engine into one, please check.
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 9 lines
From test perspective, better to have all forward engine to verify shared rxq, test team want to run the regression with less impacts. Hope to have a solution to utilize all forwarding engines
seamlessly.
Yes. it good goal. testpmd forward performance using as synthetic bench everyone. I think, we are aligned to not have any regression for the generic forward engine.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
app/test-pmd/testpmd.h +2
-1+get_end_cycles (fs, start_tsc); } +/* * Work-around of a compilation error with ICC on invocations of the * rte_be_to_cpu_16() function. -- 2.25.1
PATCH v2 7/15 app/testpmd: support shared Rx queues for IO forwarding
In reply to Xueming LiSupports shared Rx queue.
If shared Rx queue is enabled, group received packets by stream according to mbuf->port value and then and forward in stream basis as before.
If shared Rx queue is not enabled, just forward in stream basis.
--- app/test-pmd/iofwd.c | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-)
app/test-pmd/iofwd.c +10 -17
@@ -44,25 +44,11 @@* to packets data. */ static void -pkt_burst_io_forward (struct fwd_stream *fs) +io_forward_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; -uint16_t nb_rx;uint16_t nb_tx;uint32_t retry; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* -* Receive a burst of packets and forward them. -*/ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, - pkts_burst, nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; - fs->rx_packets += nb_rx; nb_tx =rte_eth_tx_burst (fs->tx_port, fs->tx_queue, pkts_burst, nb_rx);
@@ -85,8 +71,15 @@ pkt_burst_io_forward(struct fwd_stream *fs)rte_pktmbuf_free (pkts_burst[nb_tx]); }while (++nb_tx < nb_rx); } +} -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine. +*/ +static void +pkt_burst_io_forward (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, io_forward_stream); }struct fwd_engine io_fwd_engine = {
Signature · 1 line
2.25.1
PATCH v2 8/15 app/testpmd: support shared Rx queue for rxonly forwarding
In reply to Xueming LiSupports shared Rx queue.
If shared Rx queue is enabled, group received packets by stream according to mbuf->port value and then and forward in stream basis as before.
If shared Rx queue is not enabled, just forward in stream basis.
--- app/test-pmd/rxonly.c | 34 +++++++++++++--------------------- 1 file changed, 13 insertions(+), 21 deletions(-)
app/test-pmd/rxonly.c +13 -21
@@ -41,32 +41,24 @@#include "testpmd.h" /* -* Received a burst of packets. +* Process a burst of received packets from same stream. */ static void -pkt_burst_receive (struct fwd_stream *fs) +rxonly_forward_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ]; -uint16_t nb_rx; -uint16_t i; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* -* Receive a burst of packets. -*/ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; +RTE_SET_USED (fs); +rte_pktmbuf_free_bulk (pkts_burst, nb_rx); +} - fs->rx_packets += nb_rx; -for (i =0 ; i < nb_rx; i++) -rte_pktmbuf_free (pkts_burst[i]); -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine. +*/ +static void +pkt_burst_receive (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, rxonly_forward_stream); }struct fwd_engine rx_only_engine = {
Signature · 1 line
2.25.1
PATCH v2 9/15 app/testpmd: support shared Rx queue for icmpecho fwd
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Add support of shared rxq.
If shared rxq is enabled, filter packet by stream according to mbuf->port value and then fwd it in stream basis (as before).
If shared rxq is not enabled, just fwd it in stream basis.
--- app/test-pmd/icmpecho.c | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-)
app/test-pmd/icmpecho.c +13 -20
@@ -267,13 +267,13 @@ ipv4_hdr_cksum(struct rte_ipv4_hdr *ip_h) (((rte_be_to_cpu_32 ((ipv4_addr)) >>24 ) &0x000000FF ) ==0xE0 )/* -* Receive a burst of packets, lookup for ICMP echo requests, and, if any, -* send back ICMP echo replies. +* Lookup for ICMP echo requests in received mbuf and, if any, +* send back ICMP echo replies to corresponding Tx port. */static void -reply_to_icmp_echo_rqsts (struct fwd_stream *fs) +reply_to_icmp_echo_rqsts_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ];struct rte_mbuf *pkt;struct rte_ether_hdr *eth_h;struct rte_vlan_hdr *vlan_h;
@@ -283,7 +283,6 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)struct rte_ether_addr eth_addr;uint32_t retry;uint32_t ip_addr; -uint16_t nb_rx;uint16_t nb_tx;uint16_t nb_replies;uint16_t eth_type;
@@ -291,22 +290,9 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)uint16_t arp_op;uint16_t arp_pro;uint32_t cksum; -uint8_t i; +uint16_t i;int l2_len; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* -* First, receive a burst of packets. -*/ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; - fs->rx_packets += nb_rx; nb_replies =0 ;for (i =0 ; i < nb_rx; i++) {if (likely (i < nb_rx -1 ))
@@ -509,8 +495,15 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs) }while (++nb_tx < nb_replies); } } +} -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine. +*/ +static void +reply_to_icmp_echo_rqsts (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, reply_to_icmp_echo_rqsts_stream); }struct fwd_engine icmp_echo_engine = {
Signature · 1 line
2.25.1
PATCH v2 10/15 app/testpmd: support shared Rx queue for csum fwd
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Add support of shared rxq.
If shared rxq is enabled, filter packet by stream according to mbuf->port value and then fwd it in stream basis (as before).
If shared rxq is not enabled, just fwd it in stream basis.
--- app/test-pmd/csumonly.c | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-)
app/test-pmd/csumonly.c +11 -17
@@ -763,7 +763,7 @@ pkt_copy_split(const struct rte_mbuf *pkt) }/* -* Receive a burst of packets, and for each packet: +* For each packet in received mbuf: * - parse packet, and try to recognize a supported packet type (1) * - if it's not a supported packet type, don't touch the packet, else: * - reprocess the checksum of all supported layers. This is done in SW
@@ -792,9 +792,9 @@ pkt_copy_split(const struct rte_mbuf *pkt)* OUTER_IP is only useful for tunnel packets. */ static void -pkt_burst_checksum_forward (struct fwd_stream *fs) +checksum_forward_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ];struct rte_mbuf *gso_segments[GSO_MAX_PKT_BURST ];struct rte_gso_ctx *gso_ctx;struct rte_mbuf **tx_pkts_burst;
@@ -805,7 +805,6 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)void **gro_ctx;uint16_t gro_pkts_num;uint8_t gro_enable; -uint16_t nb_rx;uint16_t nb_tx;uint16_t nb_prep;uint16_t i;
@@ -820,18 +819,6 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)uint16_t nb_segments =0 ;int ret; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* receive a burst of packet */ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; - - fs->rx_packets += nb_rx; rx_bad_ip_csum =0 ; rx_bad_l4_csum =0 ; rx_bad_outer_l4_csum =0 ;
@@ -1139,8 +1126,15 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)rte_pktmbuf_free (tx_pkts_burst[nb_tx]); }while (++nb_tx < nb_rx); } +} -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine. +*/ +static void +pkt_burst_checksum_forward (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, checksum_forward_stream); }struct fwd_engine csum_fwd_engine = {
Signature · 1 line
2.25.1
PATCH v2 11/15 app/testpmd: support shared Rx queue for flowgen
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Add support of shared rxq.
If shared rxq is enabled, filter packet by stream according to mbuf->port value and then do stats in stream basis (as before).
If shared rxq is not enabled, just as usual in stream basis.
--- app/test-pmd/flowgen.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)
app/test-pmd/flowgen.c +10 -12
@@ -83,10 +83,10 @@ ip_sum(const alias_int16_t *hdr, int hdr_len)* still do so in order to maintain traffic statistics. */ static void -pkt_burst_flow_gen (struct fwd_stream *fs) +flow_gen_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) {unsigned pkt_size = tx_pkt_length -4 ;/* Adjust FCS */ -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ];struct rte_mempool *mbp;struct rte_mbuf *pkt =NULL ;struct rte_ether_hdr *eth_hdr;
@@ -94,23 +94,14 @@ pkt_burst_flow_gen(struct fwd_stream *fs)struct rte_udp_hdr *udp_hdr;uint16_t vlan_tci, vlan_tci_outer;uint64_t ol_flags =0 ; -uint16_t nb_rx;uint16_t nb_tx;uint16_t nb_pkt;uint16_t nb_clones = nb_pkt_flowgen_clones;uint16_t i;uint32_t retry;uint64_t tx_offloads; -uint64_t start_tsc =0 ;static int next_flow =0 ; -get_start_cycles (&start_tsc); - -/* Receive a burst of packets and discard them. */ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); - fs->rx_packets += nb_rx; -for (i =0 ; i < nb_rx; i++)rte_pktmbuf_free (pkts_burst[i]);
@@ -213,8 +204,15 @@ pkt_burst_flow_gen(struct fwd_stream *fs)rte_pktmbuf_free (pkts_burst[nb_tx]); }while (++nb_tx < nb_pkt); } +} -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine +*/ +static void +pkt_burst_flow_gen (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, flow_gen_stream); }struct fwd_engine flow_gen_engine = {
Signature · 1 line
2.25.1
PATCH v2 12/15 app/testpmd: support shared Rx queue for MAC fwd
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Add support of shared rxq.
If shared rxq is enabled, filter packet by stream according to mbuf->port value and then fwd it in stream basis (as before).
If shared rxq is not enabled, just fwd it as usual in stream basis.
--- app/test-pmd/macfwd.c | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-)
app/test-pmd/macfwd.c +10 -17
@@ -44,32 +44,18 @@* before forwarding them. */ static void -pkt_burst_mac_forward (struct fwd_stream *fs) +mac_forward_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ];struct rte_port *txp;struct rte_mbuf *mb;struct rte_ether_hdr *eth_hdr;uint32_t retry; -uint16_t nb_rx;uint16_t nb_tx;uint16_t i;uint64_t ol_flags =0 ;uint64_t tx_offloads; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* -* Receive a burst of packets and forward them. -*/ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; - fs->rx_packets += nb_rx; txp = &ports[fs->tx_port]; tx_offloads = txp->dev_conf.txmode.offloads;if (tx_offloads &DEV_TX_OFFLOAD_VLAN_INSERT )
@@ -116,8 +102,15 @@ pkt_burst_mac_forward(struct fwd_stream *fs)rte_pktmbuf_free (pkts_burst[nb_tx]); }while (++nb_tx < nb_rx); } +} -get_end_cycles (fs, start_tsc); +/* +* Wrapper of real fwd engine. +*/ +static void +pkt_burst_mac_forward (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, mac_forward_stream); }struct fwd_engine mac_fwd_engine = {
Signature · 1 line
2.25.1
PATCH v2 13/15 app/testpmd: support shared Rx queue for macswap fwd
In reply to Xueming LiFrom: Xiaoyu Min <[email protected]>
Add support of shared rxq.
If shared rxq is enabled, filter packet by stream according to mbuf->port value and then fwd it in stream basis (as before).
If shared rxq is not enabled, just fwd it as usual in stream basis.
--- app/test-pmd/macswap.c | 28 +++++++++++----------------- 1 file changed, 11 insertions(+), 17 deletions(-)
app/test-pmd/macswap.c +11 -17
@@ -50,27 +50,13 @@* addresses of packets before forwarding them. */ static void -pkt_burst_mac_swap (struct fwd_stream *fs) +mac_swap_stream (struct fwd_stream *fs,uint16_t nb_rx, +struct rte_mbuf **pkts_burst) { -struct rte_mbuf *pkts_burst[MAX_PKT_BURST ];struct rte_port *txp; -uint16_t nb_rx;uint16_t nb_tx;uint32_t retry; -uint64_t start_tsc =0 ; - -get_start_cycles (&start_tsc); - -/* -* Receive a burst of packets and forward them. -*/ - nb_rx =rte_eth_rx_burst (fs->rx_port, fs->rx_queue, pkts_burst, - nb_pkt_per_burst); -inc_rx_burst_stats (fs, nb_rx); -if (unlikely (nb_rx ==0 )) -return ; - fs->rx_packets += nb_rx; txp = &ports[fs->tx_port];do_macswap (pkts_burst, nb_rx, txp);
@@ -95,7 +81,15 @@ pkt_burst_mac_swap(struct fwd_stream *fs)rte_pktmbuf_free (pkts_burst[nb_tx]); }while (++nb_tx < nb_rx); } -get_end_cycles (fs, start_tsc); +} + +/* +* Wrapper of real fwd engine. +*/ +static void +pkt_burst_mac_swap (struct fwd_stream *fs) +{ +return do_burst_fwd (fs, mac_swap_stream); }struct fwd_engine mac_swap_engine = {
Signature · 1 line
2.25.1