On 9 November 2016 at 09:09, Christophe Milard <christophe.mil...@linaro.org
> wrote:
>
>
> 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?
>
>
>> [FF] no:
for each <device enumerator>
> for each enumerated device
> for each registered driver
>
driver.probe(device)
>
>> 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...?
> [FF] I guess not, load all drivers
>
>>
>> 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?
> [FF]: lets make a simpler example: 2 PCI devices, each with four 10Gbps
> ethernet ports. there are two enumerated PCI devices but there are 8
> packet_ios. packet ios should conserve a link to a device, the device
> should have a link back to the enumerator. no upperlayer metadata saved in
> each "object", just a link.
>
>>
>> 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?
> [FF] not sure I understand
>
> - 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.
> [FF] when you bind a driver to uio, the netdev disappears. When using
> bifurcated drivers it does not.
>
>>
>> 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...
>
[FF] I keep hw discovery/inventory/representation (hierarchy of connected
elements) separate from the functional aspects (drivers, ports,
controllable hw blocks such as classifier, scheduler...). .I guess we can
represent the switch as if it was a classifier+scheduler+tm. I haven't
thought too much about that
>
> 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-Sessi
>>> on03-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
>>
>>
>
--
[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
