[dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver

Santosh Shukla sshukla at mvista.com
Tue Dec 8 13:53:54 CET 2015


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

> On Fri,  4 Dec 2015 23:05:19 +0530
> Santosh Shukla <sshukla at 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.


More information about the dev mailing list