Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

On Fri, Oct 6, 2017 at 4:03 PM, Maxim Uvarov 
wrote:

>
>
> On 6 October 2017 at 22:26, Bill Fischofer 
> 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 
>> 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] 
>> > François-Frédéric Ozog | *Director Linaro Networking Group*
>> > T: +33.67221.6485
>> > francois.o...@linaro.org | Skype: ffozog
>> >
>>
>
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

On 6 October 2017 at 22:26, Bill Fischofer 
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 
> 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] 
> > François-Frédéric Ozog | *Director Linaro Networking Group*
> > T: +33.67221.6485
> > francois.o...@linaro.org | Skype: ffozog
> >
>

Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

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.

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 
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] 
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

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] 
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

Re: [lng-odp] generic core + HW specific drivers

[Ilias Apalodimas]

We'll only got for rpm? deb packaging?

Regards
Ilias

On 6 October 2017 at 20:18, Maxim Uvarov  wrote:

> http://pkgs.fedoraproject.org/cgit/rpms/dpdk.git/tree/dpdk.spec
>
> On 6 October 2017 at 20:17, Maxim Uvarov  wrote:
>
> >
> >
> > On 6 October 2017 at 20:05, Honnappa Nagarahalli <
> > honnappa.nagaraha...@linaro.org> wrote:
> >
> >> Any experts on how is the packaging done for DPDK?
> >>
> >>
> > ./pkg/dpdk.spec  ?
> >
> >
> >> On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
> >>  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
> >> >
> >> >
> >>
> >
> >
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

http://pkgs.fedoraproject.org/cgit/rpms/dpdk.git/tree/dpdk.spec

On 6 October 2017 at 20:17, Maxim Uvarov  wrote:

>
>
> On 6 October 2017 at 20:05, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> wrote:
>
>> Any experts on how is the packaging done for DPDK?
>>
>>
> ./pkg/dpdk.spec  ?
>
>
>> On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
>>  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
>> >
>> >
>>
>
>

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

On 6 October 2017 at 20:05, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> wrote:

> Any experts on how is the packaging done for DPDK?
>
>
./pkg/dpdk.spec  ?


> On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
>  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
> >
> >
>

Re: [lng-odp] generic core + HW specific drivers

[Honnappa Nagarahalli]

Any experts on how is the packaging done for DPDK?

On 6 October 2017 at 08:36, Savolainen, Petri (Nokia - FI/Espoo)
 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
>
>

Re: [lng-odp] generic core + HW specific drivers

[Savolainen, Petri (Nokia - FI/Espoo)]

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

Re: [lng-odp] generic core + HW specific drivers

[Ola Liljedahl]

On 5 October 2017 at 12:09, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
> No HTML mails, please.
>
>
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Wednesday, October 04, 2017 3:55 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
> Cc: Andriy Berestovskyy <andriy.berestovs...@caviumnetworks.com>; Ola 
> Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] generic core + HW specific drivers
>
>
>
> On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) 
> <mailto:petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-
>> From: Andriy Berestovskyy 
>> [mailto:mailto:andriy.berestovs...@caviumnetworks.com]
>> Sent: Tuesday, October 03, 2017 8:22 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> <mailto:petri.savolai...@nokia.com>; Ola
>> Liljedahl <mailto:ola.liljed...@linaro.org>; mailto:lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] generic core + HW specific drivers
>>
>> Hey,
>> Please see below.
>>
>> On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > So, we should be able to deliver ODP as a set of HW independent and
>> > HW specific packages (libraries). For example, minimal install would
>> >  include only odp, odp-linux and odp-test-suite, but when on arm64
>> > (and especially when on ThunderX) odp-thunderx would be installed
>>
>> There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> there are no specific platform dependencies (i.e. Cavium ThunderX,
>> Cavium Octeon, NXP etc).
>>
>> In other words, there is no such mechanism in packaging to create a
>> package odp, which will automatically install package odp-thunderx only
>> on Cavium ThunderX platforms.
>
> I'd expect that ODP main package (e.g. for arm64) would run a script (written 
> by us) during install which digs out information about the system and sets up 
> ODP paths accordingly. E.g. libs/headers from odp-thunderx package would 
> added to search paths when installing into a ThunderX system. If system is 
> not recognized,  ODP libs/header paths would point into odp-linux.
>
> That's still trying to make this a static configuration that can be done at 
> install time. What about VMs/containers that are instantiated on different 
> hosts as they are deployed? This really needs to be determined at run time, 
> not install time.
>
>
>
> Also with a VM, all arm64 ODP packages would be present, and the problem to 
> solve would be which implementation to use (to link against). If a run time 
> code can probe the host system (e.g. are we on ThunderX), so does a script. 
> An ignorant user might not run additional scripts and thus be left with the 
> default setup (odp-linux). A more aware user would run an additional script 
> before launching/building any ODP apps. This script would notice that we have 
> e.g. ThunderX HW and would change ODP paths to point into odp-thunderx 
> libs/headers. The HW discovery could be as simple as cloud administrator 
> updating VM bootparams with SoC model information.
>
>
>>
>> All other projects you are mentioning (kernel, DPDK, Xorg) use
>> architecture dependency (different packages for different architectures)
>> combined with run time configuration/probing. A kernel driver might be
>> installed, but it will be unused until configured/probed.
>
> Those projects aim to maximize code re-use of the core part and minimize size 
> of the driver part. Optimally, we'd do the opposite - minimize the core part 
> to zero and dynamically link application directly to the right "driver" (== 
> HW specific odp implementation).
>
> If there's no core part, run time probing is not needed - install time 
> probing and lib/header path setup is enough.
>
> You're describing the embedded build case, which is similar to what we have 
> today with --enable-abi-compat=no. That's not changing. We're only talking 
> about what happens for --enable-abi-compat=yes builds.
>
>
>
> 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 

Re: [lng-odp] generic core + HW specific drivers

[Honnappa Nagarahalli]

On 5 October 2017 at 05:09, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
> No HTML mails, please.
>
>
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Wednesday, October 04, 2017 3:55 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
> Cc: Andriy Berestovskyy <andriy.berestovs...@caviumnetworks.com>; Ola 
> Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] generic core + HW specific drivers
>
>
>
> On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) 
> <mailto:petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-
>> From: Andriy Berestovskyy 
>> [mailto:mailto:andriy.berestovs...@caviumnetworks.com]
>> Sent: Tuesday, October 03, 2017 8:22 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> <mailto:petri.savolai...@nokia.com>; Ola
>> Liljedahl <mailto:ola.liljed...@linaro.org>; mailto:lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] generic core + HW specific drivers
>>
>> Hey,
>> Please see below.
>>
>> On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > So, we should be able to deliver ODP as a set of HW independent and
>> > HW specific packages (libraries). For example, minimal install would
>> >  include only odp, odp-linux and odp-test-suite, but when on arm64
>> > (and especially when on ThunderX) odp-thunderx would be installed
>>
>> There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> there are no specific platform dependencies (i.e. Cavium ThunderX,
>> Cavium Octeon, NXP etc).
>>
>> In other words, there is no such mechanism in packaging to create a
>> package odp, which will automatically install package odp-thunderx only
>> on Cavium ThunderX platforms.
>
> I'd expect that ODP main package (e.g. for arm64) would run a script (written 
> by us) during install which digs out information about the system and sets up 
> ODP paths accordingly. E.g. libs/headers from odp-thunderx package would 
> added to search paths when installing into a ThunderX system. If system is 
> not recognized,  ODP libs/header paths would point into odp-linux.
>
> That's still trying to make this a static configuration that can be done at 
> install time. What about VMs/containers that are instantiated on different 
> hosts as they are deployed? This really needs to be determined at run time, 
> not install time.
>
>
>
> Also with a VM, all arm64 ODP packages would be present, and the problem to 
> solve would be which implementation to use (to link against). If a run time 
> code can probe the host system (e.g. are we on ThunderX), so does a script. 
> An ignorant user might not run additional scripts and thus be left with the 
> default setup (odp-linux). A more aware user would run an additional script 
> before launching/building any ODP apps. This script would notice that we have 
> e.g. ThunderX HW and would change ODP paths to point into odp-thunderx 
> libs/headers. The HW discovery could be as simple as cloud administrator 
> updating VM bootparams with SoC model information.
>
>
>>
>> All other projects you are mentioning (kernel, DPDK, Xorg) use
>> architecture dependency (different packages for different architectures)
>> combined with run time configuration/probing. A kernel driver might be
>> installed, but it will be unused until configured/probed.
>
> Those projects aim to maximize code re-use of the core part and minimize size 
> of the driver part. Optimally, we'd do the opposite - minimize the core part 
> to zero and dynamically link application directly to the right "driver" (== 
> HW specific odp implementation).
>
> If there's no core part, run time probing is not needed - install time 
> probing and lib/header path setup is enough.
>
> You're describing the embedded build case, which is similar to what we have 
> today with --enable-abi-compat=no. That's not changing. We're only talking 
> about what happens for --enable-abi-compat=yes builds.
>
>
>
> 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.
>
> You may very well want to build and run non-ABI compat applications also in a 
> VM. Non-ABI compat just means that you are not going to run *the same 
> application image* with another implementation/system. You may still build 
> locally on the VM, or have bunch of (non-ABI compat) application images 
> pre-built - one per implement

Re: [lng-odp] generic core + HW specific drivers

[Honnappa Nagarahalli]

Bob Monkman commented on about 'platform discovery' during my talk at
Connect. His thought is that with Intel EPA and such (enhanced
platform awareness), the orchestrater will have in-depth data about
the platform. It will have information about the make and model of a
NIC/hardware accelerator for ex:. He promised to provide few
documents, I am following up.

Thanks,
Honnappa

On 4 October 2017 at 08:46, Francois Ozog <francois.o...@linaro.org> wrote:
> Hi Bogdan,
>
> cloud manager is a loosely defined entity ;-)
>
> In the context of NFV orchestration will not deal with this.
>
> VNF manager may but there is lack of "sensing" information.
>
> If you think of an AWS/Azure image, then this simply does not work.
>
> FF
>
> On 4 October 2017 at 15:27, Bogdan Pricope <bogdan.pric...@linaro.org>
> wrote:
>
>> There are (at least) three cases:
>>
>> 1.   Discovery is done by odp
>>
>> 2.   Discovery is done by application
>>
>> 3.   Discovery is done by a third party entity
>>
>>
>>
>> For cloud, I would expect a cloud administrator entity will know
>> exactly the configuration of each ‘target’ and this can be provided to
>> ‘target’ as an environment variable or a file.
>>
>>
>> This information can be used to:
>>
>> 1.   Generate an odp.conf file (with a predefine structure),
>> identifying the module(s) to load.
>>
>>
>> e.g.
>>
>> module:
>>
>> {
>>
>>modules = ("libodp_thunderx.so.0");
>>
>> };
>>
>>
>>
>> 2.   Download the actual module libs (e.g. from a network drive)
>> if cannot be deployed with the application (at the same time)
>>
>>
>>
>> Ultimately, odp.conf stored in a predetermined location or indicated
>> as an environment variable will be used by odp-core library to load
>> the module(s).
>>
>>
>>
>> ODP_SYSCONFIG_FILE=/tmp/odp.conf ./example/generator/odp_generator -I
>> 1 -m r -c 0x8
>>
>>
>>
>> /Bogdan
>>
>> On 4 October 2017 at 15:54, Bill Fischofer <bill.fischo...@linaro.org>
>> wrote:
>> > On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
>> > petri.savolai...@nokia.com> wrote:
>> >
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Andriy Berestovskyy [mailto:Andriy.Berestovskyy@
>> caviumnetworks.com
>> >> ]
>> >> > Sent: Tuesday, October 03, 2017 8:22 PM
>> >> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com
>> >;
>> >> Ola
>> >> > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
>> >> > Subject: Re: [lng-odp] generic core + HW specific drivers
>> >> >
>> >> > Hey,
>> >> > Please see below.
>> >> >
>> >> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> >> > > So, we should be able to deliver ODP as a set of HW independent and
>> >> > > HW specific packages (libraries). For example, minimal install would
>> >> > >  include only odp, odp-linux and odp-test-suite, but when on arm64
>> >> > > (and especially when on ThunderX) odp-thunderx would be installed
>> >> >
>> >> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> >> > there are no specific platform dependencies (i.e. Cavium ThunderX,
>> >> > Cavium Octeon, NXP etc).
>> >> >
>> >> > In other words, there is no such mechanism in packaging to create a
>> >> > package odp, which will automatically install package odp-thunderx
>> only
>> >> > on Cavium ThunderX platforms.
>> >>
>> >> I'd expect that ODP main package (e.g. for arm64) would run a script
>> >> (written by us) during install which digs out information about the
>> system
>> >> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
>> >> package would added to search paths when installing into a ThunderX
>> system.
>> >> If system is not recognized,  ODP libs/header paths would point into
>> >> odp-linux.
>> >>
>> >>
>> > That's still trying to make this a static configuration that can be done
>> at
>> > install time. What about VMs/containers that are instantiated on
>> different
>> > hosts as they are dep

