RE: RFC - Tap io_uring PMD
> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 12 November 2024 06.21 > > On Wed, 6 Nov 2024 08:46:55 +0100 > Maxime Coquelin wrote: > > > > Why not just use Virtio-user PMD with Vhost-kernel backend [0]? > > Are there any missing features that io_uring can address? > > > > Regards, > > Maxime > > > > [0]: > http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html > > > > Yes, I looked at that but: > - virtio user ends up with a busy kernel thread which is not > acceptable > in SOC environment where all resources are locked down. In the SOC > I was working > on DPDK was limited to 4 polling isolated CPU's and 1 sleeping main > thread. > The rest of the CPU resources were hard constrained by cgroups. The > virtio user > thread was a problem. I suppose the Kernel needs to schedule CPU resources to process the packets at some point anyway. So how does the ioring driver improve the situation with the virtio-user thread? I.e. what's the difference in the way the Kernel handles these two types of drivers? And a slightly related question: Are there any differences in throughput, latency or other performance metrics? (At very high bandwidth, scheduling latency matters; the "latency" parameter of the BDP becomes dominant.) Overall, I'm trying to figure out when to use the virtio-user PMD, and when to use the ioring PMD. Eventually, this should be described in the driver documentation or a user guide. > > - virtio user device is not persistent. If DPDK is being used a > dataplane, need to > be able to quickly restart and not disturb applications and routing > in the kernel > while the tap device is unavailable. I.e having device present but > in no carrier > state is better than having to teach applications about hot plug or > play around > with multiple addresses on loopback device (which is what Cisco > routers do). virtio-user device persistence can probably be achieved in some other way. (E.g. a persistent user space daemon could be used as a middle man for allocation. Just an idea; probably better solutions are available, if given more brain cycles.)
[PATCH 2/3] net/hns3: remove pvid info dump for VF
Since the pvid status obtained from kernel varies on different
platform, and the pvid of VF can be accessed by 'ip link show'
command, so remove it in case of misunderstanding.
Fixes: 871e5a4f881b ("net/hns3: dump VLAN configuration info")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/hns3/hns3_dump.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/hns3/hns3_dump.c b/drivers/net/hns3/hns3_dump.c
index 738dcb0c42fc..f21d32e6a2b5 100644
--- a/drivers/net/hns3/hns3_dump.c
+++ b/drivers/net/hns3/hns3_dump.c
@@ -693,6 +693,10 @@ hns3_get_vlan_tx_offload_cfg(FILE *file, struct hns3_hw
*hw)
static void
hns3_get_port_pvid_info(FILE *file, struct hns3_hw *hw)
{
+ struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
+ if (hns->is_vf)
+ return;
+
fprintf(file, " - pvid status: %s\n",
hw->port_base_vlan_cfg.state ? "On" : "Off");
}
--
2.22.0
[PATCH 3/3] net/hns3: rename RAS module
Rename ROH_MAC module as HIMAC to avoid misunderstandings.
Fixes: 1c1eb759e9d7 ("net/hns3: support RAS process in Kunpeng 930")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/hns3/hns3_intr.c | 4 ++--
drivers/net/hns3/hns3_intr.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hns3/hns3_intr.c b/drivers/net/hns3/hns3_intr.c
index 2de2b86b0297..db5c84061ca3 100644
--- a/drivers/net/hns3/hns3_intr.c
+++ b/drivers/net/hns3/hns3_intr.c
@@ -1432,8 +1432,8 @@ static const struct hns3_hw_mod_name
hns3_hw_module_name[] = {
.module_name = MODULE_MASTER,
.msg = "MODULE_MASTER"
}, {
- .module_name = MODULE_ROH_MAC,
- .msg = "MODULE_ROH_MAC"
+ .module_name = MODULE_HIMAC,
+ .msg = "MODULE_HIMAC"
}
};
diff --git a/drivers/net/hns3/hns3_intr.h b/drivers/net/hns3/hns3_intr.h
index 1edb07de361b..e88b00c9c986 100644
--- a/drivers/net/hns3/hns3_intr.h
+++ b/drivers/net/hns3/hns3_intr.h
@@ -104,7 +104,7 @@ enum hns3_mod_name_list {
MODULE_RCB_TX,
MODULE_TXDMA,
MODULE_MASTER,
- MODULE_ROH_MAC,
+ MODULE_HIMAC,
};
enum hns3_err_type_list {
--
2.22.0
[PATCH 1/3] net/hns3: fix simple Tx path incorrect free the mbuf
From: Dengdui Huang
When RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE offload is not set,
use rte_pktmbuf_free_seg() to free the mbuf.
Fixes: 7ef933908f04 ("net/hns3: add simple Tx path")
Cc: sta...@dpdk.org
Signed-off-by: Dengdui Huang
Signed-off-by: Jie Hai
---
drivers/net/hns3/hns3_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 03bbbc435fac..09e39cb673cb 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -4006,7 +4006,7 @@ hns3_tx_free_buffer_simple(struct hns3_tx_queue *txq)
for (i = 0; i < txq->tx_rs_thresh; i++)
rte_prefetch0((tx_entry + i)->mbuf);
for (i = 0; i < txq->tx_rs_thresh; i++, tx_entry++) {
- rte_mempool_put(tx_entry->mbuf->pool, tx_entry->mbuf);
+ rte_pktmbuf_free_seg(tx_entry->mbuf);
tx_entry->mbuf = NULL;
}
--
2.22.0
[PATCH 0/3] net/hns3: bugfix on hns3
The patchset fixes some codes. Dengdui Huang (1): net/hns3: fix simple Tx path incorrect free the mbuf Jie Hai (2): net/hns3: remove pvid info dump for VF net/hns3: rename RAS module drivers/net/hns3/hns3_dump.c | 4 drivers/net/hns3/hns3_intr.c | 4 ++-- drivers/net/hns3/hns3_intr.h | 2 +- drivers/net/hns3/hns3_rxtx.c | 2 +- 4 files changed, 8 insertions(+), 4 deletions(-) -- 2.22.0
