All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Santosh Shukla <sshukla@mvista.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	dev@dpdk.org, Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode
Date: Tue, 26 Jan 2016 15:28:34 +0100	[thread overview]
Message-ID: <2443301.RnaAh4IIhO@xps13> (raw)
In-Reply-To: <CAAyOgsbunjZX=NqM_i+Q3+RMKO7x38WpExZ0SC-34-o2W+17ug@mail.gmail.com>

2016-01-26 19:35, Santosh Shukla:
> On Tue, Jan 26, 2016 at 6:30 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> > 2016-01-26 15:56, Santosh Shukla:
> >> In my observation, currently virtio work for vfio-noiommu, that's why
> >> said drv->kdrv need to know vfio mode.
> >
> > It is your observation. It may change in near future.
> 
> so that mean till then, virtio support for non-x86 arch has to wait?

No, absolutely not. virtio for non-x86 is welcome.

> We have working model with vfio-noiommu, don't you think it make sense
> to let vfio_noiommu implementation exist and later in-case
> virtio+iommu gets mainline then switch to vfio __mode__ agnostic
> approach. And for that All it takes to replace __noiommu suffix with
> default.

I'm just saying you should not touch the enum rte_kernel_driver.
RTE_KDRV_VFIO is a driver.
RTE_KDRV_VFIO_NOIOMMU is a mode.
As the VFIO API is the same in both modes, there is no reason to
distinguish them at this level.
Your patch adds the NOIOMMU case everywhere:
        case RTE_KDRV_VFIO:
+       case RTE_KDRV_VFIO_NOIOMMU:

I'll stop commenting here to let others give their opinion.

[...]
> >> with vfio+iommu; binding virtio pci device to vfio-pci driver fail;
> >> giving below error:
> >> [   53.053464] VFIO - User Level meta-driver version: 0.3
> >> [   73.077805] vfio-pci: probe of 0000:00:03.0 failed with error -22
> >> [   73.077852] vfio-pci: probe of 0000:00:03.0 failed with error -22
> >>
> >> vfio_pci_probe() --> vfio_iommu_group_get() --> iommu_group_get()
> >> fails: iommu doesn't have group for virtio pci device.
> >
> > Yes it fails when binding.
> > So the later check in the virtio PMD is useless.
> 
> Which check?

The check for VFIO noiommu only:
-       if (dev->kdrv == RTE_KDRV_VFIO)
+       if (dev->kdrv == RTE_KDRV_VFIO_NOIOMMU)

[...]
> > Furthermore restricting virtio to no-iommu mode doesn't bring
> > any improvement.
> 
> We're not __restricting__, as soon as virtio+iommu gets working state,
> we'll simply replace __noiommu with default. Then its upto user to try
> out virtio with vfio default or vfio_noiommu.

Yes it's up to user.
So your code should be
	if (dev->kdrv == RTE_KDRV_VFIO)

> > That's why I suggest to keep the initial semantic of kdrv and
> > not pollute it with VFIO modes.
> 
> I am okay to live with default and forget suffix __noiommu but there
> are implementation problem which was discussed in other thread
> - Virtio pmd driver should avoid interface parsing i.e.
> virtio_resource_init_uio/vfio() etc.. For vfio case - We could easily
> get rid of by moving /sys parsing to pci_eal layer, Right? If so then
> virtio currently works with vfio-noiommu, it make sense to me that
> pci_eal layer does parsing for pmd driver before that pmd driver get
> initialized.

Please reword. What is the problem?

> - Another case could be: iommu-less-pmd-driver. eal layer to do
> parsing before updating drv->kdrv.

[...]
> >> >> > If a check is needed, I would prefer using your function
> >> >> > pci_vfio_is_noiommu() and remove driver modes from struct rte_kernel_driver.
> >> >>
> >> >> I don't think calling pci_vfio_no_iommu() inside
> >> >> virtio_reg_rd/wr_1/2/3() would be a good idea.
> >> >
> >> > Why? The value may be cached in the priv properties.
> >> >
> >> pci_vfio_is_noiommu() parses /sys for
> >> - enable_noiommu param
> >> - attached driver name is vfio-noiommu or not.
> >>
> >> It does file operation for that, I meant to say that calling this api
> >> within register_rd/wr function is not correct. It would be better if
> >> those low level register_rd/wr api only checks driver_types.
> >
> > Yes, that's why I said the return of pci_vfio_is_noiommu() may be cached
> > to keep efficiency.
> 
> I am not convinced though, Still find pmd driver checking driver_types
> using drv->kdrv is better approach than introducing a new global
> variable which may look something like;

Not a global variable. A function in EAL layer. A variable in PMD priv.

> At pci_eal layer ----
> bool vfio_mode;
> vfio_mode = pci_vfio_is_noiommu();
> 
> At virtio pmd driver layer ----
> Checking value at vfio_mode variable before doing virtio_rd/wr for
> vfio interface.
> 
> Instead virtio pmd driver doing
> 
> virtio_reg_rd/wr_1/2/4()
> {
> if (drv->kdrv == VFIO)
>       do pread()/pwrite()
> else
>       in()/out()
> }
> 
> is better approach.
> 
> Let me know if you still think former is better than latter then I'll
> send patch revision right-away.

  reply	other threads:[~2016-01-26 14:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 18:57 [PATCH v6 08/11] eal: pci: introduce RTE_KDRV_VFIO_NOIOMMUi driver mode Santosh Shukla
2016-01-21 10:32 ` David Marchand
2016-01-21 11:13   ` Santosh Shukla
2016-01-21 11:28     ` Thomas Monjalon
2016-01-21 12:04       ` Santosh Shukla
2016-01-21 14:46         ` Thomas Monjalon
2016-01-21 17:17           ` Santosh Shukla
2016-01-25 15:29             ` Thomas Monjalon
2016-01-26 10:26               ` Santosh Shukla
2016-01-26 13:00                 ` Thomas Monjalon
2016-01-26 14:05                   ` Santosh Shukla
2016-01-26 14:28                     ` Thomas Monjalon [this message]
2016-01-26 16:21                       ` Santosh Shukla
2016-01-27 10:41                         ` Santosh Shukla
2016-01-27 15:32                           ` Santosh Shukla
2016-01-27 15:39                             ` Thomas Monjalon
2016-01-27 15:56                               ` Santosh Shukla
2016-01-27 17:18                                 ` Santosh Shukla

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=2443301.RnaAh4IIhO@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=alex.williamson@redhat.com \
    --cc=dev@dpdk.org \
    --cc=mst@redhat.com \
    --cc=sshukla@mvista.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 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.