Re: [lng-odp] generic core + HW specific drivers

[Savolainen, Petri (Nokia - FI/Espoo)]

No HTML mails, please.


From: Bill Fischofer [mailto:bill.fischo...@linaro.org] 
Sent: Wednesday, October 04, 2017 3:55 PM
To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
Cc: Andriy Berestovskyy <andriy.berestovs...@caviumnetworks.com>; Ola Liljedahl 
<ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
Subject: Re: [lng-odp] generic core + HW specific drivers



On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) 
<mailto:petri.savolai...@nokia.com> wrote:


> -Original Message-
> From: Andriy Berestovskyy 
> [mailto:mailto:andriy.berestovs...@caviumnetworks.com]
> Sent: Tuesday, October 03, 2017 8:22 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <mailto:petri.savolai...@nokia.com>; 
> Ola
> Liljedahl <mailto:ola.liljed...@linaro.org>; mailto:lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] generic core + HW specific drivers
>
> Hey,
> Please see below.
>
> On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > So, we should be able to deliver ODP as a set of HW independent and
> > HW specific packages (libraries). For example, minimal install would
> >  include only odp, odp-linux and odp-test-suite, but when on arm64
> > (and especially when on ThunderX) odp-thunderx would be installed
>
> There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
> there are no specific platform dependencies (i.e. Cavium ThunderX,
> Cavium Octeon, NXP etc).
>
> In other words, there is no such mechanism in packaging to create a
> package odp, which will automatically install package odp-thunderx only
> on Cavium ThunderX platforms.

I'd expect that ODP main package (e.g. for arm64) would run a script (written 
by us) during install which digs out information about the system and sets up 
ODP paths accordingly. E.g. libs/headers from odp-thunderx package would added 
to search paths when installing into a ThunderX system. If system is not 
recognized,  ODP libs/header paths would point into odp-linux.

That's still trying to make this a static configuration that can be done at 
install time. What about VMs/containers that are instantiated on different 
hosts as they are deployed? This really needs to be determined at run time, not 
install time. 



Also with a VM, all arm64 ODP packages would be present, and the problem to 
solve would be which implementation to use (to link against). If a run time 
code can probe the host system (e.g. are we on ThunderX), so does a script. An 
ignorant user might not run additional scripts and thus be left with the 
default setup (odp-linux). A more aware user would run an additional script 
before launching/building any ODP apps. This script would notice that we have 
e.g. ThunderX HW and would change ODP paths to point into odp-thunderx 
libs/headers. The HW discovery could be as simple as cloud administrator 
updating VM bootparams with SoC model information.


>
> All other projects you are mentioning (kernel, DPDK, Xorg) use
> architecture dependency (different packages for different architectures)
> combined with run time configuration/probing. A kernel driver might be
> installed, but it will be unused until configured/probed.

Those projects aim to maximize code re-use of the core part and minimize size 
of the driver part. Optimally, we'd do the opposite - minimize the core part to 
zero and dynamically link application directly to the right "driver" (== HW 
specific odp implementation).

If there's no core part, run time probing is not needed - install time probing 
and lib/header path setup is enough.

You're describing the embedded build case, which is similar to what we have 
today with --enable-abi-compat=no. That's not changing. We're only talking 
about what happens for --enable-abi-compat=yes builds.
 


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.

You may very well want to build and run non-ABI compat applications also in a 
VM. Non-ABI compat just means that you are not going to run *the same 
application image* with another implementation/system. You may still build 
locally on the VM, or have bunch of (non-ABI compat) application images 
pre-built - one per implementation/system.


>
> To support multiple platforms, runtime configuration/probing is
> inevitable. The real question is who does this probing: ODP itself or
> each application independently. To avoid code duplication, ODP looks
> like a better choice...

Install time probe/conf would be the best choice. The second best would be a 
dummy "core ODP" implementation which would be just a giant function pointer 
array (redirect every ODP API call to its implementation in a HW specific lib).

That's effect

Re: [lng-odp] generic core + HW specific drivers

[Ilias Apalodimas]

Hello Francois,

Exactly, my consideration was only on multiple NICs, present in 1
architecture.

Regards
Ilias

On 4 October 2017 at 16:42, Francois Ozog  wrote:

> Hi Ilias,
>
> there are two mechanisms:
>
> - modular framework
> - DDF
>
> Modular framework will be used to adapt to SoC platform.
> DDF will be used to adapt to pugable NICs
>
> So I guess you were referring to plugable NICs.
>
> FF
>
> On 4 October 2017 at 14:35, Ilias Apalodimas 
> wrote:
>
>> Let's say you are running on a platform with two different ethernet
>> interfaces. The vendor wants one active interface at any given time.
>> So auto discovering will have to somehow limit the modules it will load. I
>> am not sure this is a real requirement, i was just wondering if
>> it's possible.
>>
>> Regards
>> Ilias
>>
>>
>> On 4 October 2017 at 15:31, Bill Fischofer 
>> wrote:
>>
>> >
>> >
>> > On Wed, Oct 4, 2017 at 4:04 AM, Ilias Apalodimas <
>> > ilias.apalodi...@linaro.org> wrote:
>> >
>> >> Regarding the modules configuration, is there a possibility of "mixed
>> >> hardware"?
>> >> For example a vendor adds two or more devices of the same "type" that
>> are
>> >> supported from ODP but only wants one available at any given time. Is
>> this
>> >> a possibility?
>> >> If it is and we end up using some "auto discovery" method a
>> configuration
>> >> file/blacklisting method, will also be needed.
>> >>
>> >
>> > I'm not sure I understand. Discovery refers to determining at runtime
>> the
>> > specific platform the application is running on. That question always
>> has a
>> > determinate answer. The question of live migration to a different
>> platform
>> > is a separate one and something we've not yet looked at beyond listing
>> it
>> > as a "wish list" item.
>> >
>> >
>> >>
>> >> Regards
>> >> Ilias
>> >>
>> >>
>> >> On 4 October 2017 at 06:06, Brian Brooks 
>> wrote:
>> >>
>> >> > The approach taken by Vulkan project:
>> >> > https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/
>> >> > blob/master/loader/LoaderAndLayerInterface.md
>> >> >
>> >> > On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
>> >> >  wrote:
>> >> > > On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> >> > >>> -Original Message-
>> >> > >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On
>> Behalf
>> >> Of
>> >> > Ola
>> >> > >>> Liljedahl
>> >> > >>> Sent: Friday, September 29, 2017 8:47 PM
>> >> > >>> To: lng-odp@lists.linaro.org
>> >> > >>> Subject: [lng-odp] generic core + HW specific drivers
>> >> > >>>
>> >> > >>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
>> >> > >>> xorg install
>> >> > >>> xorg-docs-core install
>> >> > >>> xserver-xorg install
>> >> > >>> xserver-xorg-core install
>> >> > >>> xserver-xorg-input-all install
>> >> > >>> xserver-xorg-input-evdev install
>> >> > >>> xserver-xorg-input-libinput install
>> >> > >>> xserver-xorg-input-synaptics install
>> >> > >>> xserver-xorg-input-wacom install
>> >> > >>> xserver-xorg-video-all install
>> >> > >>> xserver-xorg-video-amdgpu install
>> >> > >>> xserver-xorg-video-ati install
>> >> > >>> xserver-xorg-video-fbdev install
>> >> > >>> xserver-xorg-video-intel install
>> >> > >>> xserver-xorg-video-mach64 install
>> >> > >>> xserver-xorg-video-neomagic install
>> >> > >>> xserver-xorg-video-nouveau install<<> >> > >>> xserver-xorg-video-openchrome install
>> >> > >>> xserver-xorg-video-qxl install
>> >> > >>> xserver-xorg-video-r128 install
>> >> > >>> xserver-xorg-video-radeon install .   <<> >> > >>> xserver-xorg-video-savage install
>> >> > >>> xserver-xorg-video-siliconmotion install
>> >> > >>> xserver-xorg-video-sisusb install
>> >> > >>> xserver-xorg-video-tdfx install
>> >> > >>> xserver-xorg-video-trident install
>> >> > >>> xserver-xorg-video-vesa install
>> >> > >>> xserver-xorg-video-vmware install .   <<> >> > >>>
>> >> > >>> So let's rename ODP Cloud to ODP Core.
>> >> > >>>
>> >> > >>> -- Ola
>> >> > >>
>> >> > >>
>> >> > >> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/a
>> >> rtful/dpdk)
>> >> > include many HW dependent packages
>> >> > >>
>> >> > >> ...
>> >> > >> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<<
>> Intel
>> >> Red
>> >> > Rock Canyon net driver, provided only for x86
>> >> > >> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
>> >> > >> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
>> >> > >> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
>> >> > >> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
>> >> > >> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
>> >> > >> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
>> >> > >> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
>> >> > >> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX
>> >> SSO
>> >> > eventdev driver files as a package
>> >> > >> librte-pmd-pcap17.05 (= 

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

Hi Bogdan,

cloud manager is a loosely defined entity ;-)

In the context of NFV orchestration will not deal with this.

VNF manager may but there is lack of "sensing" information.

If you think of an AWS/Azure image, then this simply does not work.

FF

On 4 October 2017 at 15:27, Bogdan Pricope <bogdan.pric...@linaro.org>
wrote:

> There are (at least) three cases:
>
> 1.   Discovery is done by odp
>
> 2.   Discovery is done by application
>
> 3.   Discovery is done by a third party entity
>
>
>
> For cloud, I would expect a cloud administrator entity will know
> exactly the configuration of each ‘target’ and this can be provided to
> ‘target’ as an environment variable or a file.
>
>
> This information can be used to:
>
> 1.   Generate an odp.conf file (with a predefine structure),
> identifying the module(s) to load.
>
>
> e.g.
>
> module:
>
> {
>
>modules = ("libodp_thunderx.so.0");
>
> };
>
>
>
> 2.   Download the actual module libs (e.g. from a network drive)
> if cannot be deployed with the application (at the same time)
>
>
>
> Ultimately, odp.conf stored in a predetermined location or indicated
> as an environment variable will be used by odp-core library to load
> the module(s).
>
>
>
> ODP_SYSCONFIG_FILE=/tmp/odp.conf ./example/generator/odp_generator -I
> 1 -m r -c 0x8
>
>
>
> /Bogdan
>
> On 4 October 2017 at 15:54, Bill Fischofer <bill.fischo...@linaro.org>
> wrote:
> > On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> > petri.savolai...@nokia.com> wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Andriy Berestovskyy [mailto:Andriy.Berestovskyy@
> caviumnetworks.com
> >> ]
> >> > Sent: Tuesday, October 03, 2017 8:22 PM
> >> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com
> >;
> >> Ola
> >> > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
> >> > Subject: Re: [lng-odp] generic core + HW specific drivers
> >> >
> >> > Hey,
> >> > Please see below.
> >> >
> >> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >> > > So, we should be able to deliver ODP as a set of HW independent and
> >> > > HW specific packages (libraries). For example, minimal install would
> >> > >  include only odp, odp-linux and odp-test-suite, but when on arm64
> >> > > (and especially when on ThunderX) odp-thunderx would be installed
> >> >
> >> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
> >> > there are no specific platform dependencies (i.e. Cavium ThunderX,
> >> > Cavium Octeon, NXP etc).
> >> >
> >> > In other words, there is no such mechanism in packaging to create a
> >> > package odp, which will automatically install package odp-thunderx
> only
> >> > on Cavium ThunderX platforms.
> >>
> >> I'd expect that ODP main package (e.g. for arm64) would run a script
> >> (written by us) during install which digs out information about the
> system
> >> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
> >> package would added to search paths when installing into a ThunderX
> system.
> >> If system is not recognized,  ODP libs/header paths would point into
> >> odp-linux.
> >>
> >>
> > That's still trying to make this a static configuration that can be done
> at
> > install time. What about VMs/containers that are instantiated on
> different
> > hosts as they are deployed? This really needs to be determined at run
> time,
> > not install time.
> >
> >
> >>
> >> >
> >> >
> >> > > Package:
> >> > > * odp * depends on: odp-linux
> >> > > * odp-linux * depends on: odp
> >> >  > * odp-thunderx [arm64] * depends on: odp
> >> >
> >> > So installing odp-thunderx we will end up with odp, odp-linux and
> >> > odp-thunderx, so still we have switch runtime between odp-linux and
> >> > odp-thunderx...
> >>
> >> I hope it's a matter of probing and installing paths on install time,
> >> instead of runtime. It's hard to believe that ODP would be the first
> >> package ever to choose and install a library from a set of alternative
> >> libraries.
> >>
> >
> > ODP is a pioneer in 

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

