All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	dev@dpdk.org, Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH] bus/pci: fix vfio mode
Date: Mon, 30 Oct 2017 18:13:50 +0100	[thread overview]
Message-ID: <20171030171349.GI10890@bidouze.vm.6wind.com> (raw)
In-Reply-To: <ce5d50f2-42d7-1a9b-85ee-d7df2604e8b4@intel.com>

On Mon, Oct 30, 2017 at 09:57:08AM -0700, Ferruh Yigit wrote:
> On 10/30/2017 4:24 AM, Thomas Monjalon wrote:
> > 30/10/2017 10:27, Thomas Monjalon:
> >> 30/10/2017 10:17, Gaëtan Rivet:
> >>> Hi Ferruh,
> >>>
> >>> On Mon, Oct 30, 2017 at 02:00:43AM -0700, Ferruh Yigit wrote:
> >>>> On 10/30/2017 1:06 AM, Gaëtan Rivet wrote:
> >>>>> Hi Jerin,
> >>>>>
> >>>>> On Sat, Oct 28, 2017 at 11:50:52AM +0530, Jerin Jacob wrote:
> >>>>>> The definition of VFIO_PRESENT is "eal_vfio.h", Fail to
> >>>>>> include eal_vfio.h will result in disabling vfio.
> >>>>>>
> >>>>>> Fixes: 279b581c897d ("vfio: expose functions")
> >>>>>>
> >>>>>
> >>>>> Thanks for the fix, sorry for VFIO.
> >>>>> I tried to let go of VFIO_PRESENT in the PCI patchset, unfortunately I did
> >>>>> not do a good-enough job.
> >>>>>
> >>>>> Instead of reinstating the dependency on the private eal_vfio.h header,
> >>>>> I'd suggest replacing all VFIO_PRESENT references within the PCI bus by
> >>>>> RTE_EAL_VFIO, and make the pci_vfio.c compilation depend on it within
> >>>>> the linux Makefile. Something like:
> >>>>>
> >>>>> ---8<---
> >>>>>
> >>>>> grep -rl VFIO_PRESENT drivers/bus/pci/linux/ |while read -r file
> >>>>> do sed -i 's;VFIO_PRESENT;RTE_EAL_VFIO;' $file
> >>>>> done
> >>>>
> >>>> VFIO_PRESENT is the combination of the if user enabled VFIO and if Linux kernel
> >>>> supports it.
> >>>>
> >>>> Why not add same check and VFIO_PRESENT definition to rte_vfio.h:
> >>>>
> >>>>   --- a/lib/librte_eal/common/include/rte_vfio.h
> >>>>   +++ b/lib/librte_eal/common/include/rte_vfio.h
> >>>>   @@ -34,7 +34,13 @@
> >>>>    #ifndef _RTE_VFIO_H_
> >>>>    #define _RTE_VFIO_H_
> >>>>
> >>>>   +#if !defined(VFIO_PRESENT) && defined(RTE_EAL_VFIO)
> >>>>   +#include <linux/version.h>
> >>>>   +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 6, 0)
> >>>>    #include <linux/vfio.h>
> >>>>   +#define VFIO_PRESENT
> >>>>   +#endif /* >= 3.6.0 */
> >>>>   +#endif
> >>>>   +
> >>>>   +#ifdef VFIO_PRESENT
> >>>>
> >>>>   ... Need to wrap here in case VFIO disabled ...
> >>>>
> >>>>   #endif
> >>>>
> >>>
> >>> It would work indeed.
> >>>
> >>> I mostly dislike having whole compilation units disabled silently on a
> >>> linux version check. I think that if someone wanted to support kernels <
> >>> 3.6, they ought to do the work of disabling RTE_EAL_VFIO.
> >>>
> >>> A build error could be thrown to help those users toward the right
> >>> solution, but I think that the meaning of having this option enabled
> >>> should be enforced: if it is enabled, it is compiled. If dependencies
> >>> are not met, then the option should be disabled.
> >>
> >> +1 to avoid implicit disabling.
> > 
> > To make it clear, we can disable VFIO automatically if not supported by
> > the kernel at compilation time, but there should be a warning.
> 
> Gaetan suggest letting build error and push user to disable the feature. If we
> let the build error, I think feature should be disabled by default.
> 
> And for VFIO, instead of disabling it by default I am for auto disable it if
> kernel requirement not met, and +1 for adding a warning.
> 
> btw, that kernel version check is already in eal_vfio.h, we are already
> disabling some vfio code based on kernel version check, weather add here or not.
> 
> Thanks,
> ferruh

The new version of the patches should behave like you described :) .

I still think VFIO_PRESENT should be changed, but not now.

-- 
Gaëtan Rivet
6WIND

  reply	other threads:[~2017-10-30 17:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-28  6:20 [PATCH] bus/pci: fix vfio mode Jerin Jacob
2017-10-30  8:06 ` Gaëtan Rivet
2017-10-30  9:00   ` Ferruh Yigit
2017-10-30  9:17     ` Gaëtan Rivet
2017-10-30  9:27       ` Thomas Monjalon
2017-10-30 11:24         ` Thomas Monjalon
2017-10-30 16:57           ` Ferruh Yigit
2017-10-30 17:13             ` Gaëtan Rivet [this message]
2017-10-30  9:10   ` Jerin Jacob
2017-10-30 12:55 ` [PATCH v2 1/2] " Gaetan Rivet
2017-10-30 12:55   ` [PATCH v2 2/2] eal: warn user that VFIO is disabled Gaetan Rivet
2017-10-30 16:36   ` [PATCH v3 1/2] bus/pci: fix vfio mode Gaetan Rivet
2017-10-30 16:36     ` [PATCH v3 2/2] eal: warn user that VFIO is disabled Gaetan Rivet
2017-10-30 17:31       ` Ferruh Yigit
2017-10-30 17:26     ` [PATCH v3 1/2] bus/pci: fix vfio mode Ferruh Yigit
2017-10-30 19:07       ` Ferruh Yigit
2017-10-30 22:32     ` [PATCH v4] " Ferruh Yigit
2017-10-31 12:03       ` Bruce Richardson
2017-10-31 16:58         ` Ferruh Yigit
2017-10-31 18:21         ` Thomas Monjalon
2017-10-31 14:11       ` Gaëtan Rivet

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=20171030171349.GI10890@bidouze.vm.6wind.com \
    --to=gaetan.rivet@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.