DPDK patches and discussions
 help / color / mirror / Atom feed
From: Santosh Shukla <sshukla@mvista.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Rizwan Ansari <ransari@mvista.com>
Subject: Re: [dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver
Date: Tue, 8 Dec 2015 18:23:54 +0530	[thread overview]
Message-ID: <CAAyOgsbR81AYyg8Sv3SXx7mNqO=WaCnMn9zO=cd6oMzFdShjWw@mail.gmail.com> (raw)
In-Reply-To: <20151207090833.03f65d63@xeon-e3>

On Mon, Dec 7, 2015 at 10:38 PM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Fri,  4 Dec 2015 23:05:19 +0530
> Santosh Shukla <sshukla@mvista.com> wrote:
>
> >
> > +#ifdef RTE_EXEC_ENV_LINUXAPP
> > +/* start address of first pci_iobar slot (user-space virtual-addres) */
> > +void *ioport_map;
> > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> > +
> > +#include <sys/mman.h>
> > +#define DEV_NAME             "/dev/igb_ioport"
> > +
> > +/* Keeping pci_ioport_size = 4k.
> > + * So maximum mmaped pci_iobar supported =
> > + * (ioport_size/pci_dev->mem_resource[0].len)
> > + *
> > + * note: kernel could allow maximum 32 virtio-net-pci interface, that
> mean
> > + * maximum 32 PCI_IOBAR(s) where each PCI_IOBAR_LEN=0x20, so
> virtio_map_ioport()
> > + * func by theory gonna support 4k/0x20 ==> 128 PCI_IOBAR(s), more than
> > + * max-virtio-net-pci interface.
> > + */
> > +#define PAGE_SIZE            4096
> > +#define PCI_IOPORT_SIZE              PAGE_SIZE
> > +#define PCI_IOPORT_MAX               128 /* 4k / 0x20 */
> > +
> > +int ioport_map_cnt;
> > +#endif /* ARM, ARM64 */
> > +#endif /* RTE_EXEC_ENV_LINUXAPP */
>
> These variables should be static.
>
>
(Sorry for delayed follow, Was travelling..)
Right,


> Also, it is should be possible to extract the I/O bar stuff in a generic
> way through sysfs
> and not depend on a character device. The long term goal for DPDK
> acceptance is to
> eliminate (or at least reduce to a minumum) any requirement for special
> kernel drivers.
>

I agree. Existing implementation does read pci_iobar for start address and
size, But for non-x86 arch, we need someway to map pci_iobar and thats-why
thought of adding device file for a purpose, as archs like arm lack iopl()
privileged io syscall support, However iopl() too quite native driver
design assumption.

I have few idea in my mind such that - Right now I am updating
ioport_mapped addr {kernel-virtual-addr-io-memory} to
/sys/bus/pci/pci_bus_xxxx/xxx/map field, instead of mapping their, I'll try
to map to uio's pci interface and then use existing pci_map_resource() api
to mmap kernel-virtual-io-address to user-space-virtual-ioaddr. We'll come
back on this.

  reply	other threads:[~2015-12-08 12:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 17:35 [dpdk-dev] [PATCH 0/6] Add virtio support in arm/arm64 Santosh Shukla
2015-12-04 17:35 ` [dpdk-dev] [PATCH 1/6] virtio: Introduce config RTE_VIRTIO_INC_VECTOR Santosh Shukla
2015-12-04 17:35 ` [dpdk-dev] [PATCH 2/6] config: i686: set RTE_VIRTIO_INC_VECTOR=n Santosh Shukla
2015-12-04 17:35 ` [dpdk-dev] [PATCH 3/6] virtio: armv7/v8: Introdice api to emulate x86-style of PCI/ISA ioport access Santosh Shukla
2015-12-07 17:09   ` Stephen Hemminger
2015-12-08 15:35     ` Santosh Shukla
2015-12-04 17:35 ` [dpdk-dev] [PATCH 4/6] config: armv7/v8: Enable RTE_LIBRTE_VIRTIO_PMD Santosh Shukla
2015-12-04 17:35 ` [dpdk-dev] [PATCH 5/6] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init() Santosh Shukla
2015-12-09 19:58   ` Jan Viktorin
2015-12-04 17:35 ` [dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver Santosh Shukla
2015-12-07 17:08   ` Stephen Hemminger
2015-12-08 12:53     ` Santosh Shukla [this message]
2015-12-09 18:59       ` Santosh Shukla
2015-12-09 19:04         ` Stephen Hemminger
2015-12-09 19:19           ` Santosh Shukla
2015-12-09 19:57             ` Stephen Hemminger
2015-12-08  9:47   ` Ananyev, Konstantin
2015-12-08 12:55     ` Santosh Shukla
2015-12-07  2:12 ` [dpdk-dev] [PATCH 0/6] Add virtio support in arm/arm64 Yuanhan Liu
2015-12-08 12:59   ` Xie, Huawei
2015-12-10  6:16     ` Santosh Shukla
2015-12-10  6:31       ` Yuanhan Liu

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='CAAyOgsbR81AYyg8Sv3SXx7mNqO=WaCnMn9zO=cd6oMzFdShjWw@mail.gmail.com' \
    --to=sshukla@mvista.com \
    --cc=dev@dpdk.org \
    --cc=ransari@mvista.com \
    --cc=stephen@networkplumber.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).