To deal with drivers we need to have additional "standard" (helper or API?) objects to deal with MAC addresses.
ODP could be made to handle SDH, SDLC, FrameRelay or ATM packets. A packet_io is pretty generic... But as soon as we talk with drivers and initialization, we need to deal with L1 initialization (link up/ synchronized...) and L2 initialization (DLCI, MAC (Ethernet, FDDI, TokenRing...)...). Shall we add those L1 and L3 concepts ? FF On 9 November 2016 at 09:38, Francois Ozog <francois.o...@linaro.org> wrote: > > > 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 > > -- [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
