Le ven. 27 oct. 2017 à 17:31, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit :
> 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. > If we define multiple devios (devio-mommu, devio-vfio, devio-netmdev) then the DDF is pretty generic and one single driver may adapt to all. Despite I hope we'll have to support only one. 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 > Ill push code snipet to clarify > > > >> 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 >> >> -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 <javascript:void(0);> francois.o...@linaro.org | Skype: ffozog