DPDK patches and discussions
 help / color / mirror / Atom feed
From: Santosh Shukla <sshukla@mvista.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
Date: Tue, 29 Dec 2015 20:21:48 +0530	[thread overview]
Message-ID: <CAAyOgsZUrdWsCEuescF+CF5TsrhNH5-soQJ9ay_zbKiFu_t9xQ@mail.gmail.com> (raw)
In-Reply-To: <1451397878.18084.4.camel@redhat.com>

On Tue, Dec 29, 2015 at 7:34 PM, Alex Williamson
<alex.williamson@redhat.com> wrote:
> On Tue, 2015-12-29 at 16:17 +0530, Santosh Shukla wrote:
>> On Tue, Dec 29, 2015 at 3:26 PM, Burakov, Anatoly
>> <anatoly.burakov@intel.com> wrote:
>> > Hi Santosh,
>> >
>> > > On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla <sshukla@mvista.c
>> > > om>
>> > > wrote:
>> > > > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu
>> > > > <yuanhan.liu@linux.intel.com> wrote:
>> > > > > On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla
>> > > > > wrote:
>> > > > > > > > I guess we have done enough evaluation / investigation
>> > > > > > > > that
>> > > > > > > > suggest - so to map iopci region to userspace in arch
>> > > > > > > > agnostic-way -
>> > > > > > > >
>> > > > > > > > # either we need to modify kernel
>> > > > > > > >                - Make sure all the non-x86 arch to
>> > > > > > > > support
>> > > > > > > > mapping for iopci region (i.e. pci_mmap_page_range). I
>> > > > > > > > don;t
>> > > > > > > > think its a correct approach though.
>> > > > > > > >             or
>> > > > > > > >                - include /dev/ioport char-mem device
>> > > > > > > > file who
>> > > > > > > > could do more than byte operation, Note that this
>> > > > > > > > implementation
>> > > > > > > > does not exist in kernel.  I could send an RFC to lkml.
>> > > > > > >
>> > > > > > > Maybe you could propose the two to lkml, to get some
>> > > > > > > feedbacks
>> > > > > > > from those kernel/ARM gurus? Please cc me if you do so.
>> > > > > > >
>> > > > > >
>> > > > > > The latter one I already shared old lkml thread, Pl.
>> > > > > > revisit my v1
>> > > > > > 0/6 patch [1] and in that refer [2].
>> > > > >
>> > > > > Oops, sorry, a bit busy, that I didn't look at it carefully.
>> > > > > My bad,
>> > > > > anyway.
>> > > > >
>> > > > > > Josh has already proposed to lkml but for some reason
>> > > > > > thread didn't
>> > > > > > went far. I can restart that discussion giving dpdk use-
>> > > > > > case as an
>> > > > > > example/ requirement.
>> > > > >
>> > > > > I had a quick go through of the discussion. Both hpa and Arnd
>> > > > > seem to
>> > > > > be fine with the ioctl interface on /dev/port. Have you tried
>> > > > > that?
>> > > > > And if you want to restart it, ioctl might be a better option
>> > > > > than
>> > > > > /dev/ioport, judging from the discussion.
>> > > > >
>> > > >
>> > > > I tried legacy patch and re-writing with ioctl-way; doing
>> > > > changes in
>> > > > dpdk port as well in kernel, had to test on quite other hw not
>> > > > only
>> > > > arm64 though! so it will take time for me, I am travelling
>> > > > tomorrow so
>> > > > bit delayed, We'll post patch to lkml and share dpdk-virtio
>> > > > feedback
>> > > > perhaps by Monday.
>> > > >
>> > >
>> > > I posted a query about /dev/ioports approach in lkml thread [1],
>> > > and Arnd
>> > > suggested to use vfio framework but it looks like vfio too does
>> > > not map
>> > > ioresource_io region. Same communicated to Arnd and waiting for
>> > > his reply.
>> > >
>> > > In mean time I like to ask general question;
>> > > - Has anyone tried vfio/non-iommu approach for virtio pmd driver?
>> > > If not
>> > > then Is there any plan? Someone planning to take up.
>> > > [1] https://lkml.org/lkml/2015/12/23/145
>> >
>> > I have submitted a patch to support no-iommu mode, but I'm not
>> > aware of anyone trying VFIO-noiommu at all. That's probably
>> > expected since it's Christmas/New Year in a lot of places, and
>> > everyone is on a break.
>> >
>> > That said, I'm not sure I completely understand what is it that
>> > you're asking about. The code you're referring to (in vfio_pci.c,
>> > line 854 as of kernel 4.3) is checking if a PCI BAR is available
>> > for IO (hence checking if the IORESOURCE_MEM
>>
>>
>> Thanks for reply! You comment might help to move this discuss to next
>> level.
>>
>> Look at kernel/resource.c, it exports two symbol ioport_resource and
>> iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and
>> IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e..
>> _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec)
>> uses pci _io bar region for device initialization as virtio headers
>> are locate at pci _io bar region. Since it uses pci _iobar region so
>> likely it update pci_resource.[index].flag = IORESOURCE_IO.  and vfio
>> mmap function wont handle ioresource_io (i guess). And that is why I
>> asked same to lkml thread.
>>
>>
>> bit is set). There isn't any "ioresource_mem" region as far as VFIO
>> is
>> concerned, there are only BARs, ROM, VGA and PCI
>> config regions (linux/vfio.h, line 314 as of kernel 4.3). So if
>> you're
>> missing some PCI regions for VFIO to map, they would first need to be
>> added to VFIO kernel implementation before they can be used by DPDK.
>> That is, unless I'm misunderstanding something :)
>> >
>>
>> Agree. As mentioned above, I guess ioresource_io pci bar
>> implementation missing in vfio kernel? but before adding code support
>> in kernel I would like to hear from experts example, You, Alex!
>> (looping alex)
>
> MMIO and I/O port space are simply regions as far as VFIO is concerned.
>  The userspace API supports the concept of I/O port regions that can be
> mmap'd by userspace, but the implementation does not since I/O port
> regions cannot be mmap'd on x86.  Someone needs to propose some code
> for vfio-pci to support it.  Thanks,
>

