Yes, I saw that and agree. Suggest we leave things as is for ODP v1.0 since
it's not a production target and take this as a follow-on work item for
next year to figure out an optimal solution for this problem.
Given the typedef presence this means that other platforms will copy the
linux-generic A
On Tue, Nov 4, 2014 at 7:27 PM, Taras Kondratiuk
wrote:
> On 11/04/2014 04:29 PM, Ciprian Barbu wrote:
>>
>> Here is a first attempt to remove inlines from API files. I also moved
>> some
>> defines and typedefs out of some of the API headers. There is still room
>> for
>> improvement I guess, the
The following commits changed the master branch of DPDK:
http://dpdk.org/browse/dpdk/commit/?id=7869536f
http://dpdk.org/browse/dpdk/commit/?id=ca04aaea
http://dpdk.org/browse/dpdk/commit/?id=08b563ff
http://dpdk.org/browse/dpdk/commit/?id=ea672a8b
http://dpdk.org/browse/dpdk/commit/?id=9aaccf1a
h
If the ODP prototypes simply all said 'static inline' then would that
permit the implementation to choose later which were actually static inline?
I.e., if the common odp_xxx.h says
static inline void *odp_foo(...);
Then can the implementation can say;
static inline void *odp_foo(...) { };
to
On 11/04/2014 07:24 PM, Bill Fischofer wrote:
These files simply describe the APIs, their parameters, and expected
behaviors. As such they are implementation-independent. The only
implementation-specific things in them are the typedef definitions,
which is what we were discussing moving. The s
It's unfortunate that C (and GCC) have these inlining limitations. This,
BTW, is exactly the sort of thing that LLVM was designed to handle--and
without requiring the programmer to decide in advance which functions
should and should not be inlined.
We could wrapper the independent APIs in macros
On 11/04/2014 04:29 PM, Ciprian Barbu wrote:
Here is a first attempt to remove inlines from API files. I also moved some
defines and typedefs out of some of the API headers. There is still room for
improvement I guess, the inline implementation and defines could be split into
their own files, but
These files simply describe the APIs, their parameters, and expected
behaviors. As such they are implementation-independent. The only
implementation-specific things in them are the typedef definitions, which
is what we were discussing moving. The sequence of #includes should be:
Application
Sorry, please ignore. The calendar in Mac Mail did not give me an option to not
send this email when I moved it :-(
> On Nov 4, 2014, at 11:02 AM, Wiles, Roger Keith
> wrote:
>
> Wiles, Roger Keith has updated the event: Weekly ODP Design Discussion Call,
> scheduled for July 15, 2014 at 10:0
On Tue, Nov 4, 2014 at 3:45 PM, Bill Fischofer
wrote:
> Please take a look at the RFC patches I circulated for odp_buffer.h,
> odp_buffer_pool.h, and odp_packet.h. These now serve as both executables
> and doxygen source so the information is in one place.
Ok, I saw the two patches, but after se
Wiles, Roger Keith has updated the event: Weekly ODP Design Discussion Call,
scheduled for July 15, 2014 at 10:00 AM (US/Central). To acknowledge this
invitation, click the link below.
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
METHOD:REQUEST
PRODID:-//Apple Inc.//Mac OS X 10.10//EN
BEGIN:
Summary of today's ODP call. Again, I apologize for the time zone
confusion. This call occurs at 15:00 UTC on Tuesdays. If you reside in a
time zone that observes summer time then this call will move relative to
local time as you move between summer and winter times. The US moved off
summer time
We we want to call everything we've documented mandatory in v1.0 I'm OK
with that. What I don't want is for us to say that and then as we approach
end of year someone says "but I really can't do (formerly optional) feature
X".
Quick poll: Are there any APIs currently marked optional that anyone d
Since odp_schedule_skip_order has dest queue, So how its differ from
odp_queue_enque() as
en-queue is going to release it implicitly.
Jerin.
From: lng-odp-boun...@lists.linaro.org on
behalf of Alexandru Badicioiu
Sent: Friday, October 31, 2014 6:40 PM
To:
True, but maybe there is a middle way -
What if instead of a mad matrix of optional features we have 2 or 3 levels of
features?
Say:
ODP Basic support - all mandatory features are supported.
ODP Full support - mandatory + all what we now call optional features are
supported.
And maybe, if it mak
I did express the same in the past and agree with Petri
'“optional” is next to non-existent'. It creates fragmentation
that we don't need. When I need to figure out what optional
pieces implemented by specific ODP implementation and
how to match one that not implemented from that point
it is not ve
I don't think it can use the first fragment place in the order. It can use the
last fragment to arrive place in the queue.
Otherwise you have to stop forwarding until all fragments arrive to keep the
order… no?
Gilad Ben-Yossef
Software Architect
EZchip Technologies Ltd.
37 Israel Pollak Ave, K
Do we still worry about Petri's comment? Right now
platform/linux-generic/include/api/odp_byteorder.h includes endian.h.
Anyway that should be the subject of a different patch so I think this
can go in.
On Mon, Nov 3, 2014 at 10:53 PM, Mike Holmes wrote:
> API headers should not include C std lib
On Mon, Nov 3, 2014 at 8:23 PM, Mike Holmes wrote:
> ping
>
> On 30 October 2014 18:17, Mike Holmes wrote:
>>
>> tot is = i which cannot leave the for loop without being positive
>> unless it exits entirely and never reaches the test statement.
>> Or QUEUE_ROUNDS is #defined to 0 rather than (512
Hello Venky,
We've been looking at some of the OVS cards we have and the subject of
testing OVS on top of ODP on top of DPDK came up. Last time I worked
on this I modified odp_init_dpdk with hardcoded values but we need to
solve this problem in the near future. Mike pushed a patch that allows
appl
Here is a first attempt to remove inlines from API files. I also moved some
defines and typedefs out of some of the API headers. There is still room for
improvement I guess, the inline implementation and defines could be split into
their own files, but I just tried to show the general idea.
I also
In addition to skip order function I think we need to handle the case when
a packet gets fragmented (e.g. IP fragmentation). In this case the
fragments should share the original sequence number and the order
restoration logic should be aware when the last fragment occurs.
Alex
On 3 November 2014
Please take a look at the RFC patches I circulated for odp_buffer.h,
odp_buffer_pool.h, and odp_packet.h. These now serve as both executables
and doxygen source so the information is in one place.
The split discussion refers to where the platform-specific typedefs are
defined + the question of ho
That's precisely why we've said that all implementations must provide at
least stubs for all of the ODP APIs (even those marked optional). Not
every ODP application will be able to run on every ODP implementation, but
that's OK. You don't need your home office router to have enterprise-level
feat
I’m concerned that the API gets too fragmented already in v1.0 and the
ecosystem will be limited by that. For example, it’s hard to integrate 3rd
party (or open source) SW into a system, if my app uses optional feature X, the
3rd party lib uses optional feature Y and the implementation provides
I think the criteria I outlined above for considering an API optional are
reasonable. Recall that the reason certain APIs are designated as optional
is because we received feedback that they were not feasible on specific
platforms. It's RECOMMENDED that platforms provide all of these APIs,
howeve
On Mon, Nov 3, 2014 at 5:47 PM, Taras Kondratiuk
wrote:
> A need to split out a clean API headers is being discussed again, so
> pulling this thread up to remind what the previous attempt was.
>
> On 07/08/2014 05:55 PM, Mike Holmes wrote:
>> We discussed this on a hangout, here are the results as
Hi,
As noted many times before, “optional” is next to non-existent for application
programmers – especially if it’s important to achieve application portability.
I’d suggest that API v1.0 would not have anything labeled as optional. It’s
simplifies the API for everybody (implementers/testers/u
On Tue, Nov 04, 2014 at 07:02:47PM +0800, yan.songm...@linaro.org wrote:
> Hi jacob,
> A) return number of buffers
> The odp_queue_deq_multi do return the number of buffer but the
> odp_queue_enq_multi is not.
Correct. But test case should honor the
return value(number of buffers dequeued) from
Hi jacob,
A) return number of buffers
The odp_queue_deq_multi do return the number of buffer but the
odp_queue_enq_multi is not.
I think odp_queue_enq_multi is need to return the number of buffers too,
because there is a limit of eight.
When the user enqueue ten, in fact just eight buffe
Mike,
In fact i never use checkpatch before. I will use it from now on.
This two internal function is not include ,because i just test the base queue
type.
As you said, i think this two function will be include in the odp_packet_io
tests or the deep test in queue later.
yan.songm...@li
On 11/04/2014 10:48 AM, Shmulik Ladkani wrote:
Hi,
I don't have a big picture of what you are trying to achieve, but ODP
is not a framework for thread-local initialization of 3rd party
libraries.
I completely agree.
However my usecase is an exception, as I was trying to create a C++
binding
I'd add to this if the reason for using a non-ODP API is that the
equivalent ODP API is missing something we'd like to know about that so
that may be corrected in a future revision of the API. Over time I'd
expect the ODP APIs to gain richness both as the framework matures and as
it tracks the inc
I think this is an important discussion so I've added it to the agenda for
today's ODP call. Please see my earlier note regarding the time of the
call. Its remains at 15:00 UTC.
Gilad's point is correct. While ODP uses the term 'thread' (at least for
v1.0), 'task' is probably a better term sinc
Apologies for the late notice, but I realized that although we've stated
that this call is scheduled for 15:00 UTC, it was mistakenly put into the
Google calendar in a US timezone that's affected by daylight savings time.
That's now been corrected and the call is indeed now scheduled for 15:00
UTC.
You are aware that there is no assumption in ODP that the different ODP tasks
are threads, right?
Gilad
Gilad Ben-Yossef
Software Architect
EZchip Technologies Ltd.
37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel
Tel: +972-4-959- ext. 576, Fax: +972-8-681-1483
Mobile: +972-52-826-0388, US Mo
I think it's fair to note though that applications that uses any API outside
ODP may not be portable across other ODP platforms, or even exhibit different
performance characteristic from ODP APIs on the same platform.
Therefore I expect that *all other things being equal*, there is an advantage
Hi,
> I don't have a big picture of what you are trying to achieve, but ODP
> is not a framework for thread-local initialization of 3rd party
> libraries.
I completely agree.
However my usecase is an exception, as I was trying to create a C++
binding for ODP - hence it isn't just a "different" l
38 matches
Mail list logo
