On Fri, Oct 6, 2017 at 4:03 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> > > On 6 October 2017 at 22:26, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > >> PR #225 [1] is a good example of the sort of packaging/distro problem ODP >> wants to solve. DPDK currently requires special compile flags to determine >> the microarchitecture it's running on. As a result, Travis broke when they >> deployed new test machines that had a different microarchitecture. To get >> around this we need to compile DPDK to disable any such optimizations so >> it >> uses its least-common-denominator code. That's exactly what we don't want >> in ODP. >> >> > even more than that dpdk will not compile at all without SSE instructions. > Minimum cpu > level is core2 (-march=core2). They even do not have "generic" platform > (code without -march will not compile). > So it's why hack to make it work on any hardware. It will be great feature > that you can run application > without thinking to configure it to specific cpu, i.e. not care if it's > Ivybridge, Sandybridge, > some other x86_64 and etc. > Sounds like an opportunity for differentiation even on x86. If ODP apps can be compiled on any generic x86 and run optimally on a target x86 without recompilation/relinking that would seem to be an improvement over what DPDK currently offers in this area. Since DPDK will have this same issue in the NFV space I can only assume they're working on this problem as well, so perhaps another opportunity area for joint collaboration. > > Maxim. > > > >> So ODP needs to determine this at run time and adapt accordingly, as >> François mentions. >> >> --- >> [1] https://github.com/Linaro/odp/pull/225 >> >> On Fri, Oct 6, 2017 at 12:42 PM, Francois Ozog <francois.o...@linaro.org> >> wrote: >> >> > Hi Petri, >> > >> > DPDK modules are not allowing DPDK to adapt to underlying architecture. >> It >> > is just pugable HW. >> > The DDF will deal with that. >> > >> > The problem we need to solve is architecture adaptation. where the CORE >> of >> > the application changes. there is a single DPDK core with drivers. ODP >> has >> > different CORES (one for each SoC implementation) and several plugable >> > driver through DDF. >> > >> > So the DPDK model is not comparable. >> > >> > The Xorg model is closer but still Xorg CORE does not change based on >> the >> > GPU/FrameBuffer plugins. >> > >> > ANd last, but not least, all those things are INSTALL time stuff. Which >> we >> > care for NEPs as I mentioned in the use cases, but is not enough to deal >> > with arbitrary INSTANTIATION. >> > >> > Cordially, >> > >> > FF >> > >> > On 6 October 2017 at 15:36, Savolainen, Petri (Nokia - FI/Espoo) < >> > petri.savolai...@nokia.com> wrote: >> > >> > > > > No, I'm pointing that the more there's common core SW, the more >> there >> > > > > are trade-offs and the less direct HW access == less performance. >> > For >> > > > > optimal performance, the amount of common core SW is zero. >> > > > >> > > > Yes this is sort of the ideal but I doubt this type of installation >> > > > will be accepted by e.g. Red Hat for inclusion in server-oriented >> > > > Linux distributions. Jon Masters seems to be strongly against this >> > > > (although I have only heard this second hand). So that's why I >> > > > proposed the common (generic) core + platform specific drivers model >> > > > that is used by e.g. Xorg and DPDK. Since DPDK is actually a user >> > > > space framework (unlike Xorg), this should be a good model for ODP >> and >> > > > something that Red Hat cannot object against. >> > > > >> > > >> > > If every line of code is maintained properly, why a distro would care >> > > about the ratio between common core SW and HW specific driver SW? >> > > >> > > If they care, what is an acceptable ratio? Is it 90% common SW : 10% >> HW >> > > specific SW, 80:20, 50:50, 10:90 and why not 0:100? How this ratio >> should >> > > be calculated? >> > > >> > > DPDK is in Ubuntu already. Have anyone calculated what this ratio is >> for >> > > it? >> > > >> > > I'd be interested to see ODP as part of any distro first, and only >> after >> > > that speculate what other distros may or may not say. E.g. Ubuntu >> seem to >> > > accept packages that are only for single arch, e.g.: >> > > librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386] <<< Intel >> Red >> > > Rock Canyon net driver, provided only for x86 >> > > >> > > -Petri >> > > >> > > >> > > >> > >> > >> > -- >> > [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 >> > >> > >
