From: Garrett D'Amore <garrett@damore.org>
To: dev@dpdk.org, Philip Prindeville <philipp_subx@redfish-solutions.com>
Subject: Re: DPDK packaging and OpenWrt
Date: Tue, 16 May 2023 16:06:42 -0700 [thread overview]
Message-ID: <470f0311-ed76-4134-8d62-f4db7269f1d6@Spark> (raw)
In-Reply-To: <60A57C56-D30C-4B0F-BAE9-01BA6FD16E66@redfish-solutions.com>
[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]
On May 16, 2023 at 12:19 PM -0700, Philip Prindeville <philipp_subx@redfish-solutions.com>, wrote:
> Hi,
>
> I'm a packaging maintainer for some of the OpenWrt ancillary packages, and I'm looking at upstreaming DPDK support into OpenWrt. Apologies in advance if this is a bit dense (a brain dump) or hops between too many topics.
>
> I was looking at what's been done to date, and it seems there are a few shortcomings which I hope to address.
>
> Amongst them are:
>
>
> I have some related questions.
>
> 1. OpenWrt already bakes "vfio.ko" and "vfio-pci.ko" here:
>
> https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/virt.mk#L77-L117
>
> but does so with "CONFIG_VFIO_PCI_IGD=y", which seems to be specifically for VGA acceleration of guests in a virtualized environment. That seems to be an odd corner case, and unlikely given that OpenWrt almost always runs on headless hardware. Should this be reverted?
>
> 2. "vfio.ko" is built with "CONFIG_VFIO_NOIOMMU=y", which seems insecure. Can this be reverted?
>
> 3. Is "uio_pci_generic.ko" worth the potential insecurity/instability of a misbehaving application? My understanding is that it's only needed on SR-IOV hardware where MSI/MSI-X interrupts aren't supported: is there even any current hardware that doesn't support MSI/MSI-X? Or am I misunderstanding the use case?
*Either* uio_pci_generic *or* vfio with NOIOMMU are required for the vary large number of systems that either lack an IOMMU (btw, that will be nearly all OpenWRT platforms!), or elect to run with the iommu unconfigured (one justification for doing that - apart from numerous software bugs and limitations — is that the IOMMU can slow down I/O. We actually recommend most of our customers that run dedicated systems run with the IOMMU disabled for this reason.)
vfio with noiommu is preferable.
>
> 4. Can most functionality be achieved with VFIO + IOMMU support?
*If* you have an IOMMU, and you aren’t trying to eke the very last bits of performance, yes. But as many systems don’t have an IOMMU, and as one of the main points of DPDK are extremely performance sensitive applications, I think the answer is more broadly, “no”.
> 11. What is the user-space TCP/IP stack of choice (or reference) for use with DPDK?
IMO, if you’re using DPDK to run *TCP* applications then you’re probably misusing it — there isn’t a user land TCP stack that I would trust. IP/UDP is something we do, and it works well, but I can tell you already it’s a pain to do *just* IP, because e.g. routing tables, ARP, etc. all have to be handled.
• Garrett
[-- Attachment #2: Type: text/html, Size: 3536 bytes --]
next prev parent reply other threads:[~2023-05-16 23:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 19:18 Philip Prindeville
2023-05-16 20:43 ` Stephen Hemminger
2023-05-16 23:24 ` Philip Prindeville
2023-05-16 23:41 ` Stephen Hemminger
2023-05-16 23:43 ` Stephen Hemminger
2023-05-16 23:06 ` Garrett D'Amore [this message]
2023-05-16 23:38 ` Philip Prindeville
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=470f0311-ed76-4134-8d62-f4db7269f1d6@Spark \
--to=garrett@damore.org \
--cc=dev@dpdk.org \
--cc=philipp_subx@redfish-solutions.com \
/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).