The problem with scanning, especially in a VNF environment, is that (a) the application probably isn't authorized to to that and (b) the application certainly doesn't have real visibility into what the actual device topology is. It only knows what it "needs to know" (as determined by higher-level functions) so there's no point trying to second-guess that. Applications will be told "use these devices" and that should be our design assumption in this support.
On Fri, Oct 27, 2017 at 10:10 AM, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> wrote: > > > 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 >>> >>> >> >
