Re: [lng-odp] DDF discussions taking time

here is the code snippet I promised: /* = */ /* Code snipets */ /* --- */ /* enumerator stuf */ /* PCI enumerator module */ pci_enumerator_class_init { enumclass_register("pci"...); Browse /sys/bus/pci to create pci_enumerators for each

Re: [lng-odp] DDF discussions taking time

On Fri, Oct 27, 2017 at 4:54 PM, Francois Ozog wrote: > > Le ven. 27 oct. 2017 à 23:51, Bill Fischofer > a écrit : > >> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog >> wrote: >> >>> >>> Le ven. 27 oct. 2017 à

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:54, Francois Ozog a écrit : > Le ven. 27 oct. 2017 à 23:51, Bill Fischofer > a écrit : > >> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog >> wrote: >> >>> >>> Le ven. 27 oct. 2017 à 23:05,

Re: [lng-odp] DDF discussions taking time

On Fri, Oct 27, 2017 at 3:43 PM, Francois Ozog wrote: > > Le ven. 27 oct. 2017 à 20:35, Bill Fischofer > a écrit : > >> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote: >> >>> >>> Le ven. 27 oct. 2017 à

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:51, Bill Fischofer a écrit : > On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog > wrote: > >> >> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli < >> honnappa.nagaraha...@linaro.org> a écrit : >> >>> On 27 October

Re: [lng-odp] DDF discussions taking time

On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog wrote: > > Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli < > honnappa.nagaraha...@linaro.org> a écrit : > >> On 27 October 2017 at 13:35, Bill Fischofer >> wrote: >> >>> >>> >>> On Fri, Oct

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit : > On 27 October 2017 at 13:35, Bill Fischofer > wrote: > >> >> >> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote: >> >>> >>> Le ven. 27

Re: [lng-odp] DDF discussions taking time

On 27 October 2017 at 13:35, Bill Fischofer wrote: > > > On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > wrote: > >> >> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer >> a écrit : >> >>> The problem with scanning,

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 20:35, Bill Fischofer a écrit : > On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > wrote: > >> >> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer >> a écrit : >> >>> The problem with scanning,

Re: [lng-odp] DDF discussions taking time

On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog wrote: > > Le ven. 27 oct. 2017 à 17:17, Bill Fischofer > a écrit : > >> The problem with scanning, especially in a VNF environment, is that (a) >> the application probably isn't authorized to

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 17:31, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> a écrit : > On 27 October 2017 at 02:36, Francois Ozog > wrote: > >> Well, we do not need to scan all the platform because the pktio_open >> contains enough information to target the

Re: [lng-odp] DDF discussions taking time

Le ven. 27 oct. 2017 à 17:17, Bill Fischofer a écrit : > The problem with scanning, especially in a VNF environment, is that (a) > the application probably isn't authorized to to that > nothing prevents scanning what is available for n the vm. "Scale up" Events are

Re: [lng-odp] DDF discussions taking time

On 27 October 2017 at 02:36, Francois Ozog wrote: > Well, we do not need to scan all the platform because the pktio_open > contains enough information to target the right device. > This is almost true as we need to have an additional "selector" for the > port on

Re: [lng-odp] DDF discussions taking time

The problem with scanning, especially in a VNF environment, is that (a) the application probably isn't authorized to to that and (b) the application certainly doesn't have real visibility into what the actual device topology is. It only knows what it "needs to know" (as determined by higher-level

Re: [lng-odp] DDF discussions taking time

On 27 October 2017 at 09:50, Bill Fischofer wrote: > ODP 2.0 assumes Linux system services are available so the question of how > to operate in bare metal environments is a separate one and up to those ODP > implementations. Again the application will provide a >

Re: [lng-odp] DDF discussions taking time

ODP 2.0 assumes Linux system services are available so the question of how to operate in bare metal environments is a separate one and up to those ODP implementations. Again the application will provide a sufficiently-qualified device name string to identify which device it wants to open in an

Re: [lng-odp] DDF discussions taking time

Well, we do not need to scan all the platform because the pktio_open contains enough information to target the right device. This is almost true as we need to have an additional "selector" for the port on multiport NICs that are controlled by a single pci ID. :: or something like that. All ports

Re: [lng-odp] DDF discussions taking time

On 26 October 2017 at 16:34, Bill Fischofer wrote: > I agree with Maxim. Best to get one or two working drivers and see what else > is needed. The intent here is not for ODP to become another OS, so I'm not > sure why we need to concern ourselves with bus walking and

Re: [lng-odp] DDF discussions taking time

Hi Bill/Maxim, These are the exact decisions I wanted us to make coming out of this discussion. I have taken some what of a longer route, i.e. examine the DDF design and understand the idea/thinking on why somethings were created. We are almost there, we do not have many more slides to cover,

Re: [lng-odp] DDF discussions taking time

I agree with Maxim. Best to get one or two working drivers and see what else is needed. The intent here is not for ODP to become another OS, so I'm not sure why we need to concern ourselves with bus walking and similar arcana. Linux has already long solved this problem. We should leverage what's

Re: [lng-odp] DDF discussions taking time

Hello Honnappa, I think we also need to take a look from bottom. I.e. from exact drivers to implement. That it will be more clear which interface is needed to be created. Do you have some list of drivers which needed to be implemented? I.e. with pci drivers I think we in a good way, but non pci