From: 王星 <xing_wang@realsil.com.cn>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: 陈立 <dali_chen@realsil.com.cn>, 王颢 <howard_wang@realsil.com.cn>
Subject: about RTL8168 PMD on ARM SoC
Date: Thu, 25 Aug 2022 02:53:09 +0000 [thread overview]
Message-ID: <e6c53cdd2ab148adb4e1c30e0c11ec44@realsil.com.cn> (raw)
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
Hi DPDK,
I am a pmd driver developer from Realtek NIC department,
when I was porting r8168pmd already verified on x86 to an ARM64 SoC Unisoc: UIS8650
I found that after NIC Rx init (in general, Rx ring and buffers should have been prepared for NIC to DMA read),
the NIC status reg showed RDU (Rx Descriptor Unavailable), which means NIC cannot read the proper desc content,
later I sended some packets to NIC hold by testpmd rx_only mode, HW internal Rx packet counter can grow to some value, then stuck, 8168pmd Rx debug print reported it received less packets than that value, and the print showed up even some minutes later!
I doubt the phenomenon is caused by improper HW-based IO coherency support on this ARM SoC,
I have read the ARM SoC support list on DPDK website, to name it: NV Bluefield, NXP DPAA, Marvell Octeon TX …
Does DPDK (or UIO/VFIO driver or hugetlb driver) need special HW IO cache coherency support on ARM platform, say, ACE and Device side MMU etc?
Should the SoC provide specialized UIO/VFIO driver or hugetlb driver and/or specific DPDK lib to support such user mode DMA?
Will you please give suggestions, thanks a lot!
BRs
[-- Attachment #2: Type: text/html, Size: 4485 bytes --]
next reply other threads:[~2022-08-25 7:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 2:53 王星 [this message]
2022-08-25 14:41 ` Honnappa Nagarahalli
2022-08-26 2:06 ` 答复: " 王星
2022-08-26 2:36 ` 王星
2022-08-26 16:44 ` Honnappa Nagarahalli
2022-08-29 15:40 ` Hau
2022-09-02 7:17 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6c53cdd2ab148adb4e1c30e0c11ec44@realsil.com.cn \
--to=xing_wang@realsil.com.cn \
--cc=dali_chen@realsil.com.cn \
--cc=dev@dpdk.org \
--cc=howard_wang@realsil.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).