I will work on this and post an RFC soon to LKML, That RFC targetted
to map IOport region for non-x86 platform in particular. Thanks for
confirming the vfio behaviour.

> Alex

  reply	other threads:[~2015-12-29 14:51 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-14 13:00 [dpdk-dev] [ [PATCH v2] 00/13] Add virtio support in arm/arm64 Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 01/13] virtio: Introduce config RTE_VIRTIO_INC_VECTOR Santosh Shukla
2015-12-17 12:02   ` Santosh Shukla
2015-12-17 12:03     ` Thomas Monjalon
2015-12-17 12:18       ` Santosh Shukla
2015-12-17 23:24     ` Stephen Hemminger
2015-12-18  1:31       ` Yuanhan Liu
2015-12-18  9:52       ` Xie, Huawei
2015-12-18 10:41         ` Thomas Monjalon
2015-12-18 17:33         ` Stephen Hemminger
2015-12-18 18:11           ` Thomas Monjalon
2015-12-18 12:46       ` Santosh Shukla
2015-12-22  6:26         ` Yuanhan Liu
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 02/13] config: i686: set RTE_VIRTIO_INC_VECTOR=n Santosh Shukla
2015-12-17 12:03   ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 03/13] rte_io: armv7/v8: Introduce api to emulate x86-style of PCI/ISA ioport access Santosh Shukla
2015-12-14 14:25   ` Jerin Jacob
2015-12-14 16:29     ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 04/13] virtio_pci: use rte_io.h for non-x86 arch Santosh Shukla
2015-12-14 14:28   ` Jerin Jacob
2015-12-14 15:29     ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 05/13] virtio: change io_base datatype from uint32_t to uint64_type Santosh Shukla
2015-12-16 13:48   ` Yuanhan Liu
2015-12-16 14:01     ` Santosh Shukla
2015-12-16 14:23       ` Yuanhan Liu
2015-12-16 14:39         ` Santosh Shukla
2015-12-16 14:58           ` Yuanhan Liu
2015-12-16 15:05             ` Santosh Shukla
2015-12-17  7:19               ` Yuanhan Liu
2015-12-17  8:17                 ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 06/13] config: armv7/v8: Enable RTE_LIBRTE_VIRTIO_PMD Santosh Shukla
2015-12-14 14:31   ` Jerin Jacob
2015-12-14 16:16     ` Santosh Shukla
2015-12-15  5:36   ` Jianbo Liu
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 07/13] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init() Santosh Shukla
2015-12-14 14:34   ` Jan Viktorin
2015-12-14 15:04     ` Santosh Shukla
2015-12-14 14:37   ` Jerin Jacob
2015-12-14 15:24     ` Santosh Shukla
2015-12-14 15:56       ` Jerin Jacob
2015-12-14 16:13         ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 08/13] rte_io: x86: Remove sys/io.h ifdef x86 clutter Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 09/13] igb_uio: ioport: map iopci region for armv7/v8 Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 10/13] include/exec-env: ioport: add rte_virt_ioport header file Santosh Shukla
2015-12-14 14:43   ` Jerin Jacob
2015-12-14 16:17     ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 11/13] virtio_ioport: armv7/v8: mmap virtio iopci bar region Santosh Shukla
2015-12-16 13:29   ` Yuanhan Liu
2015-12-16 14:20     ` Santosh Shukla
2015-12-16 14:37       ` Yuanhan Liu
2015-12-16 14:40         ` Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 12/13] virtio_ethdev: use virtio_ioport api at device init/close Santosh Shukla
2015-12-14 13:00 ` [dpdk-dev] [ [PATCH v2] 13/13] virtio_ethdev : fix format specifier error for 64bit addr case Santosh Shukla
2015-12-14 14:31 ` [dpdk-dev] [ [PATCH v2] 00/13] Add virtio support in arm/arm64 Jan Viktorin
2015-12-14 16:09   ` Santosh Shukla
2015-12-16  7:48 ` Santosh Shukla
2015-12-16  8:47   ` David Marchand
2015-12-16 11:43     ` Santosh Shukla
2015-12-16 12:31       ` [dpdk-dev] [PATCH] eal: map io resources for non x86 architectures David Marchand
2015-12-16 12:48         ` Yuanhan Liu
2015-12-16 13:34           ` David Marchand
2015-12-16 13:42             ` Yuanhan Liu
2015-12-16 13:51           ` Santosh Shukla
2015-12-17  9:38             ` Yuanhan Liu
2015-12-17 10:01               ` Santosh Shukla
2015-12-17 10:02                 ` Santosh Shukla
2015-12-17 10:07                   ` Santosh Shukla
2015-12-17 10:14                     ` Thomas Monjalon
2015-12-17 10:21                       ` Santosh Shukla
2015-12-17 10:33                         ` Thomas Monjalon
2015-12-17 11:22                           ` Santosh Shukla
2015-12-18  5:30                             ` Yuanhan Liu
2015-12-18  6:34                               ` Jerin Jacob
2015-12-18  7:55                                 ` Yuanhan Liu
2015-12-18  9:37                                 ` Thomas Monjalon
2015-12-18  7:54                               ` Santosh Shukla
2015-12-18  8:21                                 ` Yuanhan Liu
2015-12-18 12:55                                   ` Santosh Shukla
2015-12-29  5:56                                     ` Santosh Shukla
2015-12-29  9:56                                       ` Burakov, Anatoly
2015-12-29 10:47                                         ` Santosh Shukla
2015-12-29 11:06                                           ` Burakov, Anatoly
2015-12-29 12:23                                             ` Santosh Shukla
2015-12-29 14:04                                           ` Alex Williamson
2015-12-29 14:51                                             ` Santosh Shukla [this message]
2015-12-31 14:27                                               ` Santosh Shukla
2015-12-16 13:15         ` Bruce Richardson
2015-12-16 13:29           ` David Marchand

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=CAAyOgsZUrdWsCEuescF+CF5TsrhNH5-soQJ9ay_zbKiFu_t9xQ@mail.gmail.com \
    --to=sshukla@mvista.com \
    --cc=alex.williamson@redhat.com \
    --cc=dev@dpdk.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).