On 09/03/15 09:29, Nicolas Morey-Chaisemartin wrote:
Just a question a bit beside the point:
What is the policy about API-NEXT?
I was very surprised to see that the api-next branch was merged to master just
a few commits before the release.
I would have expected it to be merge right after v1.3.
Just a question a bit beside the point:
What is the policy about API-NEXT?
I was very surprised to see that the api-next branch was merged to master just
a few commits before the release.
I would have expected it to be merge right after v1.3.0.0 tag so we have a
fairly tested master being releas
On 03.09.15 09:20, Nicolas Morey-Chaisemartin wrote:
On 09/02/2015 11:16 PM, Ivan Khoronzhuk wrote:
On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
On 26.08.15 18:22, Stuart Haslam wrote:
On Wed, Aug 26, 2015 at 06:11:13PM +0300, Iv
On 09/02/2015 11:16 PM, Ivan Khoronzhuk wrote:
>
>
> On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
>>
>> On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
>>>
>>>
>>> On 26.08.15 18:22, Stuart Haslam wrote:
On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan Khoronzhuk wrote:
> It's neede
On 09/03/15 03:07, Bill Fischofer wrote:
Ensure that the reorder queue associated with ordered queues is empty
as part of odp_queue_destroy() processing
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_queue.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/platform/linu
https://bugs.linaro.org/show_bug.cgi?id=1615
--- Comment #11 from Bill Fischofer ---
I seem to be able to generate this fairly reliably. Here's what gdb shows:
core was generated by `./timer_main'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 odp_atomic_fetch_inc_u64 (atom=)
I seem to be able to generate this fairly reliably. Here's what gdb shows:
core was generated by `./timer_main'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 odp_atomic_fetch_inc_u64 (atom=)
at ./include/odp/atomic.h:158
158 return __atomic_fetch_add(&atom->v, 1, __ATOMIC_R
https://bugs.linaro.org/show_bug.cgi?id=1790
Bill Fischofer changed:
What|Removed |Added
CC||maxim.uva...@linaro.org
--- Comment #2 from B
https://bugs.linaro.org/show_bug.cgi?id=1785
Bill Fischofer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
I see this all the time in api-next. It's annoying. Not sure what's
causing it but a fix would be very welcome.
On Wed, Sep 2, 2015 at 7:27 AM, Mike Holmes wrote:
> I have been seeing this recently also
>
> On 2 September 2015 at 04:30, Nicolas Morey-Chaisemartin > wrote:
>
>> Yes it's becaus
https://bugs.linaro.org/show_bug.cgi?id=1790
Bill Fischofer changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Add validation test coverage for the following APIs:
odp_schedule_prefetch()
odp_schedule_group_destroy()
odp_schedule_order_lock_init()
odp_schedule_order_lock()
odp_schedule_order_unlock()
Signed-off-by: Bill Fischofer
---
test/validation/scheduler/scheduler.c | 138 +++
Fix a race condition that could cause events to be stuck in an ordered
queue's reorder queue.
Signed-off-by: Bill Fischofer
---
.../linux-generic/include/odp_queue_internal.h | 36
platform/linux-generic/odp_queue.c | 48 +-
2 files change
odp_queue_lookup() should not be able to find queues in the transient
state QUEUE_STATUS_DESTOYED
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/platform/linux-generic/odp_queue.c
b/platform/linux-generi
Ensure that the reorder queue associated with ordered queues is empty
as part of odp_queue_destroy() processing
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_queue.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/platform/linux-generic/odp_queue.c
b/platform/linux-gener
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_schedule.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/platform/linux-generic/odp_schedule.c
b/platform/linux-generic/odp_schedule.c
index a88ba4d..c6619e5 100644
--- a/platform/linux-generic/odp_schedule.c
Ordered queues must be rescheduled before caching context locally to
avoid contaminating the scheduler poll queues with false ordering info.
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_schedule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/platform/
Correct the range check on odp_schedule_group_destroy() and the
associated handling of scheduler group names.
Signed-off-by: Bill Fischofer
---
platform/linux-generic/odp_schedule.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/platform/linux-generic/odp_schedule.c
b
This patch addresses critical bugs blocking the release of ODP v1.3 and
resolves Bug https://bugs.linaro.org/show_bug.cgi?id=1790
With this patch applied, all scheduler tests now pass reliably and
the MASTER branch can be tagged ODP v1.3.
- Specific issues addressed by this patch series include:
https://bugs.linaro.org/show_bug.cgi?id=1790
Bug ID: 1790
Summary: Critical scheduling issues blocking release of ODP
v1.3
Product: OpenDataPlane
Version: 1.3
Hardware: All
OS: Linux
Status: UNCO
On 02.09.15 12:35, Nicolas Morey-Chaisemartin wrote:
The odp_scheduler() requires time value in its own ticks, so
pass scheduler wait time instead of ns.
Signed-off-by: Nicolas Morey-Chaisemartin
---
Reviewed-by: Ivan Khoronzhuk
test/validation/pktio/pktio.c | 7 ---
1 file changed
On 02.09.15 12:12, Nicolas Morey-Chaisemartin wrote:
When fixing the wait time passed to schedule by using
odp_schedule_wait_time in patch:
commit 0bd245638dd0 ("validation: pktio: don't mix scheduler wait time and
ns")
wait time was increased to 1 second instead of 1 msec
which causes the t
Hi, Petri
We have to look at it proceeding from performance, platform portability and
simplicity
If you want to split on hi-res time and low-res they must have separate
functions and
be not under one common opaque time in order to not break hi-res measurements.
But in fact you split the same
On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
On 26.08.15 18:22, Stuart Haslam wrote:
On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan Khoronzhuk wrote:
It's needed because time resolution can be a little more than 1ns
and in this case o
The word "cycle" is left from old API time names. The "cycle" is
ambiguous word, especially when it can be used for other purposes.
So better to use "tick" or "time" word or just "t" symbol.
Signed-off-by: Ivan Khoronzhuk
---
example/generator/odp_generator.c | 12 ++---
example/timer/odp_ti
The time API names were changed from odp_time_cycle* to odp_time*.
Also new time API operates with new opaque type - odp_time_t, as
result several new API calls were added. For odp_schdule.c avoid
"cycle" word usage as it was left from old time API names.
This patch is intended to align linux-gene
Current time API supposes that frequency of counter is equal
to CPU frequency. But that's not always true, for instance,
in case if no access to CPU cycle counter, another hi-resolution
timer can be used, and it`s rate can be different from CPU
rate. There is no big difference in which cycles to me
This seres is intended to unbind time API names from CPU "cycles".
Also remove usage of word "cycle" from appropriate places as it's
no more valid.
Based on "[odp-lng] [Patch 0/4] preparation series before updating odp time API"
https://lists.linaro.org/pipermail/lng-odp/2015-August/014850.html
v
Sorry, I forgot to place a check-odp flag in the subject.
On 02/09/15 16:45, Zoltan Kiss wrote:
And remove the restriction about IP fragment support.
Signed-off-by: Zoltan Kiss
---
helper/platform/dpdk | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/helper/platform/dpd
And remove the restriction about IP fragment support.
Signed-off-by: Zoltan Kiss
---
helper/platform/dpdk | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/helper/platform/dpdk b/helper/platform/dpdk
index ae545a2..58cd6eb 100644
--- a/helper/platform/dpdk
+++ b/helper/platfo
Hi,
I think we need to restart the time API discussion and specify it only wall
time in mind. CPU cycle count APIs can be tuned as a next step. CPU cycle
counters are affected by frequency scaling, which makes those difficult to use
for counting linear, real time. The time API should specify a
https://bugs.linaro.org/show_bug.cgi?id=1615
--- Comment #10 from Stuart Haslam ---
I'm still seeing this occasionally, but I'm able to provoke it reliably like
this;
ulimit -c unlimited
rm core
while true; do ./test/validation/timer/timer_main; [ -f core ] && break; done
(may need to modify ac
On 2 September 2015 at 14:53, Maxim Uvarov wrote:
> On 09/02/15 14:11, Alexandru Badicioiu wrote:
>
>> Hi Maxim,
>> I think we need a real spec, maybe API extension for IPC pktio to be
>> extendable to platforms with HW acceleration, otherwise it will be just a
>> linux generic implementation fea
https://bugs.linaro.org/show_bug.cgi?id=1787
Bug ID: 1787
Summary: libcrypto.a: No such file or directory
Product: OpenDataPlane
Version: 1.2
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: enhance
I have been seeing this recently also
On 2 September 2015 at 04:30, Nicolas Morey-Chaisemartin
wrote:
> Yes it's because I did not clean. But even without changing the commit I
> run into the issue...
>
> You can try this:
> git checkout origin/master
> git clean -dxff
> ./bootstrap && ./config
https://bugs.linaro.org/show_bug.cgi?id=1786
Bug ID: 1786
Summary: CID 143679: odp_classifier.c CHECKED_RETURN
Product: OpenDataPlane
Version: 1.3
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: en
On 09/02/15 14:11, Alexandru Badicioiu wrote:
Hi Maxim,
I think we need a real spec, maybe API extension for IPC pktio to be
extendable to platforms with HW acceleration, otherwise it will be
just a linux generic implementation feature. The test application
cannot be a itself a spec.
yes, I
Hi Maxim,
I think we need a real spec, maybe API extension for IPC pktio to be
extendable to platforms with HW acceleration, otherwise it will be just a
linux generic implementation feature. The test application cannot be a
itself a spec.
I think the following assumptions cannot be imposed or work
On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
>
>
> On 26.08.15 18:22, Stuart Haslam wrote:
>> On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan Khoronzhuk wrote:
>>> It's needed because time resolution can be a little more than 1ns
>>> and in this case odp_schedule_wait_time(1) returns 0, and test
The odp_scheduler() requires time value in its own ticks, so
pass scheduler wait time instead of ns.
Signed-off-by: Nicolas Morey-Chaisemartin
---
test/validation/pktio/pktio.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/test/validation/pktio/pktio.c b/test/validat
When fixing the wait time passed to schedule by using
odp_schedule_wait_time in patch:
commit 0bd245638dd0 ("validation: pktio: don't mix scheduler wait time and
ns")
wait time was increased to 1 second instead of 1 msec
which causes the test to take nearly 2 minutes.
Signed-off-by: Nicolas Mo
Yes it's because I did not clean. But even without changing the commit I run
into the issue...
You can try this:
git checkout origin/master
git clean -dxff
./bootstrap && ./configure --enable-cunit-support --enable-test-vald
--enable-test-cpp --enable-test-helper --enable-test-perf && make -
Actual check/changes of the pktio state is now done by the pktio
global interface.
Each pktio can still implement a start/stop function to do additional
actions.
Signed-off-by: Nicolas Morey-Chaisemartin
---
platform/linux-generic/odp_packet_io.c | 15 +++
platform/linux-generic/
I think you see this because you did not clean the repo before build and
did compilation on api-next and on master.
git clean -f -d -x before compilation should help.
Maxim.
On 09/02/15 10:57, Nicolas Morey-Chaisemartin wrote:
Hi,
Since all tests were moved to Library I have been hitting the
Hi,
Since all tests were moved to Library I have been hitting the same bug over and
over in the build system.
Often when I pull master and try to rebuild from a pre existing build, I have
this error:
libtool: link: rm -fr .libs/libcrypto.a .libs/libcrypto.la
libtool: link: (cd .libs/libcrypto.l
45 matches
Mail list logo