Hi Ilias,

there are two mechanisms:

- modular framework
- DDF

Modular framework will be used to adapt to SoC platform.
DDF will be used to adapt to pugable NICs

So I guess you were referring to plugable NICs.

FF

On 4 October 2017 at 14:35, Ilias Apalodimas 
wrote:

> Let's say you are running on a platform with two different ethernet
> interfaces. The vendor wants one active interface at any given time.
> So auto discovering will have to somehow limit the modules it will load. I
> am not sure this is a real requirement, i was just wondering if
> it's possible.
>
> Regards
> Ilias
>
>
> On 4 October 2017 at 15:31, Bill Fischofer 
> wrote:
>
> >
> >
> > On Wed, Oct 4, 2017 at 4:04 AM, Ilias Apalodimas <
> > ilias.apalodi...@linaro.org> wrote:
> >
> >> Regarding the modules configuration, is there a possibility of "mixed
> >> hardware"?
> >> For example a vendor adds two or more devices of the same "type" that
> are
> >> supported from ODP but only wants one available at any given time. Is
> this
> >> a possibility?
> >> If it is and we end up using some "auto discovery" method a
> configuration
> >> file/blacklisting method, will also be needed.
> >>
> >
> > I'm not sure I understand. Discovery refers to determining at runtime the
> > specific platform the application is running on. That question always
> has a
> > determinate answer. The question of live migration to a different
> platform
> > is a separate one and something we've not yet looked at beyond listing it
> > as a "wish list" item.
> >
> >
> >>
> >> Regards
> >> Ilias
> >>
> >>
> >> On 4 October 2017 at 06:06, Brian Brooks 
> wrote:
> >>
> >> > The approach taken by Vulkan project:
> >> > https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/
> >> > blob/master/loader/LoaderAndLayerInterface.md
> >> >
> >> > On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
> >> >  wrote:
> >> > > On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >> > >>> -Original Message-
> >> > >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf
> >> Of
> >> > Ola
> >> > >>> Liljedahl
> >> > >>> Sent: Friday, September 29, 2017 8:47 PM
> >> > >>> To: lng-odp@lists.linaro.org
> >> > >>> Subject: [lng-odp] generic core + HW specific drivers
> >> > >>>
> >> > >>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
> >> > >>> xorg install
> >> > >>> xorg-docs-core install
> >> > >>> xserver-xorg install
> >> > >>> xserver-xorg-core install
> >> > >>> xserver-xorg-input-all install
> >> > >>> xserver-xorg-input-evdev install
> >> > >>> xserver-xorg-input-libinput install
> >> > >>> xserver-xorg-input-synaptics install
> >> > >>> xserver-xorg-input-wacom install
> >> > >>> xserver-xorg-video-all install
> >> > >>> xserver-xorg-video-amdgpu install
> >> > >>> xserver-xorg-video-ati install
> >> > >>> xserver-xorg-video-fbdev install
> >> > >>> xserver-xorg-video-intel install
> >> > >>> xserver-xorg-video-mach64 install
> >> > >>> xserver-xorg-video-neomagic install
> >> > >>> xserver-xorg-video-nouveau install<< >> > >>> xserver-xorg-video-openchrome install
> >> > >>> xserver-xorg-video-qxl install
> >> > >>> xserver-xorg-video-r128 install
> >> > >>> xserver-xorg-video-radeon install .   << >> > >>> xserver-xorg-video-savage install
> >> > >>> xserver-xorg-video-siliconmotion install
> >> > >>> xserver-xorg-video-sisusb install
> >> > >>> xserver-xorg-video-tdfx install
> >> > >>> xserver-xorg-video-trident install
> >> > >>> xserver-xorg-video-vesa install
> >> > >>> xserver-xorg-video-vmware install .   << >> > >>>
> >> > >>> So let's rename ODP Cloud to ODP Core.
> >> > >>>
> >> > >>> -- Ola
> >> > >>
> >> > >>
> >> > >> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/a
> >> rtful/dpdk)
> >> > include many HW dependent packages
> >> > >>
> >> > >> ...
> >> > >> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel
> >> Red
> >> > Rock Canyon net driver, provided only for x86
> >> > >> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
> >> > >> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
> >> > >> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX
> >> SSO
> >> > eventdev driver files as a package
> >> > >> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
> >> > >> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
> >> > >> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
> >> > 

Re: [lng-odp] generic core + HW specific drivers

[Bogdan Pricope]

There are (at least) three cases:

1.   Discovery is done by odp

2.   Discovery is done by application

3.   Discovery is done by a third party entity



For cloud, I would expect a cloud administrator entity will know
exactly the configuration of each ‘target’ and this can be provided to
‘target’ as an environment variable or a file.


This information can be used to:

1.   Generate an odp.conf file (with a predefine structure),
identifying the module(s) to load.


e.g.

module:

{

   modules = ("libodp_thunderx.so.0");

};



2.   Download the actual module libs (e.g. from a network drive)
if cannot be deployed with the application (at the same time)



Ultimately, odp.conf stored in a predetermined location or indicated
as an environment variable will be used by odp-core library to load
the module(s).



ODP_SYSCONFIG_FILE=/tmp/odp.conf ./example/generator/odp_generator -I
1 -m r -c 0x8



/Bogdan

On 4 October 2017 at 15:54, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Andriy Berestovskyy [mailto:andriy.berestovs...@caviumnetworks.com
>> ]
>> > Sent: Tuesday, October 03, 2017 8:22 PM
>> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
>> Ola
>> > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
>> > Subject: Re: [lng-odp] generic core + HW specific drivers
>> >
>> > Hey,
>> > Please see below.
>> >
>> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > > So, we should be able to deliver ODP as a set of HW independent and
>> > > HW specific packages (libraries). For example, minimal install would
>> > >  include only odp, odp-linux and odp-test-suite, but when on arm64
>> > > (and especially when on ThunderX) odp-thunderx would be installed
>> >
>> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
>> > there are no specific platform dependencies (i.e. Cavium ThunderX,
>> > Cavium Octeon, NXP etc).
>> >
>> > In other words, there is no such mechanism in packaging to create a
>> > package odp, which will automatically install package odp-thunderx only
>> > on Cavium ThunderX platforms.
>>
>> I'd expect that ODP main package (e.g. for arm64) would run a script
>> (written by us) during install which digs out information about the system
>> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
>> package would added to search paths when installing into a ThunderX system.
>> If system is not recognized,  ODP libs/header paths would point into
>> odp-linux.
>>
>>
> That's still trying to make this a static configuration that can be done at
> install time. What about VMs/containers that are instantiated on different
> hosts as they are deployed? This really needs to be determined at run time,
> not install time.
>
>
>>
>> >
>> >
>> > > Package:
>> > > * odp * depends on: odp-linux
>> > > * odp-linux * depends on: odp
>> >  > * odp-thunderx [arm64] * depends on: odp
>> >
>> > So installing odp-thunderx we will end up with odp, odp-linux and
>> > odp-thunderx, so still we have switch runtime between odp-linux and
>> > odp-thunderx...
>>
>> I hope it's a matter of probing and installing paths on install time,
>> instead of runtime. It's hard to believe that ODP would be the first
>> package ever to choose and install a library from a set of alternative
>> libraries.
>>
>
> ODP is a pioneer in the sense that it's offering access to platform
> acceleration capabilities, not simple attached device variants. So we may
> well be first in this sense.
>
>
>>
>> >
>> >
>> > All other projects you are mentioning (kernel, DPDK, Xorg) use
>> > architecture dependency (different packages for different architectures)
>> > combined with run time configuration/probing. A kernel driver might be
>> > installed, but it will be unused until configured/probed.
>>
>> Those projects aim to maximize code re-use of the core part and minimize
>> size of the driver part. Optimally, we'd do the opposite - minimize the
>> core part to zero and dynamically link application directly to the right
>> "driver" (== HW specific odp implementation).
>>
>> If there's no core part, run time probing is not needed - install time
>> probing a

Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

On Wed, Oct 4, 2017 at 7:47 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>
> > -Original Message-
> > From: Andriy Berestovskyy [mailto:andriy.berestovs...@caviumnetworks.com
> ]
> > Sent: Tuesday, October 03, 2017 8:22 PM
> > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
> Ola
> > Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] generic core + HW specific drivers
> >
> > Hey,
> > Please see below.
> >
> > On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > > So, we should be able to deliver ODP as a set of HW independent and
> > > HW specific packages (libraries). For example, minimal install would
> > >  include only odp, odp-linux and odp-test-suite, but when on arm64
> > > (and especially when on ThunderX) odp-thunderx would be installed
> >
> > There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
> > there are no specific platform dependencies (i.e. Cavium ThunderX,
> > Cavium Octeon, NXP etc).
> >
> > In other words, there is no such mechanism in packaging to create a
> > package odp, which will automatically install package odp-thunderx only
> > on Cavium ThunderX platforms.
>
> I'd expect that ODP main package (e.g. for arm64) would run a script
> (written by us) during install which digs out information about the system
> and sets up ODP paths accordingly. E.g. libs/headers from odp-thunderx
> package would added to search paths when installing into a ThunderX system.
> If system is not recognized,  ODP libs/header paths would point into
> odp-linux.
>
>
That's still trying to make this a static configuration that can be done at
install time. What about VMs/containers that are instantiated on different
hosts as they are deployed? This really needs to be determined at run time,
not install time.


>
> >
> >
> > > Package:
> > > * odp * depends on: odp-linux
> > > * odp-linux * depends on: odp
> >  > * odp-thunderx [arm64] * depends on: odp
> >
> > So installing odp-thunderx we will end up with odp, odp-linux and
> > odp-thunderx, so still we have switch runtime between odp-linux and
> > odp-thunderx...
>
> I hope it's a matter of probing and installing paths on install time,
> instead of runtime. It's hard to believe that ODP would be the first
> package ever to choose and install a library from a set of alternative
> libraries.
>

ODP is a pioneer in the sense that it's offering access to platform
acceleration capabilities, not simple attached device variants. So we may
well be first in this sense.


>
> >
> >
> > All other projects you are mentioning (kernel, DPDK, Xorg) use
> > architecture dependency (different packages for different architectures)
> > combined with run time configuration/probing. A kernel driver might be
> > installed, but it will be unused until configured/probed.
>
> Those projects aim to maximize code re-use of the core part and minimize
> size of the driver part. Optimally, we'd do the opposite - minimize the
> core part to zero and dynamically link application directly to the right
> "driver" (== HW specific odp implementation).
>
> If there's no core part, run time probing is not needed - install time
> probing and lib/header path setup is enough.
>

You're describing the embedded build case, which is similar to what we have
today with --enable-abi-compat=no. That's not changing. We're only talking
about what happens for --enable-abi-compat=yes builds.


>
>
> >
> > To support multiple platforms, runtime configuration/probing is
> > inevitable. The real question is who does this probing: ODP itself or
> > each application independently. To avoid code duplication, ODP looks
> > like a better choice...
>
> Install time probe/conf would be the best choice. The second best would be
> a dummy "core ODP" implementation which would be just a giant function
> pointer array (redirect every ODP API call to its implementation in a HW
> specific lib).
>

