Le ven. 27 oct. 2017 à 17:00, Maxim Uvarov <maxim.uva...@linaro.org> a
écrit :
> On 10/27/17 17:56, Honnappa Nagarahalli wrote:
> > We have to support both types of drivers as of now:
> >
> > 1) Legacy all user space drivers - In this case, what Jianbo says is
> correct.
> > 2) net-mdev drivers.
> >
> > So, DDF has to support both the use cases.
> >
> > Thank you,
> > Honnappa
> >
>
> Generic net-mdev kernel module will help here. I.e. if there is no
> kernel driver but you need create mdev from pci device (i.e. map it
> to user space) then you can link pci number with that driver which will
> get netmdev and create dummy net device for it.
>
In that case this can be only a VFIO-pci "all userspace" driver . If no
kernel driver you can't use netmdev (by definition: only a driver for a
device can expose a netmdev interface )
> Maxim.
>
> >
> > On 27 October 2017 at 04:47, Francois Ozog <francois.o...@linaro.org>
> wrote:
> >> In the case of netmdev the device is still there. Please check with
> Ilias
> >> for detailed behavior of this technology
> >>
> >> FF
> >>
> >> Le ven. 27 oct. 2017 à 10:29, Jianbo Liu <jianbo....@arm.com> a écrit :
> >>
> >>> The 10/27/2017 10:25, Maxim Uvarov wrote:
> >>>> yes, discovery is done by other tools like lspci, /proc and /sys
> >>>> interfaces. Also udev rules are there to make naming persistent.
> >>>>
> >>>> For pci it can be:
> >>>>
> >>>> odp_pktio_open("mdev:eth0")
> >>>>
> >>>> then you parse /proc/bus/pci/devices to find actual driver used for
> this
> >>>> eth0. And if you have matching mdev pktio driver - open it.
> >>>
> >>> There is no eth0 because the device is bound to vfio or uio driver.
> >>>
> >>>> That looks like very simply and clear.
> >>>>
> >>>> Maxim.
> >>>>
> >>>>
> >>>> On 27 October 2017 at 01:03, Bill Fischofer <
> bill.fischo...@linaro.org>
> >>>> wrote:
> >>>>
> >>>>> I think you've captured the distinction correctly. The larger
> question
> >>> is
> >>>>> what does ODP itself need to do with this? When an interface name is
> >>>>> presented to odp_pktio_open() it is the application's responsibility
> to
> >>>>> provide a name string that can be mapped to the device that should be
> >>>>> opened. ODP uses that string to locate / load the driver that's
> needed
> >>> to
> >>>>> operate that device. The driver is then responsible to make the
> actual
> >>>>> connection to the device.
> >>>>>
> >>>>> When a driver gets a "device string" is needs to translate that into
> >>> either
> >>>>> an appropriate Linux system call (for mdev) or to a set of PCI Bar or
> >>> other
> >>>>> HW register addresses (for dedicated I/O). So if there is a case of a
> >>>>> southbound ODP API, it would be to assist with this latter
> translation.
> >>>>>
> >>>>> On Thu, Oct 26, 2017 at 12:38 PM, Honnappa Nagarahalli <
> >>>>> honnappa.nagaraha...@linaro.org> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>> I created a document to convert our discussion into pictures. I
> >>>>>> will update this as we discuss other concepts like devio/driver etc.
> >>>>>>
> >>>>>> https://docs.google.com/a/linaro.org/document/d/1nzy-Qp6hYZU38DVi7_
> >>>>>> ZnPiaf3jRqdMN6IQHmfO80Al4/edit?usp=sharing
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Honnappa
> >>>>>>
> >>>>>
> >>>
> >>> --
> >>> IMPORTANT NOTICE: The contents of this email and any attachments are
> >>> confidential and may also be privileged. If you are not the intended
> >>> recipient, please notify the sender immediately and do not disclose the
> >>> contents to any other person, use it for any purpose, or store or copy
> the
> >>> information in any medium. Thank you.
> >>>
> >> --
> >> [image: Linaro] <http://www.linaro.org/>
> >> François-Frédéric Ozog | *Director Linaro Networking Group*
> >> T: +33.67221.6485 <javascript:void(0);>
> >> francois.o...@linaro.org | Skype: ffozog
>
> --
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485 <javascript:void(0);>
francois.o...@linaro.org | Skype: ffozog
