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. 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 > > >