That's effectively what this is, except that the population of that
indirection array is done at runtime and may vary from run to run based on
the environment (e.g., is the app running in this container/VM authorized
to use feature X on this platform? If not, fall back to the generic SW
implementation, etc.)


>
> -Petri
>
>
>

Re: [lng-odp] generic core + HW specific drivers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: Andriy Berestovskyy [mailto:andriy.berestovs...@caviumnetworks.com]
> Sent: Tuesday, October 03, 2017 8:22 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>; Ola
> Liljedahl <ola.liljed...@linaro.org>; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] generic core + HW specific drivers
> 
> Hey,
> Please see below.
> 
> On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > So, we should be able to deliver ODP as a set of HW independent and
> > HW specific packages (libraries). For example, minimal install would
> >  include only odp, odp-linux and odp-test-suite, but when on arm64
> > (and especially when on ThunderX) odp-thunderx would be installed
> 
> There are architecture dependencies (i.e. i386, amd64, arm64 etc), but
> there are no specific platform dependencies (i.e. Cavium ThunderX,
> Cavium Octeon, NXP etc).
> 
> In other words, there is no such mechanism in packaging to create a
> package odp, which will automatically install package odp-thunderx only
> on Cavium ThunderX platforms.

I'd expect that ODP main package (e.g. for arm64) would run a script (written 
by us) during install which digs out information about the system and sets up 
ODP paths accordingly. E.g. libs/headers from odp-thunderx package would added 
to search paths when installing into a ThunderX system. If system is not 
recognized,  ODP libs/header paths would point into odp-linux.


> 
> 
> > Package:
> > * odp * depends on: odp-linux
> > * odp-linux * depends on: odp
>  > * odp-thunderx [arm64] * depends on: odp
> 
> So installing odp-thunderx we will end up with odp, odp-linux and
> odp-thunderx, so still we have switch runtime between odp-linux and
> odp-thunderx...

I hope it's a matter of probing and installing paths on install time, instead 
of runtime. It's hard to believe that ODP would be the first package ever to 
choose and install a library from a set of alternative libraries.

> 
> 
> All other projects you are mentioning (kernel, DPDK, Xorg) use
> architecture dependency (different packages for different architectures)
> combined with run time configuration/probing. A kernel driver might be
> installed, but it will be unused until configured/probed.

Those projects aim to maximize code re-use of the core part and minimize size 
of the driver part. Optimally, we'd do the opposite - minimize the core part to 
zero and dynamically link application directly to the right "driver" (== HW 
specific odp implementation).

If there's no core part, run time probing is not needed - install time probing 
and lib/header path setup is enough.


> 
> To support multiple platforms, runtime configuration/probing is
> inevitable. The real question is who does this probing: ODP itself or
> each application independently. To avoid code duplication, ODP looks
> like a better choice...

Install time probe/conf would be the best choice. The second best would be a 
dummy "core ODP" implementation which would be just a giant function pointer 
array (redirect every ODP API call to its implementation in a HW specific lib). 

-Petri

Re: [lng-odp] generic core + HW specific drivers

[Ilias Apalodimas]

Let's say you are running on a platform with two different ethernet
interfaces. The vendor wants one active interface at any given time.
So auto discovering will have to somehow limit the modules it will load. I
am not sure this is a real requirement, i was just wondering if
it's possible.

Regards
Ilias


On 4 October 2017 at 15:31, Bill Fischofer 
wrote:

>
>
> On Wed, Oct 4, 2017 at 4:04 AM, Ilias Apalodimas <
> ilias.apalodi...@linaro.org> wrote:
>
>> Regarding the modules configuration, is there a possibility of "mixed
>> hardware"?
>> For example a vendor adds two or more devices of the same "type" that are
>> supported from ODP but only wants one available at any given time. Is this
>> a possibility?
>> If it is and we end up using some "auto discovery" method a configuration
>> file/blacklisting method, will also be needed.
>>
>
> I'm not sure I understand. Discovery refers to determining at runtime the
> specific platform the application is running on. That question always has a
> determinate answer. The question of live migration to a different platform
> is a separate one and something we've not yet looked at beyond listing it
> as a "wish list" item.
>
>
>>
>> Regards
>> Ilias
>>
>>
>> On 4 October 2017 at 06:06, Brian Brooks  wrote:
>>
>> > The approach taken by Vulkan project:
>> > https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/
>> > blob/master/loader/LoaderAndLayerInterface.md
>> >
>> > On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
>> >  wrote:
>> > > On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> > >>> -Original Message-
>> > >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf
>> Of
>> > Ola
>> > >>> Liljedahl
>> > >>> Sent: Friday, September 29, 2017 8:47 PM
>> > >>> To: lng-odp@lists.linaro.org
>> > >>> Subject: [lng-odp] generic core + HW specific drivers
>> > >>>
>> > >>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
>> > >>> xorg install
>> > >>> xorg-docs-core install
>> > >>> xserver-xorg install
>> > >>> xserver-xorg-core install
>> > >>> xserver-xorg-input-all install
>> > >>> xserver-xorg-input-evdev install
>> > >>> xserver-xorg-input-libinput install
>> > >>> xserver-xorg-input-synaptics install
>> > >>> xserver-xorg-input-wacom install
>> > >>> xserver-xorg-video-all install
>> > >>> xserver-xorg-video-amdgpu install
>> > >>> xserver-xorg-video-ati install
>> > >>> xserver-xorg-video-fbdev install
>> > >>> xserver-xorg-video-intel install
>> > >>> xserver-xorg-video-mach64 install
>> > >>> xserver-xorg-video-neomagic install
>> > >>> xserver-xorg-video-nouveau install<<> > >>> xserver-xorg-video-openchrome install
>> > >>> xserver-xorg-video-qxl install
>> > >>> xserver-xorg-video-r128 install
>> > >>> xserver-xorg-video-radeon install .   <<> > >>> xserver-xorg-video-savage install
>> > >>> xserver-xorg-video-siliconmotion install
>> > >>> xserver-xorg-video-sisusb install
>> > >>> xserver-xorg-video-tdfx install
>> > >>> xserver-xorg-video-trident install
>> > >>> xserver-xorg-video-vesa install
>> > >>> xserver-xorg-video-vmware install .   <<> > >>>
>> > >>> So let's rename ODP Cloud to ODP Core.
>> > >>>
>> > >>> -- Ola
>> > >>
>> > >>
>> > >> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/a
>> rtful/dpdk)
>> > include many HW dependent packages
>> > >>
>> > >> ...
>> > >> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel
>> Red
>> > Rock Canyon net driver, provided only for x86
>> > >> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
>> > >> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
>> > >> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX
>> SSO
>> > eventdev driver files as a package
>> > >> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
>> > >> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
>> > >> librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net
>> > driver files as a package
>> > >> ...
>> > >>
>> > >>
>> > >> So, we should be able to deliver ODP as a set of HW independent and
>> HW
>> > specific packages (libraries). For example, minimal install would
>> include
>> > only odp, odp-linux and odp-test-suite, but when on arm64 (and
>> especially
>> > when on ThunderX) odp-thunderx would be installed also. The trick would
>> be
>> > how to select odp-thunderx installed files (also headers) as default
>> when

Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

On Wed, Oct 4, 2017 at 4:04 AM, Ilias Apalodimas <
ilias.apalodi...@linaro.org> wrote:

> Regarding the modules configuration, is there a possibility of "mixed
> hardware"?
> For example a vendor adds two or more devices of the same "type" that are
> supported from ODP but only wants one available at any given time. Is this
> a possibility?
> If it is and we end up using some "auto discovery" method a configuration
> file/blacklisting method, will also be needed.
>

I'm not sure I understand. Discovery refers to determining at runtime the
specific platform the application is running on. That question always has a
determinate answer. The question of live migration to a different platform
is a separate one and something we've not yet looked at beyond listing it
as a "wish list" item.


>
> Regards
> Ilias
>
>
> On 4 October 2017 at 06:06, Brian Brooks  wrote:
>
> > The approach taken by Vulkan project:
> > https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/
> > blob/master/loader/LoaderAndLayerInterface.md
> >
> > On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
> >  wrote:
> > > On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > >>> -Original Message-
> > >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Ola
> > >>> Liljedahl
> > >>> Sent: Friday, September 29, 2017 8:47 PM
> > >>> To: lng-odp@lists.linaro.org
> > >>> Subject: [lng-odp] generic core + HW specific drivers
> > >>>
> > >>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
> > >>> xorg install
> > >>> xorg-docs-core install
> > >>> xserver-xorg install
> > >>> xserver-xorg-core install
> > >>> xserver-xorg-input-all install
> > >>> xserver-xorg-input-evdev install
> > >>> xserver-xorg-input-libinput install
> > >>> xserver-xorg-input-synaptics install
> > >>> xserver-xorg-input-wacom install
> > >>> xserver-xorg-video-all install
> > >>> xserver-xorg-video-amdgpu install
> > >>> xserver-xorg-video-ati install
> > >>> xserver-xorg-video-fbdev install
> > >>> xserver-xorg-video-intel install
> > >>> xserver-xorg-video-mach64 install
> > >>> xserver-xorg-video-neomagic install
> > >>> xserver-xorg-video-nouveau install<< > >>> xserver-xorg-video-openchrome install
> > >>> xserver-xorg-video-qxl install
> > >>> xserver-xorg-video-r128 install
> > >>> xserver-xorg-video-radeon install .   << > >>> xserver-xorg-video-savage install
> > >>> xserver-xorg-video-siliconmotion install
> > >>> xserver-xorg-video-sisusb install
> > >>> xserver-xorg-video-tdfx install
> > >>> xserver-xorg-video-trident install
> > >>> xserver-xorg-video-vesa install
> > >>> xserver-xorg-video-vmware install .   << > >>>
> > >>> So let's rename ODP Cloud to ODP Core.
> > >>>
> > >>> -- Ola
> > >>
> > >>
> > >> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/
> artful/dpdk)
> > include many HW dependent packages
> > >>
> > >> ...
> > >> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel
> Red
> > Rock Canyon net driver, provided only for x86
> > >> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
> > >> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
> > >> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX SSO
> > eventdev driver files as a package
> > >> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
> > >> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
> > >> librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net
> > driver files as a package
> > >> ...
> > >>
> > >>
> > >> So, we should be able to deliver ODP as a set of HW independent and HW
> > specific packages (libraries). For example, minimal install would include
> > only odp, odp-linux and odp-test-suite, but when on arm64 (and especially
> > when on ThunderX) odp-thunderx would be installed also. The trick would
> be
> > how to select odp-thunderx installed files (also headers) as default when
> > application is built or run on ThunderX (and not on another arm64).
> > >>
> > >> Package:
> > >> * odp (only generic folders and documentation, no implementation)
> > >>   * depends on: odp-linux, odp-test-suite
> > >>   * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ...
> > >> * odp-linux
> > >>   * depends on: odp, openssl
> > >>   * recommends: dpdk, netmap, ...
> > >> * odp-dpdk
> > >>   * depends on: odp, dpdk
> > >> * odp-thunderx [arm64]
> > >>   * depends on: odp, ...
> > >> * odp-test-suite
> > 

Re: [lng-odp] generic core + HW specific drivers

[Ilias Apalodimas]

Regarding the modules configuration, is there a possibility of "mixed
hardware"?
For example a vendor adds two or more devices of the same "type" that are
supported from ODP but only wants one available at any given time. Is this
a possibility?
If it is and we end up using some "auto discovery" method a configuration
file/blacklisting method, will also be needed.

Regards
Ilias


On 4 October 2017 at 06:06, Brian Brooks  wrote:

