DPDK patches and discussions
 help / color / mirror / Atom feed
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
To: "Garrett D'Amore" <garrett@damore.org>
Cc: dev@dpdk.org
Subject: Re: DPDK packaging and OpenWrt
Date: Tue, 16 May 2023 17:38:41 -0600	[thread overview]
Message-ID: <F70413AA-0CCC-4B9B-84CC-F9BBE5DB4B60@redfish-solutions.com> (raw)
In-Reply-To: <470f0311-ed76-4134-8d62-f4db7269f1d6@Spark>



> On May 16, 2023, at 5:06 PM, Garrett D'Amore <garrett@damore.org> wrote:
> 
> On May 16, 2023 at 12:19 PM -0700, Philip Prindeville <philipp_subx@redfish-solutions.com>, wrote:
> [snip]
> 
> 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.


I could build with CONFIG_NOIOMMU=n and then package the modprobe .conf file (or the grub command-line, etc) to have enable_unsafe_noiommu_mode=1, right?

This would accomplish the same thing at run-time, but allow the module to be built to be used either with or without an IOMMU?

That's per:

https://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html

But I don't know how recent that advice is...


> 
> 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


Yeah, good point.  Are there shims to use with FRR, lldpd, et al for example?



      reply	other threads:[~2023-05-16 23:38 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
2023-05-16 23:38   ` Philip Prindeville [this message]

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=F70413AA-0CCC-4B9B-84CC-F9BBE5DB4B60@redfish-solutions.com \
    --to=philipp_subx@redfish-solutions.com \
    --cc=dev@dpdk.org \
    --cc=garrett@damore.org \
    /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).