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