> The approach taken by Vulkan project:
> https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/
> blob/master/loader/LoaderAndLayerInterface.md
>
> On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
>  wrote:
> > On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >>> -Original Message-
> >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Ola
> >>> Liljedahl
> >>> Sent: Friday, September 29, 2017 8:47 PM
> >>> To: lng-odp@lists.linaro.org
> >>> Subject: [lng-odp] generic core + HW specific drivers
> >>>
> >>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
> >>> xorg install
> >>> xorg-docs-core install
> >>> xserver-xorg install
> >>> xserver-xorg-core install
> >>> xserver-xorg-input-all install
> >>> xserver-xorg-input-evdev install
> >>> xserver-xorg-input-libinput install
> >>> xserver-xorg-input-synaptics install
> >>> xserver-xorg-input-wacom install
> >>> xserver-xorg-video-all install
> >>> xserver-xorg-video-amdgpu install
> >>> xserver-xorg-video-ati install
> >>> xserver-xorg-video-fbdev install
> >>> xserver-xorg-video-intel install
> >>> xserver-xorg-video-mach64 install
> >>> xserver-xorg-video-neomagic install
> >>> xserver-xorg-video-nouveau install<< >>> xserver-xorg-video-openchrome install
> >>> xserver-xorg-video-qxl install
> >>> xserver-xorg-video-r128 install
> >>> xserver-xorg-video-radeon install .   << >>> xserver-xorg-video-savage install
> >>> xserver-xorg-video-siliconmotion install
> >>> xserver-xorg-video-sisusb install
> >>> xserver-xorg-video-tdfx install
> >>> xserver-xorg-video-trident install
> >>> xserver-xorg-video-vesa install
> >>> xserver-xorg-video-vmware install .   << >>>
> >>> So let's rename ODP Cloud to ODP Core.
> >>>
> >>> -- Ola
> >>
> >>
> >> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk)
> include many HW dependent packages
> >>
> >> ...
> >> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red
> Rock Canyon net driver, provided only for x86
> >> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
> >> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
> >> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX SSO
> eventdev driver files as a package
> >> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
> >> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
> >> librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net
> driver files as a package
> >> ...
> >>
> >>
> >> So, we should be able to deliver ODP as a set of HW independent and HW
> specific packages (libraries). For example, minimal install would include
> only odp, odp-linux and odp-test-suite, but when on arm64 (and especially
> when on ThunderX) odp-thunderx would be installed also. The trick would be
> how to select odp-thunderx installed files (also headers) as default when
> application is built or run on ThunderX (and not on another arm64).
> >>
> >> Package:
> >> * odp (only generic folders and documentation, no implementation)
> >>   * depends on: odp-linux, odp-test-suite
> >>   * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ...
> >> * odp-linux
> >>   * depends on: odp, openssl
> >>   * recommends: dpdk, netmap, ...
> >> * odp-dpdk
> >>   * depends on: odp, dpdk
> >> * odp-thunderx [arm64]
> >>   * depends on: odp, ...
> >> * odp-test-suite
> >>   * depends on: odp
> >
> > I suppose this would satisfy distribution requirements. Especially if we
> > can merge all platforms to the same repo. It might be reasonable to
> > optionally follow the model of OpenCL ICD (installable client drivers),
> > when there is a frontend library moderating access to several backend
> > libraries. Each driver can be built as a stand-along libopencl or as
> > ICD, being picked up by frontend libopencl1. Modular ODP might well be
> > just one of these drivers, serving the case when single platform
> > combines different hardware instances.
> >
> > --
> > With best wishes
> > Dmitry
>

Re: [lng-odp] generic core + HW specific drivers

[Brian Brooks]

The approach taken by Vulkan project:
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md

On Tue, Oct 3, 2017 at 6:52 PM, Dmitry Eremin-Solenikov
 wrote:
> On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola
>>> Liljedahl
>>> Sent: Friday, September 29, 2017 8:47 PM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] generic core + HW specific drivers
>>>
>>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
>>> xorg install
>>> xorg-docs-core install
>>> xserver-xorg install
>>> xserver-xorg-core install
>>> xserver-xorg-input-all install
>>> xserver-xorg-input-evdev install
>>> xserver-xorg-input-libinput install
>>> xserver-xorg-input-synaptics install
>>> xserver-xorg-input-wacom install
>>> xserver-xorg-video-all install
>>> xserver-xorg-video-amdgpu install
>>> xserver-xorg-video-ati install
>>> xserver-xorg-video-fbdev install
>>> xserver-xorg-video-intel install
>>> xserver-xorg-video-mach64 install
>>> xserver-xorg-video-neomagic install
>>> xserver-xorg-video-nouveau install<<>> xserver-xorg-video-openchrome install
>>> xserver-xorg-video-qxl install
>>> xserver-xorg-video-r128 install
>>> xserver-xorg-video-radeon install .   <<>> xserver-xorg-video-savage install
>>> xserver-xorg-video-siliconmotion install
>>> xserver-xorg-video-sisusb install
>>> xserver-xorg-video-tdfx install
>>> xserver-xorg-video-trident install
>>> xserver-xorg-video-vesa install
>>> xserver-xorg-video-vmware install .   <<>>
>>> So let's rename ODP Cloud to ODP Core.
>>>
>>> -- Ola
>>
>>
>> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk) 
>> include many HW dependent packages
>>
>> ...
>> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red Rock 
>> Canyon net driver, provided only for x86
>> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
>> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
>> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX SSO 
>> eventdev driver files as a package
>> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
>> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
>> librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net driver 
>> files as a package
>> ...
>>
>>
>> So, we should be able to deliver ODP as a set of HW independent and HW 
>> specific packages (libraries). For example, minimal install would include 
>> only odp, odp-linux and odp-test-suite, but when on arm64 (and especially 
>> when on ThunderX) odp-thunderx would be installed also. The trick would be 
>> how to select odp-thunderx installed files (also headers) as default when 
>> application is built or run on ThunderX (and not on another arm64).
>>
>> Package:
>> * odp (only generic folders and documentation, no implementation)
>>   * depends on: odp-linux, odp-test-suite
>>   * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ...
>> * odp-linux
>>   * depends on: odp, openssl
>>   * recommends: dpdk, netmap, ...
>> * odp-dpdk
>>   * depends on: odp, dpdk
>> * odp-thunderx [arm64]
>>   * depends on: odp, ...
>> * odp-test-suite
>>   * depends on: odp
>
> I suppose this would satisfy distribution requirements. Especially if we
> can merge all platforms to the same repo. It might be reasonable to
> optionally follow the model of OpenCL ICD (installable client drivers),
> when there is a frontend library moderating access to several backend
> libraries. Each driver can be built as a stand-along libopencl or as
> ICD, being picked up by frontend libopencl1. Modular ODP might well be
> just one of these drivers, serving the case when single platform
> combines different hardware instances.
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] generic core + HW specific drivers

[Dmitry Eremin-Solenikov]

On 03/10/17 11:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola
>> Liljedahl
>> Sent: Friday, September 29, 2017 8:47 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] generic core + HW specific drivers
>>
>> olli@vubuntu:~$ dpkg --get-selections | grep xorg
>> xorg install
>> xorg-docs-core install
>> xserver-xorg install
>> xserver-xorg-core install
>> xserver-xorg-input-all install
>> xserver-xorg-input-evdev install
>> xserver-xorg-input-libinput install
>> xserver-xorg-input-synaptics install
>> xserver-xorg-input-wacom install
>> xserver-xorg-video-all install
>> xserver-xorg-video-amdgpu install
>> xserver-xorg-video-ati install
>> xserver-xorg-video-fbdev install
>> xserver-xorg-video-intel install
>> xserver-xorg-video-mach64 install
>> xserver-xorg-video-neomagic install
>> xserver-xorg-video-nouveau install<<> xserver-xorg-video-openchrome install
>> xserver-xorg-video-qxl install
>> xserver-xorg-video-r128 install
>> xserver-xorg-video-radeon install .   <<> xserver-xorg-video-savage install
>> xserver-xorg-video-siliconmotion install
>> xserver-xorg-video-sisusb install
>> xserver-xorg-video-tdfx install
>> xserver-xorg-video-trident install
>> xserver-xorg-video-vesa install
>> xserver-xorg-video-vmware install .   <<>
>> So let's rename ODP Cloud to ODP Core.
>>
>> -- Ola
> 
> 
> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk) 
> include many HW dependent packages 
> 
> ...
> librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red Rock 
> Canyon net driver, provided only for x86
> librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
> librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
> librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX SSO 
> eventdev driver files as a package
> librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
> librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
> librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net driver 
> files as a package
> ...
> 
> 
> So, we should be able to deliver ODP as a set of HW independent and HW 
> specific packages (libraries). For example, minimal install would include 
> only odp, odp-linux and odp-test-suite, but when on arm64 (and especially 
> when on ThunderX) odp-thunderx would be installed also. The trick would be 
> how to select odp-thunderx installed files (also headers) as default when 
> application is built or run on ThunderX (and not on another arm64).
> 
> Package:
> * odp (only generic folders and documentation, no implementation)
>   * depends on: odp-linux, odp-test-suite
>   * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ...
> * odp-linux
>   * depends on: odp, openssl
>   * recommends: dpdk, netmap, ...
> * odp-dpdk
>   * depends on: odp, dpdk
> * odp-thunderx [arm64]
>   * depends on: odp, ...
> * odp-test-suite
>   * depends on: odp

I suppose this would satisfy distribution requirements. Especially if we
can merge all platforms to the same repo. It might be reasonable to
optionally follow the model of OpenCL ICD (installable client drivers),
when there is a frontend library moderating access to several backend
libraries. Each driver can be built as a stand-along libopencl or as
ICD, being picked up by frontend libopencl1. Modular ODP might well be
just one of these drivers, serving the case when single platform
combines different hardware instances.

-- 
With best wishes
Dmitry

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

I would leave it tu SoC vendors that can define a reliable and sustainable
method...

Le mar. 3 oct. 2017 à 22:26, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> a écrit :

> On 3 October 2017 at 08:51, Francois Ozog 
> wrote:
> > Hi Maxim,
> >
> > Modularization is configurable so that the produced output can be either:
> > - runtime selection of modules based on whatever discovery mechanism is
> > available
> > - fixed compilation of a set of modules
> >
> > As per the discovery, I would favor a similar approach to packetio: give
> an
> > opportunity to each module to say if it is appropriate for the
> environment.
> > This avoids a standardized way to detect platform which may not even
> exist:
> > - A thunderX module may check for PCI bus existence, and if yes certain
> PCI
> > entries, or any other method (devicetree? ACPI?)
> > - A DPAA2 may check for DPAA2 bus existence and particular objects for
> each
> > board, or any other method (devicetree? ACPI?)
> >
> I was thinking that the platform discovery could be at a higher level.
> Identify a processor string via /proc or such entry. Then use that
> string to map to a set of libraries for that platform (this mapping
> could be through config files). The libraries in turn should handle
> any variations in the platform.
>
> >
> > FF
> >
> >
> > On 3 October 2017 at 15:33, Maxim Uvarov 
> wrote:
> >
> >>
> >>
> >> On 3 October 2017 at 15:59, Bill Fischofer 
> >> wrote:
> >>
> >>> Good summary. The key is that RedHat and others want:
> >>>
> >>> 1. They build the distribution from source we provide, we don't get to
> >>> provide any binaries
> >>> 2. There is a single distribution they will support per-ISA (e.g.,
> >>> AArch64)
> >>>
> >>> The modular framework is designed to accommodate these requirements by
> >>> allowing a "universal core" to discover the microarchitecture at run
> time
> >>> and the most appropriate pluggable modules to use to exploit that
> >>> microarchitecture's acceleration capabilities. These modules may be
> >>> precompiled along with the core if they are part of the single ODP
> >>> distribution, or they may be packaged and distributed separately as the
> >>> supplier of these modules wishes.
> >>>
> >>> At the same time, this universal core can be statically linked for a
> >>> specific target platform to accommodate the needs of embedded
> >>> applications.
> >>> In this case the discovery and call-indirection goes away so there
> should
> >>> be no more overhead than exists in today's ODP when switching between
> >>> --enable-abi-compat=[yes|no]
> >>>
> >>>
> >> I have nothing to object about modularization components in linux-gen
> but
> >> can we be more consistent. Or we speak
> >> about runtime discovery or we speak about configuration files. I hear
> one
> >> day people say about discovery, next day
> >> about configuration files.
> >> Does somebody have understanding how that discovery will work? How odp
> in
> >> guest will understand during discovery what
> >> to use? Scan PCI devices or some drivers? With drivers that is mode
> clear
> >> as with other odp components.
> >>
> >> I think that people more afraid that changes to current master will
> bring
> >> side affects as more complexity and less performance.
> >> Maintain new work in separate branch is complex but I think we need to
> >> define requirements when code can be merged to master.
> >> These requirements from my side can be:
> >> - no performance degradation according to current code;
> >> - feature completeness (which means module framework works, we can
> change
> >> scheduler, do discovery at least some platforms,
> >> some pktio from module ddf works);
> >> - code is formed as clean patches on top of current master and passes
> >> merging review (I'm not sure how many people review current cloud-dev
> >> branch work);
> >> - at least several platforms are merged together with that framework to
> >> show it's effectiveness;
> >>
> >> In my understanding if all 4 items are met nobody will have objections.
> >>
> >> Other thing is might be shift priorities a little bit. Instead of
> changing
> >> everything to modules, change one or two things, merge second platform
> and
> >> make it work. Then send clean patches for review.
> >>
> >> Any thoughts on that?
> >>
> >> Thank you,
> >> Maxim.
> >>
> >>
> >>
> >>> On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog <
> francois.o...@linaro.org>
> >>> wrote:
> >>>
> >>> > Thanks Ola and Petri.
> >>> >
> >>> > Let's talk about use cases first.
> >>> >
> >>> > Go to market for ODP applications may be:
> >>> >
> >>> >- A product composed of software and hardware (typically a NEP
> >>> approach
> >>> >such as Nokia)
> >>> >- A software to be installed by a system administrator of an
> >>> enterprise
> >>> >- A "service" to be part of a cloud offering (say an AWS image)
> >>> >- A VNF to be deployed on a wide 

