On 27 October 2017 at 02:36, 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. > > I think, it clear that this string format is good. It has all the information that is needed. I propose we change the <port> to <device/driver specific string>: <enumerator>:<enumerator specific string>:<device/driver specific string> <port ID> would be part of such 'device/driver specific string' and will be interpreted by the driver. 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. > I too think it is worth it. Even though the progress is slow we have not stalled. We are discussing and understanding. At the end of this discussion, we would have the following information: 1) How does the final solution looks like (addressing both all-user-space drivers and net-mdev drivers)? May not be 100% clear, at least we will have few options. 2) Most critical/minimal code required to get the packets into the user space. This is what we will do in the next few weeks/month. 3) 'some what' of a plan for the rest of the code > 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 > >
