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, another
1.5 slides to cover and the last slide is about few changes Jianbo has
identified.
I expect that, after this discussion, we will identify what are the
gaps, which parts can we let go.
Thank you,
Honnappa
On 26 October 2017 at 16:34, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> I agree with Maxim. Best to get one or two working drivers and see what else
> is needed. The intent here is not for ODP to become another OS, so I'm not
> sure why we need to concern ourselves with bus walking and similar arcana.
> Linux has already long solved this problem. We should leverage what's there,
> not try to reinvent it.
>
> ODP applications are told what I/O interfaces to use, either through an
> application configuration file, command line, or other means outside the
> scope of ODP itself. ODP's job is simply to connect applications to these
> configured I/O interfaces when they call odp_pktio_open(). The name used for
> interfaces is simply a string that we've defined to have the format:
>
> class: device: other-info-needed-by-driver
>
> We've defined a number of classes already:
>
> - loop
> - pcap
> - ipc
> - dpdk
> - socket
> - socket_mmap
> - tap
> etc.
>
> We simply need to define new classes (e.g., ddf, mdev) and the names they
> need to take to identify a specific device and the associated driver to use
> for operate that device. The driver is then loaded if necessary and its
> open() interface is called.
>
> On Thu, Oct 26, 2017 at 3:59 PM, Maxim Uvarov <maxim.uva...@linaro.org>
> wrote:
>>
>> Hello Honnappa,
>>
>> I think we also need to take a look from bottom. I.e. from exact drivers
>> to
>> implement. That it will be more clear which interface is needed to be
>> created.
>> Do you have some list of drivers which needed to be implemented? I.e. with
>> pci drivers I think we in a good way, but non pci drivers are under
>> question.
>> I think we should not over-complicate odp itself with huge discovery and
>> numeration of devices. Let's take a look what is the minimal interface to
>> support
>> devices.
>>
>> Best regards,
>> Maxim.
>>
>> On 26 October 2017 at 23:35, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> wrote:
>>
>> > Hi,
>> > Agree, we have taken 2 hours and the progress has been slow. But
>> > the discussions have been good and helpful to us at Arm. The goal is
>> > to identify the gaps and work items. I am not sure if it has been
>> > helpful to others, please let me know.
>> >
>> > To speed this up, I propose few options below, let me know your opinion:
>> >
>> > 1) Have 2 additional (along with regular ODP 2.0) calls next week - We
>> > can do Tuesday 7:00am and then another on Thursday 7:00am (Austin, TX
>> > time, GMT-6, one hour before the regular ODP-2.0)
>> >
>> > 2) Resolve the pending PRs on emails
>> >
>> > 3) Discuss the DDF slides on email - Not sure how effective it will be
>> >
>> > Any other solutions?
>> >
>> > Thank you,
>> > Honnappa
>> >
>
>