Re: [lng-odp] generic core + HW specific drivers

[Honnappa Nagarahalli]

On 3 October 2017 at 08:51, Francois Ozog  wrote:
> Hi Maxim,
>
> Modularization is configurable so that the produced output can be either:
> - runtime selection of modules based on whatever discovery mechanism is
> available
> - fixed compilation of a set of modules
>
> As per the discovery, I would favor a similar approach to packetio: give an
> opportunity to each module to say if it is appropriate for the environment.
> This avoids a standardized way to detect platform which may not even exist:
> - A thunderX module may check for PCI bus existence, and if yes certain PCI
> entries, or any other method (devicetree? ACPI?)
> - A DPAA2 may check for DPAA2 bus existence and particular objects for each
> board, or any other method (devicetree? ACPI?)
>
I was thinking that the platform discovery could be at a higher level.
Identify a processor string via /proc or such entry. Then use that
string to map to a set of libraries for that platform (this mapping
could be through config files). The libraries in turn should handle
any variations in the platform.

>
> FF
>
>
> On 3 October 2017 at 15:33, Maxim Uvarov  wrote:
>
>>
>>
>> On 3 October 2017 at 15:59, Bill Fischofer 
>> wrote:
>>
>>> Good summary. The key is that RedHat and others want:
>>>
>>> 1. They build the distribution from source we provide, we don't get to
>>> provide any binaries
>>> 2. There is a single distribution they will support per-ISA (e.g.,
>>> AArch64)
>>>
>>> The modular framework is designed to accommodate these requirements by
>>> allowing a "universal core" to discover the microarchitecture at run time
>>> and the most appropriate pluggable modules to use to exploit that
>>> microarchitecture's acceleration capabilities. These modules may be
>>> precompiled along with the core if they are part of the single ODP
>>> distribution, or they may be packaged and distributed separately as the
>>> supplier of these modules wishes.
>>>
>>> At the same time, this universal core can be statically linked for a
>>> specific target platform to accommodate the needs of embedded
>>> applications.
>>> In this case the discovery and call-indirection goes away so there should
>>> be no more overhead than exists in today's ODP when switching between
>>> --enable-abi-compat=[yes|no]
>>>
>>>
>> I have nothing to object about modularization components in linux-gen but
>> can we be more consistent. Or we speak
>> about runtime discovery or we speak about configuration files. I hear one
>> day people say about discovery, next day
>> about configuration files.
>> Does somebody have understanding how that discovery will work? How odp in
>> guest will understand during discovery what
>> to use? Scan PCI devices or some drivers? With drivers that is mode clear
>> as with other odp components.
>>
>> I think that people more afraid that changes to current master will bring
>> side affects as more complexity and less performance.
>> Maintain new work in separate branch is complex but I think we need to
>> define requirements when code can be merged to master.
>> These requirements from my side can be:
>> - no performance degradation according to current code;
>> - feature completeness (which means module framework works, we can change
>> scheduler, do discovery at least some platforms,
>> some pktio from module ddf works);
>> - code is formed as clean patches on top of current master and passes
>> merging review (I'm not sure how many people review current cloud-dev
>> branch work);
>> - at least several platforms are merged together with that framework to
>> show it's effectiveness;
>>
>> In my understanding if all 4 items are met nobody will have objections.
>>
>> Other thing is might be shift priorities a little bit. Instead of changing
>> everything to modules, change one or two things, merge second platform and
>> make it work. Then send clean patches for review.
>>
>> Any thoughts on that?
>>
>> Thank you,
>> Maxim.
>>
>>
>>
>>> On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog 
>>> wrote:
>>>
>>> > Thanks Ola and Petri.
>>> >
>>> > Let's talk about use cases first.
>>> >
>>> > Go to market for ODP applications may be:
>>> >
>>> >- A product composed of software and hardware (typically a NEP
>>> approach
>>> >such as Nokia)
>>> >- A software to be installed by a system administrator of an
>>> enterprise
>>> >- A "service" to be part of a cloud offering (say an AWS image)
>>> >- A VNF to be deployed on a wide variety, apriori unknown, of
>>> hardware
>>> >as a VM
>>> >- An image to be deployed on bare metal clouds (packet.net or OVH
>>> for
>>> >instance) with hardware diversity
>>> >
>>> > As a result, an ODP application may be :
>>> >
>>> >1. Deployed as a single installed image and instantiated in different
>>> >virtualized or bare metal clouds
>>> >2. A VM is live migrated between two asymetric compute nodes
>>> > 

Re: [lng-odp] generic core + HW specific drivers

[Honnappa Nagarahalli]

On 3 October 2017 at 07:59, Bill Fischofer  wrote:
> Good summary. The key is that RedHat and others want:
>
> 1. They build the distribution from source we provide, we don't get to
> provide any binaries
> 2. There is a single distribution they will support per-ISA (e.g., AArch64)
>
> The modular framework is designed to accommodate these requirements by
> allowing a "universal core" to discover the microarchitecture at run time
> and the most appropriate pluggable modules to use to exploit that
> microarchitecture's acceleration capabilities. These modules may be
> precompiled along with the core if they are part of the single ODP
> distribution, or they may be packaged and distributed separately as the
> supplier of these modules wishes.
>
> At the same time, this universal core can be statically linked for a
> specific target platform to accommodate the needs of embedded applications.
> In this case the discovery and call-indirection goes away so there should
> be no more overhead than exists in today's ODP when switching between
> --enable-abi-compat=[yes|no]

Agree. We are currently looking into how the inline functions can be
enabled when building for a specific target platform.

>
> On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog 
> wrote:
>
>> Thanks Ola and Petri.
>>
>> Let's talk about use cases first.
>>
>> Go to market for ODP applications may be:
>>
>>- A product composed of software and hardware (typically a NEP approach
>>such as Nokia)
>>- A software to be installed by a system administrator of an enterprise
>>- A "service" to be part of a cloud offering (say an AWS image)
>>- A VNF to be deployed on a wide variety, apriori unknown, of hardware
>>as a VM
>>- An image to be deployed on bare metal clouds (packet.net or OVH for
>>instance) with hardware diversity
>>
>> As a result, an ODP application may be :
>>
>>1. Deployed as a single installed image and instantiated in different
>>virtualized or bare metal clouds
>>2. A VM is live migrated between two asymetric compute nodes
>>3. Installed on a specific machine
>>4. Deployed as an image that is to be instantiated on a single hardware
>>platform
>>
>> Irrespective of commercial Linux distribution acceptance, case 3 and 4 can
>> accommodate a static deployment paradigm where the hardware dependent
>> package is selected at installation time. Those cases corresponds to a
>> system integrator, an network equipment provider that builds a product for
>> a specific hardware platform.
>>
>> On the other hand, case 1 and 2 need a run time adaptation of the
>> framework. Case 2 may in fact be more between platform of the same type but
>> with different PLUGGED NICs and accelerators. While technically feasible
>> (yet very complex), I don't expect to deal with live migration between
>> Cavium and NXP or even Cavium ThunderX and Cavium ThunderX/2.
>> So case 1 is essentially addressing the needs of ISVs that do NOT sell a
>> bundle of software and hardware as a product. You can call it software
>> appliance.
>>
>> Ola, on the Xorg thing: yes it says that xorg.conf is now determined at
>> runtime... But if you concretely experience changing graphics card, or
>> supporting both CPU integrated graphics in additional to external GPU, you
>> will face trouble and find a lot of literature about achieving the results
>> or recovering from depressive situations...
>>
>>
>> The modular framework allows one ODP implementation to be considered as a
>> single module and loaded at runtime to solve case 1, 3 and 4. Those modules
>> may still be deployed as separate packages. The initial idea was to split
>> the implementation in more modules but it may not make that much sense
>> after giving more thoughts. Additional native drivers and the DDF itself
>> may be considered as separate modules and also distributed as separate
>> packages.
>> So we would have:
>> - odp-core
>> - odp-linux required module that provides AF packet and other packetios;
>> depends on odp-core
>> - odp-ddf optional module that provides dynamic pluggable hardware support;
>> depends on odp-core
>> - odp- optional modules for the various native NIC support; depends on
>> odp-ddf
>> - odp- optional modules to deal with SoC specific arch (ThunderX,
>> ThunderX/2, DPAA2...); depends on odp-core
>>
>> The odp- is derived from the current native SoC implementation
>> but need to leverage odp-mbuf and the new mempool facilities to allow
>> diversity of packetio to livetogether in a single platform, the rest is
>> entirely proprietary.
>>
>> The static and dynamic approaches are not mutually exclusive. I highly
>> recommend that the static (case 3 and 4) approach is driven by individual
>> members should they need it while we collectively solve the broader cloud
>> (case 1) deployment.
>>
>> Cheers
>>
>> FF
>>
>> On 3 October 2017 at 10:12, Savolainen, Petri (Nokia - FI/Espoo) <
>> 

Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

Great questions, Maxim.

What we mean by discovery is anything that isn't known or preconfigured at
compile time. In the case of embedded applications they can typically be
compiled for a specific target platform that has known characteristics.
Moving to another platform means recompiling the application. A VNF, by
contrast, does not know in advance where it will be run and is expected to
be compiled once and have that binary be runnable on any platform that
matches the ABI it's using.

Historically, general applications designed to run "anywhere" used only
generic services (e.g., sockets for I/O, OpenSSL for crypto, etc.). However
the promise of ODP is that applications can be portable at either a source
or binary level and still be able to exploit platform-specific
acceleration. So odp_packet_alloc() may use software when run on one
platform and a hardware packet manager when run on another without any
change required on the part of the application binary.

So the idea is that ODP APIs can be either statically bound and optimized
to specific implementations (the embedded model) or indirectly bound to
achieve ABI portability. We have that today with
--enable_abi_compat=[yes|no], so this is nothing new, but today we assume
that each platform is using a platform-specific odplib.so that the
application is run against.

What we want is an application to be compiled on any platform supporting
the ODP API and be runnable anywhere using the (standard) odplib.so that
RedHat or another distribution provides. So this means that rather than
assuming odplib.so has all the built-in platform-specific optimizations it
rather consists of the "ODP core" that can dynamically determine that it is
running on Vendor X, Model Y, and adapt accordingly to use that specific
platform's native capabilities.

That's the goal of the modular framework. How this will work in practice is
still has details to be worked out, but the basic idea is:

When an application calls odp_init_global() to bring up an ODP instance, a
determination is made as to the specific environment this ODP instance will
be running in. Once this determination is made (exact means TBD) the ODP
core library binds the ODP APIs to their optimized implementations for this
platform. These may either be part of the ODP core itself, if they were
included as part of the ODP git repo, or dynamically loaded from packages
distributed separately by the vendor using a standard naming scheme used by
all platforms that wish to participate in this framework. Once this
one-time process is finished, the result is an ODP application that is
running in --enable-abi_compat=yes mode the same as today. For APIs for
which there is no platform-specific optimized version then we will provide
today's linux-generic software implementation of those APIs as these are
part of the ODP core library.

