On 8 November 2016 at 18:19, Francois Ozog <francois.o...@linaro.org> wrote:
> Hi Christophe,
>
> We are focusing on network devices which have at least network ports.
> Inventory of devices and ports are two distinct topics as there is no
> guarantee that there is one device per port. (Intel and Mellanox have this
> policy: one device per PCI port, but many others have one PCI device for
> multiple ports (Chelsio...)
>
> 1) device discovery
>
> So let's focus first on device discovery.
>
> Devices can be found from:
> - static "configuration" based on ODP implementation
> - ACPI
> - PCI
> - DPAA2 NXP bus
> - VMBus (VMs running on Microsoft Hyper-V hypervisor)
> - others ?
>
> So bus are somewhat limited (ACPI is NOT a bus). I prefer to talk about
> device enumerators.
>
OK.
>
> so we can loop through all devices using your proposed:
> for each <device enumerator>
> for each probed device
>
Not sure what a "probed device" is here, I what thinking:
for each <device enumerator>
for each driver
driver.probe(device)
Is that what you meant?
>
> But that is only for static discovery at the program startup.
>
yes
>
> It would be way better to allow hotplugs (card insertion in a chassis,
> addition of one virtual interfrace in aa VM because of a scale up
> operation).
>
yes: we can probe new hotplugged devices (again registered drivers) when a
new device is hot plugged and and probe registered (unassigned) device
again any hot plugged driver.
>
> So in addition to initial synchronous probing we need asynchronous events
> handling.
>
yes
>
> Once we have found the device, we need to check if we have a driver for it
> and if the "user" has decided if he wants to use that device (configuration
> aspects)
>
I guess the fact that a user loads a driver is an act of configuration...?
>
> 2) driver assignment
> From this device we may want to enumerate ports and other "things" (like
> embeded switch) that are present on the device.
>
hmmm... so a device driver could act as a new enumerator? I am not fully
following your proposal here... Let's say 2 PCI board contains (each) its
switch (one switch per board). The PCI enumerator will detect 2 devices. So
according to your proposal, we would also have switch enumerators? How many
such switch enumerator do we have? Where is it located?
> Accessing devices is bus dependent, os dependent and processor dependent.
> A few problems to tackle:
> - On Linux, a device can be accessed through uio, vfio or through a direct
> library (cf bifurcated drivers)
>
yes. So a device enumerator will give many interface to play with the
devices it enumerates. In my first example, I called BUS what you call
enumerator and DRIVER_TYPE was the key to select the device interface (like
PCI_VFIO wouild select the vfio interface). If we keep with the enumerator
view (that I like), shall each enumerator give a choice of
"device-interface" for each of its device? I.E:
my BUS = your enumerator (OK)
my DRIVER_TYPE = device_interface?
> - if uio, it also depends on the processor architecture (Intel has a
> special way of exposing uio, PPC64 and ARM64 are different)
>
Haven't digged into uio yet ...
> - if bifurcated driver, the "odp/dpdk driver" SHOULD not deal directly
> with the PCI device but rather with the device specific library
>
"odp/dpdk driver"...Are you planning for a new driver structure for dpdk
too, which we would share ?
Not sure I understand what you meant there. I though bifurcated drivers
where just drivers getting their data from userland application but
controled by kernel tools. I guess my view is not complete here.
> 3) created objects in ODP
> odp_pktio_t is somewhat corresponding to a port "driver". it does properly
> adapts to a device with multiple ports.
>
Not sure of the match when you started talking about the embeded switches...
Christophe.
>
> FF
>
>
>
>
>
> On 7 November 2016 at 17:49, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>> Bonsoir Francois,
>>
>> I'll take that in English thereafter so that other can read (copy to the
>> list).
>>
>> I have looked at that:
>>
>> https://dpdksummit.com/Archive/pdf/2016Userspace/Day02-
>> Session03-ShreyanshJain-Userspace2016.pdf
>>
>> I guess that is what you referred to, Francois, when talking at the
>> SYNC meeting earlier today. I missed a lot of was you said, though, my
>> BJ being extremely uncooperative today.
>>
>> I have not seen the presentation, but my understanding is that PCI
>> drivers would "require" PCI bus drivers. As SocX driver could require
>> Soc bus scan.
>> I have to admit that I did not follow 100% the DPDK proposal, but
>> this approach to have a "BUS driver" is not very clear to me, when it
>> comes to ODP:
>>
>> 1)Because SoC constructors will probably accelerate more than the
>> interface. If those constructors have, for instance, different
>> odp-packet implementation (matching their HW), they will likely have
>> their own ODP implementation anyway, so making the bus enumerator a
>> driver will not help them.
>>
>> 2)Bus enumeration and ressource mapping would likely require quite a
>> lot of assumptions regarding the OS/platform the BUS driver runs on
>> (such as the persence of the /sys fs on linux).
>> That would make the driver OS/Platform dependent: not a big deal for
>> DPDK (which is mainly targetting linux/X86), but maybe more a problem
>> for ODP...
>>
>> I have to admit that having driver dependencies (a bit like package
>> systems like apt-get/rpm have) would have benefits as well, but not
>> sure that it would be best for us. Isn't the goal of ODP being mostly
>> an API to enable completely different implementations? Is there a
>> point trying to go for more than standart busses in the linux generic
>> implementation then?
>>
>> By the way: How does the NXP board interface the machine? Not sure I
>> understand their case...
>>
>>
>> My intension was to do Bus enumeration in ODP, and provide driver
>> registration in ODP as well. So eventually, ODP would build a list of
>> devices for each bus and a list of registered drivers.
>>
>> Then ODP would do something like:
>> for each bus
>> for each device of this bus
>> for each driver
>> if driver.bus == bus, then call driver.probe(device),
>> if probe() returns true (the driver can handle the
>> device), then break;
>>
>> Basically saying that the first driver whose probe() fnct returns true
>> is good to go.
>>
>> This is a simpler model (and It would be limited to PCI busses to
>> start with), but it hopefully would enable drivers to be OS/platform
>> agnostic: If, PCI for instance, is handled differentely on different
>> ODP implementation, the board driver would not have to care as long as
>> the ODPDRV-pci interface remains the same.
>>
>> Any other voices?
>>
>> Those who want to TALK to me are VERY welcomed to HO me! :-)
>>
>> Thks for reading :-)
>>
>> Christophe.
>>
>
>
>
> --
> [image: Linaro] <http://www.linaro.org/>
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
>
