From: Stephen Hemminger <stephen@networkplumber.org>
To: Jan Viktorin <viktorin@rehivetech.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] VFIO no-iommu
Date: Thu, 17 Dec 2015 15:29:09 -0800 [thread overview]
Message-ID: <20151217152909.4c7cbaff@xeon-e3> (raw)
In-Reply-To: <20151217203816.1bc6bd2c@jvn>
On Thu, 17 Dec 2015 20:38:16 +0100
Jan Viktorin <viktorin@rehivetech.com> wrote:
> On Thu, 17 Dec 2015 11:09:23 +0100
> Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
>
> > Hi,
> >
> > 2015-12-17 09:52, Burakov, Anatoly:
> > > > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > > > > > > So it works. Is it acceptable? Useful? Sufficiently complete?
> > > > > > > Does it imply deprecating the uio interface? I believe the
> > > > > > > feature that started this discussion was support for MSI/X
> > > > > > > interrupts so that VFs can support some kind of interrupt (uio
> > > > > > > only supports INTx since it doesn't allow DMA). Implementing that
> > > > > > > would be the ultimate test of whether this provides dpdk with not
> > > > > > > only a more consistent interface, but the feature dpdk wants
> > > > > > > that's missing in uio. Thanks,
> > > > >
> > > > > Ferruh has done a great job so far testing Alex's patch, very few changes
> > > > from DPDK side seem to be required as far as existing functionality goes (not
> > > > sure about VF interrupts mentioned by Alex). However, one thing that
> > > > concerns me is usability. While it is true that no-IOMMU mode in VFIO would
> > > > mean uio interfaces could be deprecated in time, the no-iommu mode is way
> > > > more hassle than using igb_uio/uio_pci_generic because it will require a
> > > > kernel recompile as opposed to simply compiling and insmod'ding an out-of-
> > > > tree driver. So, in essence, if you don't want an IOMMU, it's becoming that
> > > > much harder to use DPDK. Would that be something DPDK is willing to live
> > > > with in the absence of uio interfaces?
> > > >
> > > > Excuse me if I missed something obvious.
> > > > Why a kernel compilation is needed?
> > >
> > > Well, not really full kernel compilation, but in the default configuration, VFIO driver would not support NOIOMMU mode. I.e. it's not compiled by default. Support for no-iommu should be enabled in kernel config and compiled in. So, whoever is going to use DPDK with VFIO-no-iommu will have to download kernel tree and recompile the VFIO module and install it. That's obviously way more hassle than simply compiling an out-of-tree driver that's already included and works with an out-of-the-box kernel.
> >
> > The "out-of-the-box kernel" is configured by your distribution.
> > So we don't know yet what will be their choice.
> > If the distribution supports DPDK, it should be enabled.
>
> I have a question as I am not involved in all possible DPDK
> configurations, platforms, etc. and not yet very involved in vfio. What
> are the devices which do not have IOMMU? If I have, say, DPDK 2.3 with
> vfio-noiommu, which platforms (or computer systems) I am targeting?
>
> Would it be an Intel-based system? Would it be PPC8, ARM?
>
> If it is ARMv7... I would say that the fact I have to explicitly enable
> the no-IOMMU feature and rebuild the kernel (or whatever) is just OK. As
> for such systems, it is common to have a quite customized OS. Well,
> the big distributions are able to run on those devices, that's true...
> However, in such case, the users are usually skilled enough to take
> care of having their own special Linux kernel.
>
> So, is the fact the distributions would not support the no-IOMMU setup
> in their default configuration really an issue? Will some very common
> Intel/DPDK-based box need this?
>
> Regards
> Jan
So far:
* broken hardware (many systems including those from Dell) do not provide
working IOMMU because of Bios bugs etc.
* Linux guest in VMware/KVM/Hyper-V. There is no IOMMU emulation in most
of these systems.
* Older smaller systems (ie Atom) may not have IOMMU
next prev parent reply other threads:[~2015-12-17 23:29 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 16:28 Thomas Monjalon
2015-12-11 22:12 ` Vincent JARDIN
2015-12-11 23:02 ` Alex Williamson
2015-12-15 13:43 ` O'Driscoll, Tim
2015-12-15 16:53 ` Alex Williamson
2015-12-16 4:04 ` Ferruh Yigit
2015-12-16 4:38 ` Alex Williamson
2015-12-16 8:35 ` Burakov, Anatoly
2015-12-16 16:23 ` Burakov, Anatoly
2015-12-16 23:17 ` Thomas Monjalon
2015-12-17 9:52 ` Burakov, Anatoly
2015-12-17 10:09 ` Thomas Monjalon
2015-12-17 19:38 ` Jan Viktorin
2015-12-17 21:16 ` Vincent JARDIN
2015-12-17 23:29 ` Stephen Hemminger [this message]
2015-12-16 17:11 ` Alex Williamson
2015-12-16 17:22 ` Burakov, Anatoly
2015-12-17 16:43 ` Alex Williamson
2015-12-18 10:43 ` Yigit, Ferruh
2015-12-18 14:38 ` Alex Williamson
2015-12-18 21:50 ` Alex Williamson
2015-12-21 11:46 ` Yigit, Ferruh
2015-12-21 12:18 ` [dpdk-dev] [PATCH] vfio: add no-iommu support Ferruh Yigit
2015-12-21 15:15 ` Burakov, Anatoly
2015-12-21 15:26 ` Yigit, Ferruh
2015-12-21 15:28 ` Burakov, Anatoly
2015-12-21 19:22 ` [dpdk-dev] VFIO no-iommu Alex Williamson
2015-12-22 20:20 ` Alex Williamson
2015-12-23 11:19 ` Burakov, Anatoly
2015-12-31 14:30 ` Santosh Shukla
2016-01-14 6:03 ` Jike Song
2016-01-14 6:52 ` Alex Williamson
2016-01-14 8:12 ` Jike Song
2015-12-11 23:20 ` Jan Viktorin
2015-12-15 11:20 ` Alejandro Lucero
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=20151217152909.4c7cbaff@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=viktorin@rehivetech.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).