This same process is repeated on smaller scale when odp_pktio_open() calls
are made to connect to an I/O interface. The name string passed to
odp_pktio_open() will follow a standard scheme that will allow ODP to
locate a device driver that provides the odp_pktio_xxx() APIs for this
device. Again these drivers may either be linked into the ODP core library
itself or be dynamically loaded.

With that as background, see answers to your specific questions inline.


On Tue, Oct 3, 2017 at 8:51 AM, Francois Ozog 
wrote:

> Hi Maxim,
>
> Modularization is configurable so that the produced output can be either:
> - runtime selection of modules based on whatever discovery mechanism is
> available
> - fixed compilation of a set of modules
>
> As per the discovery, I would favor a similar approach to packetio: give
> an opportunity to each module to say if it is appropriate for the
> environment. This avoids a standardized way to detect platform which may
> not even exist:
> - A thunderX module may check for PCI bus existence, and if yes certain
> PCI entries, or any other method (devicetree? ACPI?)
> - A DPAA2 may check for DPAA2 bus existence and particular objects for
> each board, or any other method (devicetree? ACPI?)
>
>
> FF
>
>
> On 3 October 2017 at 15:33, Maxim Uvarov  wrote:
>
>>
>>
>> On 3 October 2017 at 15:59, Bill Fischofer 
>> wrote:
>>
>>> Good summary. The key is that RedHat and others want:
>>>
>>> 1. They build the distribution from source we provide, we don't get to
>>> provide any binaries
>>> 2. There is a single distribution they will support per-ISA (e.g.,
>>> AArch64)
>>>
>>> The modular framework is designed to accommodate these requirements by
>>> allowing a "universal core" to discover the microarchitecture at run time
>>> and the most appropriate pluggable modules to use to exploit that
>>> microarchitecture's acceleration capabilities. These modules may be
>>> precompiled along with the core if they are part of the single ODP
>>> distribution, or they may be packaged and distributed separately as the

Re: [lng-odp] generic core + HW specific drivers

[Andriy Berestovskyy]

Hey,
Please see below.

On 03.10.2017 10:12, Savolainen, Petri (Nokia - FI/Espoo) wrote:
So, we should be able to deliver ODP as a set of HW independent and 
HW specific packages (libraries). For example, minimal install would
 include only odp, odp-linux and odp-test-suite, but when on arm64 
(and especially when on ThunderX) odp-thunderx would be installed


There are architecture dependencies (i.e. i386, amd64, arm64 etc), but 
there are no specific platform dependencies (i.e. Cavium ThunderX, 
Cavium Octeon, NXP etc).


In other words, there is no such mechanism in packaging to create a 
package odp, which will automatically install package odp-thunderx only 
on Cavium ThunderX platforms.




Package:
* odp * depends on: odp-linux
* odp-linux * depends on: odp

> * odp-thunderx [arm64] * depends on: odp

So installing odp-thunderx we will end up with odp, odp-linux and 
odp-thunderx, so still we have switch runtime between odp-linux and 
odp-thunderx...



All other projects you are mentioning (kernel, DPDK, Xorg) use
architecture dependency (different packages for different architectures) 
combined with run time configuration/probing. A kernel driver might be 
installed, but it will be unused until configured/probed.


To support multiple platforms, runtime configuration/probing is 
inevitable. The real question is who does this probing: ODP itself or 
each application independently. To avoid code duplication, ODP looks 
like a better choice...



Andriy

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

Hi Maxim,

Modularization is configurable so that the produced output can be either:
- runtime selection of modules based on whatever discovery mechanism is
available
- fixed compilation of a set of modules

As per the discovery, I would favor a similar approach to packetio: give an
opportunity to each module to say if it is appropriate for the environment.
This avoids a standardized way to detect platform which may not even exist:
- A thunderX module may check for PCI bus existence, and if yes certain PCI
entries, or any other method (devicetree? ACPI?)
- A DPAA2 may check for DPAA2 bus existence and particular objects for each
board, or any other method (devicetree? ACPI?)


FF


On 3 October 2017 at 15:33, Maxim Uvarov  wrote:

>
>
> On 3 October 2017 at 15:59, Bill Fischofer 
> wrote:
>
>> Good summary. The key is that RedHat and others want:
>>
>> 1. They build the distribution from source we provide, we don't get to
>> provide any binaries
>> 2. There is a single distribution they will support per-ISA (e.g.,
>> AArch64)
>>
>> The modular framework is designed to accommodate these requirements by
>> allowing a "universal core" to discover the microarchitecture at run time
>> and the most appropriate pluggable modules to use to exploit that
>> microarchitecture's acceleration capabilities. These modules may be
>> precompiled along with the core if they are part of the single ODP
>> distribution, or they may be packaged and distributed separately as the
>> supplier of these modules wishes.
>>
>> At the same time, this universal core can be statically linked for a
>> specific target platform to accommodate the needs of embedded
>> applications.
>> In this case the discovery and call-indirection goes away so there should
>> be no more overhead than exists in today's ODP when switching between
>> --enable-abi-compat=[yes|no]
>>
>>
> I have nothing to object about modularization components in linux-gen but
> can we be more consistent. Or we speak
> about runtime discovery or we speak about configuration files. I hear one
> day people say about discovery, next day
> about configuration files.
> Does somebody have understanding how that discovery will work? How odp in
> guest will understand during discovery what
> to use? Scan PCI devices or some drivers? With drivers that is mode clear
> as with other odp components.
>
> I think that people more afraid that changes to current master will bring
> side affects as more complexity and less performance.
> Maintain new work in separate branch is complex but I think we need to
> define requirements when code can be merged to master.
> These requirements from my side can be:
> - no performance degradation according to current code;
> - feature completeness (which means module framework works, we can change
> scheduler, do discovery at least some platforms,
> some pktio from module ddf works);
> - code is formed as clean patches on top of current master and passes
> merging review (I'm not sure how many people review current cloud-dev
> branch work);
> - at least several platforms are merged together with that framework to
> show it's effectiveness;
>
> In my understanding if all 4 items are met nobody will have objections.
>
> Other thing is might be shift priorities a little bit. Instead of changing
> everything to modules, change one or two things, merge second platform and
> make it work. Then send clean patches for review.
>
> Any thoughts on that?
>
> Thank you,
> Maxim.
>
>
>
>> On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog 
>> wrote:
>>
>> > Thanks Ola and Petri.
>> >
>> > Let's talk about use cases first.
>> >
>> > Go to market for ODP applications may be:
>> >
>> >- A product composed of software and hardware (typically a NEP
>> approach
>> >such as Nokia)
>> >- A software to be installed by a system administrator of an
>> enterprise
>> >- A "service" to be part of a cloud offering (say an AWS image)
>> >- A VNF to be deployed on a wide variety, apriori unknown, of
>> hardware
>> >as a VM
>> >- An image to be deployed on bare metal clouds (packet.net or OVH
>> for
>> >instance) with hardware diversity
>> >
>> > As a result, an ODP application may be :
>> >
>> >1. Deployed as a single installed image and instantiated in different
>> >virtualized or bare metal clouds
>> >2. A VM is live migrated between two asymetric compute nodes
>> >3. Installed on a specific machine
>> >4. Deployed as an image that is to be instantiated on a single
>> hardware
>> >platform
>> >
>> > Irrespective of commercial Linux distribution acceptance, case 3 and 4
>> can
>> > accommodate a static deployment paradigm where the hardware dependent
>> > package is selected at installation time. Those cases corresponds to a
>> > system integrator, an network equipment provider that builds a product
>> for
>> > a specific hardware platform.
>> >
>> > On the 

Re: [lng-odp] generic core + HW specific drivers

[Maxim Uvarov]

On 3 October 2017 at 15:59, Bill Fischofer 
wrote:

> Good summary. The key is that RedHat and others want:
>
> 1. They build the distribution from source we provide, we don't get to
> provide any binaries
> 2. There is a single distribution they will support per-ISA (e.g., AArch64)
>
> The modular framework is designed to accommodate these requirements by
> allowing a "universal core" to discover the microarchitecture at run time
> and the most appropriate pluggable modules to use to exploit that
> microarchitecture's acceleration capabilities. These modules may be
> precompiled along with the core if they are part of the single ODP
> distribution, or they may be packaged and distributed separately as the
> supplier of these modules wishes.
>
> At the same time, this universal core can be statically linked for a
> specific target platform to accommodate the needs of embedded applications.
> In this case the discovery and call-indirection goes away so there should
> be no more overhead than exists in today's ODP when switching between
> --enable-abi-compat=[yes|no]
>
>
I have nothing to object about modularization components in linux-gen but
can we be more consistent. Or we speak
about runtime discovery or we speak about configuration files. I hear one
day people say about discovery, next day
about configuration files.
Does somebody have understanding how that discovery will work? How odp in
guest will understand during discovery what
to use? Scan PCI devices or some drivers? With drivers that is mode clear
as with other odp components.

I think that people more afraid that changes to current master will bring
side affects as more complexity and less performance.
Maintain new work in separate branch is complex but I think we need to
define requirements when code can be merged to master.
These requirements from my side can be:
- no performance degradation according to current code;
- feature completeness (which means module framework works, we can change
scheduler, do discovery at least some platforms,
some pktio from module ddf works);
- code is formed as clean patches on top of current master and passes
merging review (I'm not sure how many people review current cloud-dev
branch work);
- at least several platforms are merged together with that framework to
show it's effectiveness;

In my understanding if all 4 items are met nobody will have objections.

Other thing is might be shift priorities a little bit. Instead of changing
everything to modules, change one or two things, merge second platform and
make it work. Then send clean patches for review.

Any thoughts on that?

Thank you,
Maxim.



> On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog 
> wrote:
>
> > Thanks Ola and Petri.
> >
> > Let's talk about use cases first.
> >
> > Go to market for ODP applications may be:
> >
> >- A product composed of software and hardware (typically a NEP
> approach
> >such as Nokia)
> >- A software to be installed by a system administrator of an
> enterprise
> >- A "service" to be part of a cloud offering (say an AWS image)
> >- A VNF to be deployed on a wide variety, apriori unknown, of hardware
> >as a VM
> >- An image to be deployed on bare metal clouds (packet.net or OVH for
> >instance) with hardware diversity
> >
> > As a result, an ODP application may be :
> >
> >1. Deployed as a single installed image and instantiated in different
> >virtualized or bare metal clouds
> >2. A VM is live migrated between two asymetric compute nodes
> >3. Installed on a specific machine
> >4. Deployed as an image that is to be instantiated on a single
> hardware
> >platform
> >
> > Irrespective of commercial Linux distribution acceptance, case 3 and 4
> can
> > accommodate a static deployment paradigm where the hardware dependent
> > package is selected at installation time. Those cases corresponds to a
> > system integrator, an network equipment provider that builds a product
> for
> > a specific hardware platform.
> >
> > On the other hand, case 1 and 2 need a run time adaptation of the
> > framework. Case 2 may in fact be more between platform of the same type
> but
> > with different PLUGGED NICs and accelerators. While technically feasible
> > (yet very complex), I don't expect to deal with live migration between
> > Cavium and NXP or even Cavium ThunderX and Cavium ThunderX/2.
> > So case 1 is essentially addressing the needs of ISVs that do NOT sell a
> > bundle of software and hardware as a product. You can call it software
> > appliance.
> >
> > Ola, on the Xorg thing: yes it says that xorg.conf is now determined at
> > runtime... But if you concretely experience changing graphics card, or
> > supporting both CPU integrated graphics in additional to external GPU,
> you
> > will face trouble and find a lot of literature about achieving the
> results
> > or recovering from depressive situations...
> >
> >
> > The modular 

Re: [lng-odp] generic core + HW specific drivers

[Bill Fischofer]

Good summary. The key is that RedHat and others want:

1. They build the distribution from source we provide, we don't get to
provide any binaries
2. There is a single distribution they will support per-ISA (e.g., AArch64)

