On 27 October 2017 at 09:50, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> ODP 2.0 assumes Linux system services are available so the question of how > to operate in bare metal environments is a separate one and up to those ODP > implementations. Again the application will provide a > sufficiently-qualified device name string to identify which device it wants > to open in an unambiguous manner. How it does that is again outside the > scope of ODP so this isn't something we need to worry about. All ODP needs > to do is be able to identify which driver needs to be loaded and passed the > rest of the device name and then that driver handles the rest. > > By baremetal, I meant host with Linux OS. I agree, it is applications responsibility to provide the device string, how it does that is outside the scope of ODP. We will continue the discussion on the slides. But, in the meanwhile, I am thinking of possible design if we want to avoid complete scanning of the platform during initialization. In the current packet I/O framework, all the function pointers of the driver are known before odp_pktio_open API is called. If we have to stick to this design, the drivers for the PCI device should have registered their functions with the packet IO framework before odp_pktio_open is called. > On Fri, Oct 27, 2017 at 2:36 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Well, we do not need to scan all the platform because the pktio_open >> contains enough information to target the right device. >> This is almost true as we need to have an additional "selector" for the >> port on multiport NICs that are controlled by a single pci ID. >> <enumerator>:<enumerator specific string>:<port> or something like that. >> >> All ports may not be typically handled by ODP. For instance management >> network will most certainly be a native Linux one. >> >> Dpaa2 bus may impose us to full scan if we have to go the full driver >> route (vfio-pci) but this will not be necessary if we can have the >> net-mdev. In that case, the dpaa2 bus can be handled the same way as pci. >> >> Dynamic bus events (hot plug) are a nice to have and may be dropped from >> coding yet we can talk about it. and when it come to this, this is not >> about dealing with the bus controllers directly but tapping into Linux >> event framework. >> >> I know we can simplify things and I am very flexible in what we can >> decide not to do. That said I have been dealing with operational issues on >> that very topic since 2006 when I designed my first kernel based fast >> packet IO.... So there will be topics where I'll push hard to explain (not >> impose) why we should go a harder route. This slows things down but I think >> this is worth it. >> >> FF >> >> Le ven. 27 oct. 2017 à 06:23, Honnappa Nagarahalli < >> honnappa.nagaraha...@linaro.org> a écrit : >> >>> On 26 October 2017 at 16:34, Bill Fischofer <bill.fischo...@linaro.org> >>> wrote: >>> > I agree with Maxim. Best to get one or two working drivers and see >>> what else >>> > is needed. The intent here is not for ODP to become another OS, so I'm >>> not >>> > sure why we need to concern ourselves with bus walking and similar >>> arcana. >>> > Linux has already long solved this problem. We should leverage what's >>> there, >>> > not try to reinvent it. >>> > >>> > ODP applications are told what I/O interfaces to use, either through an >>> > application configuration file, command line, or other means outside >>> the >>> > scope of ODP itself. ODP's job is simply to connect applications to >>> these >>> > configured I/O interfaces when they call odp_pktio_open(). The name >>> used for >>> > interfaces is simply a string that we've defined to have the format: >>> > >>> > class: device: other-info-needed-by-driver >>> > >>> > We've defined a number of classes already: >>> > >>> > - loop >>> > - pcap >>> > - ipc >>> > - dpdk >>> > - socket >>> > - socket_mmap >>> > - tap >>> > etc. >>> > >>> > We simply need to define new classes (e.g., ddf, mdev) and the names >>> they >>> > need to take to identify a specific device and the associated driver >>> to use >>> > for operate that device. The driver is then loaded if necessary and its >>> > open() interface is called. >>> > >>> >>> Coincidentally, internally we were discussing this exactly. >>> >>> Why do we need to scan and understand the complete platform during >>> initialization? - I would think, mostly, ODP will run in a platform >>> (baremetal, VM, container) where all the devices are supposed to be >>> used by ODP (i.e. ODP will not run in a platform where it will share >>> the platform with other applications). So why not scan and identify >>> the devices/drivers and create the packet IO ops during >>> initialization. The packet I/O framework assumes that various methods >>> (open, close, send, recv etc) of the device driver are known when >>> odp_pktio_open API is called. None of that has to change. >>> >>> Another solution I can think of is (tweak to reduce the time spent in >>> scanning etc), instead of scanning all the devices, DDF initialization >>> function can be provided with all the ports the user has requested. >>> >>> If the scanning for the device and identifying the driver has to be >>> triggered through the odp_pktio_open API, the current packet IO >>> framework needs to change. >>> >>> > On Thu, Oct 26, 2017 at 3:59 PM, Maxim Uvarov <maxim.uva...@linaro.org >>> > >>> > wrote: >>> >> >>> >> Hello Honnappa, >>> >> >>> >> I think we also need to take a look from bottom. I.e. from exact >>> drivers >>> >> to >>> >> implement. That it will be more clear which interface is needed to be >>> >> created. >>> >> Do you have some list of drivers which needed to be implemented? I.e. >>> with >>> >> pci drivers I think we in a good way, but non pci drivers are under >>> >> question. >>> >> I think we should not over-complicate odp itself with huge discovery >>> and >>> >> numeration of devices. Let's take a look what is the minimal >>> interface to >>> >> support >>> >> devices. >>> >> >>> >> Best regards, >>> >> Maxim. >>> >> >>> >> On 26 October 2017 at 23:35, Honnappa Nagarahalli < >>> >> honnappa.nagaraha...@linaro.org> wrote: >>> >> >>> >> > Hi, >>> >> > Agree, we have taken 2 hours and the progress has been slow. But >>> >> > the discussions have been good and helpful to us at Arm. The goal is >>> >> > to identify the gaps and work items. I am not sure if it has been >>> >> > helpful to others, please let me know. >>> >> > >>> >> > To speed this up, I propose few options below, let me know your >>> opinion: >>> >> > >>> >> > 1) Have 2 additional (along with regular ODP 2.0) calls next week - >>> We >>> >> > can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, >>> TX >>> >> > time, GMT-6, one hour before the regular ODP-2.0) >>> >> > >>> >> > 2) Resolve the pending PRs on emails >>> >> > >>> >> > 3) Discuss the DDF slides on email - Not sure how effective it will >>> be >>> >> > >>> >> > Any other solutions? >>> >> > >>> >> > Thank you, >>> >> > Honnappa >>> >> > >>> > >>> > >>> >> -- >> [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 >> >> >
