Re: [PATCH v1] net/e1000: do not update link status in secondary process
>> The code to update link status is not safe in secondary process. >> If called from secondary it will crash, example from dumpcap: >> eth_em_link_update >> >> Signed-off-by: Jun Wang > > Wouldn't it be better to fix the code in e1000_check_link to work in > secondary process. There are network virtual appliances that use > secondary process for all processing. Yes, the e1000 virtual network card currently does not work properly in the secondary process. After skipping eth_em_link_update, I tested the e1000 card and it was able to capture packets normally. For the secondary process, I think eth_em_link_update is not necessary. Jun Wang
[PATCH] net/hns3: add Rx DMA address align check
From: Chengwen Feng
The network engine has Rx DMA address align requirement, if this
requirement is violated, the Rx function will be abnormal. The detail
requirement is:
1) For HIP08 platform, require 64-bytes alignment.
2) For later platform, require 128-bytes alignment.
The setup Rx DMA address exists both on the control and data plane, to
ensure performance, the alignment check is added only on the control
plane.
Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
Signed-off-by: Jie Hai
---
drivers/net/hns3/hns3_ethdev.c| 2 ++
drivers/net/hns3/hns3_ethdev.h| 8
drivers/net/hns3/hns3_ethdev_vf.c | 2 ++
drivers/net/hns3/hns3_rxtx.c | 21 +
4 files changed, 33 insertions(+)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 9730b9a7e9f6..2340fb21b1ad 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2738,6 +2738,7 @@ hns3_get_capability(struct hns3_hw *hw)
hw->rss_info.ipv6_sctp_offload_supported = false;
hw->udp_cksum_mode = HNS3_SPECIAL_PORT_SW_CKSUM_MODE;
pf->support_multi_tc_pause = false;
+ hw->rx_dma_addr_align = HNS3_RX_DMA_ADDR_ALIGN_64;
return 0;
}
@@ -2758,6 +2759,7 @@ hns3_get_capability(struct hns3_hw *hw)
hw->rss_info.ipv6_sctp_offload_supported = true;
hw->udp_cksum_mode = HNS3_SPECIAL_PORT_HW_CKSUM_MODE;
pf->support_multi_tc_pause = true;
+ hw->rx_dma_addr_align = HNS3_RX_DMA_ADDR_ALIGN_128;
return 0;
}
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index e70c5fff2a45..c190d5109b91 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -487,6 +487,9 @@ struct hns3_queue_intr {
#define HNS3_PKTS_DROP_STATS_MODE1 0
#define HNS3_PKTS_DROP_STATS_MODE2 1
+#define HNS3_RX_DMA_ADDR_ALIGN_128 128
+#define HNS3_RX_DMA_ADDR_ALIGN_64 64
+
struct hns3_hw {
struct rte_eth_dev_data *data;
void *io_base;
@@ -554,6 +557,11 @@ struct hns3_hw {
* direction.
*/
uint8_t min_tx_pkt_len;
+ /*
+* The required alignment of the DMA address of the RX buffer.
+* See HNS3_RX_DMA_ADDR_ALIGN_XXX for available values.
+*/
+ uint16_t rx_dma_addr_align;
struct hns3_queue_intr intr;
/*
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c
b/drivers/net/hns3/hns3_ethdev_vf.c
index 4eeb46a34448..465280dce40c 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -707,6 +707,7 @@ hns3vf_get_capability(struct hns3_hw *hw)
hw->min_tx_pkt_len = HNS3_HIP08_MIN_TX_PKT_LEN;
hw->rss_info.ipv6_sctp_offload_supported = false;
hw->promisc_mode = HNS3_UNLIMIT_PROMISC_MODE;
+ hw->rx_dma_addr_align = HNS3_RX_DMA_ADDR_ALIGN_64;
return 0;
}
@@ -724,6 +725,7 @@ hns3vf_get_capability(struct hns3_hw *hw)
hw->drop_stats_mode = HNS3_PKTS_DROP_STATS_MODE2;
hw->rss_info.ipv6_sctp_offload_supported = true;
hw->promisc_mode = HNS3_LIMIT_PROMISC_MODE;
+ hw->rx_dma_addr_align = HNS3_RX_DMA_ADDR_ALIGN_128;
return 0;
}
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index f4ec1f8e5823..2354091e1dd6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -274,12 +274,27 @@ hns3_free_all_queues(struct rte_eth_dev *dev)
hns3_free_tx_queues(dev);
}
+static int
+hns3_check_rx_dma_addr(struct hns3_hw *hw, uint64_t dma_addr)
+{
+ uint64_t rem;
+
+ rem = dma_addr & (hw->rx_dma_addr_align - 1);
+ if (rem > 0) {
+ hns3_err(hw, "The IO address of the beginning of the mbuf data "
+"must be %u-byte aligned", hw->rx_dma_addr_align);
+ return -EINVAL;
+ }
+ return 0;
+}
+
static int
hns3_alloc_rx_queue_mbufs(struct hns3_hw *hw, struct hns3_rx_queue *rxq)
{
struct rte_mbuf *mbuf;
uint64_t dma_addr;
uint16_t i;
+ int ret;
for (i = 0; i < rxq->nb_rx_desc; i++) {
mbuf = rte_mbuf_raw_alloc(rxq->mb_pool);
@@ -300,6 +315,12 @@ hns3_alloc_rx_queue_mbufs(struct hns3_hw *hw, struct
hns3_rx_queue *rxq)
dma_addr = rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
rxq->rx_ring[i].addr = dma_addr;
rxq->rx_ring[i].rx.bd_base_info = 0;
+
+ ret = hns3_check_rx_dma_addr(hw, dma_addr);
+ if (ret != 0) {
+ hns3_rx_queue_release_mbufs(rxq);
+ return ret;
+ }
}
return 0;
--
2.33.0
Re: [PATCH v6 2/2] bus/pci: fix secondary process save 'FD' problem
Hi David,
> On Jul 13, 2024, at 01:30, David Marchand wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hello,
>
> On Tue, Jul 2, 2024 at 9:40 AM Chaoyong He wrote:
>>
>> From: Zerun Fu
>>
>> In the previous logic the 'fd' was only saved in the primary process,
>> but for some devices this value is also used in the secondary logic.
>>
>> For example, the call of 'rte_pci_find_ext_capability()' will fail in
>> the secondary process.
>>
>> Fix this problem by getting and saving the value of 'fd' also in the
>> secondary process logic.
>>
>> Fixes: 9b957f378abf ("pci: merge uio functions for linux and bsd")
>> Cc: muk...@igel.co.jp
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Zerun Fu
>> Reviewed-by: Chaoyong He
>> Reviewed-by: Long Wu
>> Reviewed-by: Peng Zhang
>> Acked-by: Anatoly Burakov
>
> Chenbo,
> Are you ok with this fix?
Sorry that I was interrupted when I was reviewing this and later I forgot..
For this patch:
Reviewed-by: Chenbo Xia
>
> Thanks.
>
> --
> David Marchand
[DPDK/doc Bug 1488] Suggestion: add documentation to fill in total_length etc. to UDP checksum offloading?
https://bugs.dpdk.org/show_bug.cgi?id=1488 Bug ID: 1488 Summary: Suggestion: add documentation to fill in total_length etc. to UDP checksum offloading? Product: DPDK Version: 24.07 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: doc Assignee: dev@dpdk.org Reporter: user202...@protonmail.com Target Milestone: --- Currently, the documentation of RTE_MBUF_F_TX_UDP_CKSUM in https://doc.dpdk.org/api/rte__mbuf__core_8h.html#ada511d6f30184b374ba2248c26af8ede is very sparse: > UDP cksum of TX pkt. computed by NIC. I think it should mention which fields should be set. Some bug reports e.g. https://github.com/amzn/amzn-drivers/issues/176 https://github.com/amzn/amzn-drivers/issues/79 states that you need to set m3_len, total_length, dgram_cksum to the pseudo-header checksum etc. (not sure about this). What is the actual requirement of that flag, and how should the documentation be edited? -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v6 1/2] bus/pci: fix secondary process PCI uio resource map problem
On 2024/7/2 15:40, Chaoyong He wrote:
> From: Zerun Fu
>
> For the primary process, the logic loops all BARs and will skip
> the map of BAR with an invalid physical address (0), also will
> assign 'uio_res->nb_maps' with the real mapped BARs number. But
> for the secondary process, instead of loops all BARs, the logic
> using the 'uio_res->nb_map' as index. If the device uses continuous
> BARs there will be no problem, whereas if it uses discrete BARs,
> it will lead to mapping errors.
>
> Fix this problem by also loops all BARs and skip the map of BAR
> with an invalid physical address in secondary process.
>
> Fixes: 9b957f378abf ("pci: merge uio functions for linux and bsd")
Fixes: e6cf7bee1c77 ("bus/pci: fix UIO resource access from secondary process")
> Cc: muk...@igel.co.jp
> Cc: sta...@dpdk.org
>
> Signed-off-by: Zerun Fu
> Reviewed-by: Chaoyong He
> Reviewed-by: Long Wu
> Reviewed-by: Peng Zhang
> Acked-by: Anatoly Burakov
Tested-by: Dengdui Huang