The modular framework is designed to accommodate these requirements by
allowing a "universal core" to discover the microarchitecture at run time
and the most appropriate pluggable modules to use to exploit that
microarchitecture's acceleration capabilities. These modules may be
precompiled along with the core if they are part of the single ODP
distribution, or they may be packaged and distributed separately as the
supplier of these modules wishes.

At the same time, this universal core can be statically linked for a
specific target platform to accommodate the needs of embedded applications.
In this case the discovery and call-indirection goes away so there should
be no more overhead than exists in today's ODP when switching between
--enable-abi-compat=[yes|no]

On Tue, Oct 3, 2017 at 5:12 AM, Francois Ozog 
wrote:

> Thanks Ola and Petri.
>
> Let's talk about use cases first.
>
> Go to market for ODP applications may be:
>
>- A product composed of software and hardware (typically a NEP approach
>such as Nokia)
>- A software to be installed by a system administrator of an enterprise
>- A "service" to be part of a cloud offering (say an AWS image)
>- A VNF to be deployed on a wide variety, apriori unknown, of hardware
>as a VM
>- An image to be deployed on bare metal clouds (packet.net or OVH for
>instance) with hardware diversity
>
> As a result, an ODP application may be :
>
>1. Deployed as a single installed image and instantiated in different
>virtualized or bare metal clouds
>2. A VM is live migrated between two asymetric compute nodes
>3. Installed on a specific machine
>4. Deployed as an image that is to be instantiated on a single hardware
>platform
>
> Irrespective of commercial Linux distribution acceptance, case 3 and 4 can
> accommodate a static deployment paradigm where the hardware dependent
> package is selected at installation time. Those cases corresponds to a
> system integrator, an network equipment provider that builds a product for
> a specific hardware platform.
>
> On the other hand, case 1 and 2 need a run time adaptation of the
> framework. Case 2 may in fact be more between platform of the same type but
> with different PLUGGED NICs and accelerators. While technically feasible
> (yet very complex), I don't expect to deal with live migration between
> Cavium and NXP or even Cavium ThunderX and Cavium ThunderX/2.
> So case 1 is essentially addressing the needs of ISVs that do NOT sell a
> bundle of software and hardware as a product. You can call it software
> appliance.
>
> Ola, on the Xorg thing: yes it says that xorg.conf is now determined at
> runtime... But if you concretely experience changing graphics card, or
> supporting both CPU integrated graphics in additional to external GPU, you
> will face trouble and find a lot of literature about achieving the results
> or recovering from depressive situations...
>
>
> The modular framework allows one ODP implementation to be considered as a
> single module and loaded at runtime to solve case 1, 3 and 4. Those modules
> may still be deployed as separate packages. The initial idea was to split
> the implementation in more modules but it may not make that much sense
> after giving more thoughts. Additional native drivers and the DDF itself
> may be considered as separate modules and also distributed as separate
> packages.
> So we would have:
> - odp-core
> - odp-linux required module that provides AF packet and other packetios;
> depends on odp-core
> - odp-ddf optional module that provides dynamic pluggable hardware support;
> depends on odp-core
> - odp- optional modules for the various native NIC support; depends on
> odp-ddf
> - odp- optional modules to deal with SoC specific arch (ThunderX,
> ThunderX/2, DPAA2...); depends on odp-core
>
> The odp- is derived from the current native SoC implementation
> but need to leverage odp-mbuf and the new mempool facilities to allow
> diversity of packetio to livetogether in a single platform, the rest is
> entirely proprietary.
>
> The static and dynamic approaches are not mutually exclusive. I highly
> recommend that the static (case 3 and 4) approach is driven by individual
> members should they need it while we collectively solve the broader cloud
> (case 1) deployment.
>
> Cheers
>
> FF
>
> On 3 October 2017 at 10:12, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
> > > -Original Message-
> > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Ola
> > > Liljedahl
> > > Sent: Friday, September 29, 2017 8:47 PM
> > > To: lng-odp@lists.linaro.org
> > > Subject: [lng-odp] generic core + HW specific drivers
> > >
> > > 

Re: [lng-odp] generic core + HW specific drivers

[Francois Ozog]

Thanks Ola and Petri.

Let's talk about use cases first.

Go to market for ODP applications may be:

   - A product composed of software and hardware (typically a NEP approach
   such as Nokia)
   - A software to be installed by a system administrator of an enterprise
   - A "service" to be part of a cloud offering (say an AWS image)
   - A VNF to be deployed on a wide variety, apriori unknown, of hardware
   as a VM
   - An image to be deployed on bare metal clouds (packet.net or OVH for
   instance) with hardware diversity

As a result, an ODP application may be :

   1. Deployed as a single installed image and instantiated in different
   virtualized or bare metal clouds
   2. A VM is live migrated between two asymetric compute nodes
   3. Installed on a specific machine
   4. Deployed as an image that is to be instantiated on a single hardware
   platform

Irrespective of commercial Linux distribution acceptance, case 3 and 4 can
accommodate a static deployment paradigm where the hardware dependent
package is selected at installation time. Those cases corresponds to a
system integrator, an network equipment provider that builds a product for
a specific hardware platform.

On the other hand, case 1 and 2 need a run time adaptation of the
framework. Case 2 may in fact be more between platform of the same type but
with different PLUGGED NICs and accelerators. While technically feasible
(yet very complex), I don't expect to deal with live migration between
Cavium and NXP or even Cavium ThunderX and Cavium ThunderX/2.
So case 1 is essentially addressing the needs of ISVs that do NOT sell a
bundle of software and hardware as a product. You can call it software
appliance.

Ola, on the Xorg thing: yes it says that xorg.conf is now determined at
runtime... But if you concretely experience changing graphics card, or
supporting both CPU integrated graphics in additional to external GPU, you
will face trouble and find a lot of literature about achieving the results
or recovering from depressive situations...


The modular framework allows one ODP implementation to be considered as a
single module and loaded at runtime to solve case 1, 3 and 4. Those modules
may still be deployed as separate packages. The initial idea was to split
the implementation in more modules but it may not make that much sense
after giving more thoughts. Additional native drivers and the DDF itself
may be considered as separate modules and also distributed as separate
packages.
So we would have:
- odp-core
- odp-linux required module that provides AF packet and other packetios;
depends on odp-core
- odp-ddf optional module that provides dynamic pluggable hardware support;
depends on odp-core
- odp- optional modules for the various native NIC support; depends on
odp-ddf
- odp- optional modules to deal with SoC specific arch (ThunderX,
ThunderX/2, DPAA2...); depends on odp-core

The odp- is derived from the current native SoC implementation
but need to leverage odp-mbuf and the new mempool facilities to allow
diversity of packetio to livetogether in a single platform, the rest is
entirely proprietary.

The static and dynamic approaches are not mutually exclusive. I highly
recommend that the static (case 3 and 4) approach is driven by individual
members should they need it while we collectively solve the broader cloud
(case 1) deployment.

Cheers

FF

On 3 October 2017 at 10:12, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola
> > Liljedahl
> > Sent: Friday, September 29, 2017 8:47 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] generic core + HW specific drivers
> >
> > olli@vubuntu:~$ dpkg --get-selections | grep xorg
> > xorg install
> > xorg-docs-core install
> > xserver-xorg install
> > xserver-xorg-core install
> > xserver-xorg-input-all install
> > xserver-xorg-input-evdev install
> > xserver-xorg-input-libinput install
> > xserver-xorg-input-synaptics install
> > xserver-xorg-input-wacom install
> > xserver-xorg-video-all install
> > xserver-xorg-video-amdgpu install
> > xserver-xorg-video-ati install
> > xserver-xorg-video-fbdev install
> > xserver-xorg-video-intel install
> > xserver-xorg-video-mach64 install
> > xserver-xorg-video-neomagic install
> > xserver-xorg-video-nouveau install<< > xserver-xorg-video-openchrome install
> > xserver-xorg-video-qxl install
> > xserver-xorg-video-r128 install
> > xserver-xorg-video-radeon install .   << > xserver-xorg-video-savage install
> > xserver-xorg-video-siliconmotion install
> > xserver-xorg-video-sisusb install
> > xserver-xorg-video-tdfx install
> > xserver-xorg-video-trident install
> > xserver-xorg-video-vesa install
> > xserver-xorg-video-vmware install .   << >
> > So let's rename ODP Cloud to ODP Core.
> >
> > -- Ola
>
>
> DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk)
> include many HW dependent packages
>
> 

Re: [lng-odp] generic core + HW specific drivers

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Ola
> Liljedahl
> Sent: Friday, September 29, 2017 8:47 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] generic core + HW specific drivers
> 
> olli@vubuntu:~$ dpkg --get-selections | grep xorg
> xorg install
> xorg-docs-core install
> xserver-xorg install
> xserver-xorg-core install
> xserver-xorg-input-all install
> xserver-xorg-input-evdev install
> xserver-xorg-input-libinput install
> xserver-xorg-input-synaptics install
> xserver-xorg-input-wacom install
> xserver-xorg-video-all install
> xserver-xorg-video-amdgpu install
> xserver-xorg-video-ati install
> xserver-xorg-video-fbdev install
> xserver-xorg-video-intel install
> xserver-xorg-video-mach64 install
> xserver-xorg-video-neomagic install
> xserver-xorg-video-nouveau install<< xserver-xorg-video-openchrome install
> xserver-xorg-video-qxl install
> xserver-xorg-video-r128 install
> xserver-xorg-video-radeon install .   << xserver-xorg-video-savage install
> xserver-xorg-video-siliconmotion install
> xserver-xorg-video-sisusb install
> xserver-xorg-video-tdfx install
> xserver-xorg-video-trident install
> xserver-xorg-video-vesa install
> xserver-xorg-video-vmware install .   << 
> So let's rename ODP Cloud to ODP Core.
> 
> -- Ola


DPDK packages in Ubuntu 17.05 (https://packages.ubuntu.com/artful/dpdk) include 
many HW dependent packages 

...
librte-pmd-fm10k17.05 (= 17.05.2-0ubuntu1) [amd64, i386]  <<< Intel Red Rock 
Canyon net driver, provided only for x86
librte-pmd-i40e17.05 (= 17.05.2-0ubuntu1)
librte-pmd-ixgbe17.05 (= 17.05.2-0ubuntu1) [not ppc64el]
librte-pmd-kni17.05 (= 17.05.2-0ubuntu1) [not i386]
librte-pmd-lio17.05 (= 17.05.2-0ubuntu1)
librte-pmd-nfp17.05 (= 17.05.2-0ubuntu1)
librte-pmd-null-crypto17.05 (= 17.05.2-0ubuntu1)
librte-pmd-null17.05 (= 17.05.2-0ubuntu1)
librte-pmd-octeontx-ssovf17.05 (= 17.05.2-0ubuntu1)   <<< OcteonTX SSO eventdev 
driver files as a package
librte-pmd-pcap17.05 (= 17.05.2-0ubuntu1)
librte-pmd-qede17.05 (= 17.05.2-0ubuntu1)
librte-pmd-ring17.05 (= 17.05.2-0ubuntu1)
librte-pmd-sfc-efx17.05 (= 17.05.2-0ubuntu1) [amd64]
librte-pmd-skeleton-event17.05 (= 17.05.2-0ubuntu1)
librte-pmd-sw-event17.05 (= 17.05.2-0ubuntu1)
librte-pmd-tap17.05 (= 17.05.2-0ubuntu1)
librte-pmd-thunderx-nicvf17.05 (= 17.05.2-0ubuntu1)  <<< ThunderX net driver 
files as a package
...


So, we should be able to deliver ODP as a set of HW independent and HW specific 
packages (libraries). For example, minimal install would include only odp, 
odp-linux and odp-test-suite, but when on arm64 (and especially when on 
ThunderX) odp-thunderx would be installed also. The trick would be how to 
select odp-thunderx installed files (also headers) as default when application 
is built or run on ThunderX (and not on another arm64).

Package:
* odp (only generic folders and documentation, no implementation)
  * depends on: odp-linux, odp-test-suite
  * recommends: odp-linux, odp-dpdk, odp-thunderx, odp-dpaa2, ...
* odp-linux
  * depends on: odp, openssl
  * recommends: dpdk, netmap, ...
* odp-dpdk
  * depends on: odp, dpdk
* odp-thunderx [arm64]
  * depends on: odp, ...
* odp-test-suite
  * depends on: odp


-Petri