May I suggest
#define ODP_CRYPTO_SESSION_INVALID (*~*(odp_crypto_session_t)0U)
So we don't have to bother about the size (normal, long, long long) of
the odp_crypto_session_t
type.
On 14 August 2014 17:05, Robbie King (robking) robk...@cisco.com wrote:
Hi Alex, I’m getting ready to send new
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
I contribute a proposal for a log API for ODP to stimulate further
discussion.
Some comments:
Header file missing compile-time selection of log/severity levels, left as
an exercise to the mailing
:27, Santosh Shukla santosh.shu...@linaro.org
wrote:
On 21 August 2014 14:24, Ola Liljedahl ola.liljed...@linaro.org
wrote:
You are not always setting promiscuous mode on network interfaces in
ODP/linux-dpdk? Promiscuous mode should only be enabled when the
application
requires it. The l2fwd
Or perhaps use 64-bit (integer) arithmetic (e.g. uint64_t) to avoid using
floating point?
On 25 August 2014 11:06, Weilong Chen weilong.c...@linaro.org wrote:
This patch fix two point:
1.Time should be cast to double when calculate rtt.
2.Don't display receive message in flood mode.
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
Log API for internal ODP use.
Logging can be compile time and run time disabled.
Compile out all log levels: -DODP_LOG_LEVEL=0
Compile in all
Possibly we are missing a public API for looking up a queue (or perhaps
specifically an IPC queue) by name.
If you have two threads (in same or different processes) that first try to
look up an (IPC or global) queue by name and if this fails then creates
said IPC queue, you have introduced a race
So the packet socket fanout support uses PACKET_FANOUT_HASH which
distributes packets using a hash (i.e. some sort of Receive Side Scaling).
This creates some form of implicit classification and scheduling, how does
it then interact with ODP classification and scheduling functionality?
On 26
implementation calls the Linux kernel to perform the copy of buffers
(messages).
On 26 August 2014 14:03, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 08/26/2014 03:13 PM, Ola Liljedahl wrote:
Possibly we are missing a public API for looking up a queue (or perhaps
specifically an IPC queue) by name
Specifying an invalid/unsupported buffer type when creating a buffer pool
is indicative of a programming error which the app cannot really recover
from (it needs to be fixed). So this error is fatal.
Specifying too large buffer pool or similar should be possible for the
application to recover from
For internal errors, I really think abort() should be called by the ODP
implementation. Someone will have to debug and fix this problem, a silent
exit is not helpful. A core dump is a good start.
On 27 August 2014 14:15, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
E.g.
5:12 PM
To: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCH v2 2/2] Timer example error check
On 09/02/2014 05:31 PM, Ola Liljedahl wrote:
If we wait with these patches, my new timer API and implementation is
complete. Just going through the patch creation stage and fixing
On 2 September 2014 19:23, Victor Kamensky victor.kamen...@linaro.org
wrote:
Hi,
Sorry, I missed the point where we jumped to use of errno.
I would rather leave it to POSIX and not to mess with it. IMHO
it is quite archaic mechanism even in POSIX (recall movement
of errno from global to
Should we have separate header files for buffer pool and buffers? Or should
we perhaps have a different kind of separation?
In my Timer API design (patch sent out earlier today), odp_timer.h defines
both the timer pool and the timer data structures and operations. There's
even a timeout data
to be muticore and thread safe, so if
such additional calls were needed it would be a bug against them.
On Tue, Sep 2, 2014 at 8:32 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
If a thread writes to a buffer or some other memory only reachable
through
this buffer and then enqueues the buffer
If you use shared data (e.g. using global variables) in a multithreaded
environment, you will need to do explicit synchronization (barriers etc)
from the application.
I assume that the current test and example apps support multithreaded
(including multicore) environments. Do you think there are
Doesn't the OS take care of resource cleanup after process termination?
Why do we need to be able to do the same thing from within the application?
-- Ola
On 4 September 2014 12:03, Taras Kondratiuk taras.kondrat...@linaro.org
wrote:
Hi
We have agreed that 'free' API is needed for all ODP
:
On 09/04/2014 01:09 PM, Ola Liljedahl wrote:
Doesn't the OS take care of resource cleanup after process termination?
Why do we need to be able to do the same thing from within the
application?
Not all resources are maintained by OS. ODP implementation may access
some HW resources directly
I think the prototype should include the size of the buffer as well. Other
types of network interfaces use 64-bit MAC addresses. The cost of looking
forward is negligible.
/**
* Get MAC address of the interface
*
* @param hdl ODP packet IO handle
* @param mac_addr Storage for MAC
).
Then a odp_eth_mac_t type would be better choice to the public API (instead
of helpers).
-Petri
*From:* lng-odp-boun...@lists.linaro.org [mailto:
lng-odp-boun...@lists.linaro.org] *On Behalf Of *ext Ola Liljedahl
*Sent:* Thursday, September 04, 2014 4:01 PM
*To:* Bala Manoharan; lng-odp@lists.linaro.org
On 4 September 2014 15:45, Taras Kondratiuk taras.kondrat...@linaro.org
wrote:
On 09/04/2014 02:55 PM, Ola Liljedahl wrote:
I am fine with the application having the responsibility of configuring
these resources. But the OS must be able to 1) know a specific
application is using a resource
Good idea.
What's the strict meaning of the a/b/c numbers? I would like to see a
definition on how these numbers change when you make common changes.
E.g.
add function or type
remove function or type
syntactical change (but same semantics so functionally backwards
compatible), maybe adding an
The GCC __sync functions are not ideal anyway, containing unnecessary
barriers (there isn't really any need for barriers at all in these
functions, that's just a legacy from the original Itanium definition and
implementation me thinks). So we ought to re-implement odp_atomic.h, e.g.
with optimized
On 4 September 2014 19:27, Victor Kamensky victor.kamen...@linaro.org
wrote:
On 4 September 2014 03:09, Ola Liljedahl ola.liljed...@linaro.org wrote:
Doesn't the OS take care of resource cleanup after process termination?
Why do we need to be able to do the same thing from within
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
(This document/code contribution attached is provided under the terms of
agreement LES-LTM-21309)
New timer API and corresponding SW implementation for linux-generic.
Read more about use cases and usage here:
https://docs.google.com
, 2014 6:10 PM
To: Ola Liljedahl; Mike Holmes
Cc: Savolainen, Petri (NSN - FI/Espoo); Taras Kondratiuk; lng-
o...@lists.linaro.org
Subject: Re: [lng-odp] [PATCH] linux-generic: version: Add macros to
compare ODP versions
On 09/10/2014 05:35 PM, Ola Liljedahl wrote:
I think we should
.
The question is if we really need the current set of ODP atomic functions?
(Except for presenting a standard API that works when not using GCC).
-- Ola
On 10 September 2014 16:46, Victor Kamensky victor.kamen...@linaro.org
wrote:
On 10 September 2014 07:01, Ola Liljedahl ola.liljed...@linaro.org
. Can you please
confirm.
Regards,
Mukesh
--
*From:* lng-odp-boun...@lists.linaro.org lng-odp-boun...@lists.linaro.org
on behalf of Ola Liljedahl ola.liljed...@linaro.org
*Sent:* Thursday, September 11, 2014 6:44 PM
*To:* Victor Kamensky
*Cc:* Mrityunjay Kumar
Free/use counters updated on every alloc and free call might not be
possible to support, e.g. for HW buffer pools which allow allocation from
HW blocks. Also SW implementations of (shared) counters are not scalable.
Better to attempt to check if any buffers are still in use when buffer pool
?
- Leo
--
*From:* Ola Liljedahl ola.liljed...@linaro.org
*Sent:* Thursday, September 25, 2014 10:53 AM
*To:* Bill Fischofer
*Cc:* Rosenboim, Leonid; lng-odp-forward
*Subject:* Re: [lng-odp] [PATCH] Add API odp_buffer_pool_delete
Free/use counters updated on every
How does the API to the kernel for enabling user mode access to PMU
registers (especially counters and CCNT) look like?
Could we use a file in the /sys file system that can be written? There are
other examples of this, e.g. configuring DVFS governors.
I would love to have this feature as standard
Use cases, prerequisites, requirements, limitations, proposed design...
We don't have to write a twenty page document for this but we need to have
some clarity and agreement here.
Application running in user space wants to measure how many HW events (such
as cache misses or CPU cycles) have
performance counter instrumentations should compile and run also e.g.
on bare metal. How this API is special from anything else the application
accesses though ODP API?
-Petri
*From:* ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Friday, September 26, 2014 1:50 PM
, 2014 at 6:32 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
Your ODP application is free to use any library. You need to ensure those
libraries are available for all platforms you intend to deploy your ODP
application on. I expect this user mode perf library to be a standard
library
includes a HW
scheduler, for example, you won't find the perf counters relating to it in
the CPU architecture reference manual.
On Fri, Sep 26, 2014 at 6:46 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
CPU perf (PMU) counters are specified by the CPU architecture and so
shared by all CPU's
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Summary of changes from v2 based on review feedback from Petri S.
odp_timer.h:
Renamed struct odp_timer_pool to struct odp_timer_pool_s.
Renamed enum odp_timer_pool_clock_source_e to enum odp_timer_clk_src_e.
Replaced ODP_CLOCK_DEFAULT
- not for non-ODP projects.
What non-ODP projects lose if some API is defined in ODP? By definition
they don’t use it.
What other HW abstraction we should take out from ODP so that it would be
more convenient for non-ODP applications?
-Petri
*From:* ext Ola Liljedahl [mailto:ola.liljed
*From:* lng-odp-boun...@lists.linaro.org [mailto:
lng-odp-boun...@lists.linaro.org] *On Behalf Of *ext Ola Liljedahl
*Sent:* Monday, September 29, 2014 4:39 PM
*To:* lng-odp@lists.linaro.org
*Subject:* [lng-odp] ODP memory model
Currently ODP is using some kind of ad-hoc memory model
, and the C11 discussion should be
revisited for this.
I agree we can punt for now, but should the ARCH doc get some discussion
going before then ?
On Mon, Sep 29, 2014 at 9:07 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
It's not only about the implementation. It's about the contract
Maybe the Linux kernel coding style isn't so smart after all... With braces
on their own lines, vertically aligned, it is unlikely that this bug would
have slipped through. And the code would have looked so much clearer, at
least to me because my brain likes symmetry.
-- Ola
On 29 September
Of course.
On 30 September 2014 13:49, Bill Fischofer bill.fischo...@linaro.org
wrote:
Sounds like we need this written up properly in the ODP synchronizers
design doc. Something you'd like to take a stab at?
On Tue, Sep 30, 2014 at 3:49 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote
These were some of the more harmless patches, merely renaming some
functions. If it builds and runs, fine.
Now if someone would like to approve v4 of the Timer patch...
-- Ola
On 3 October 2014 16:46, Maxim Uvarov maxim.uva...@linaro.org wrote:
Looks like I missed patch time and did not
How would this look like for cross compilation? libodp.so will exist in the
target file system but header files and libraries needed for building will
live in the host file system. There could be multiple cross-targets
installed at the same time. An ODP platform could be used both for native
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Updated after review by Petri S.
* Changed name of odp_timer_pool_query_conf() to odp_timer_pool_info().
* Changed parameters of this call to use a predefined struct.
* Added return value to odp_timer_free(), return false if timeout
https://plus.google.com/104412829600273375417
Barry Spinney
10:00AM - 11:07AM
6 min
Ola Liljedahl
10:00AM - 11:07AM
0 min
Wireless Caller
10:01AM - 11:06AM
2 min
http://www.linkedin.com/in/rosenboim
Keith Wiles
10:01AM - 11:06AM
0 min
http
Some interface types use 64-bit MAC addresses (e.g. Firewire).
I think the ODP API should specify a recommended buffer size (e.g. #define
ODP_MACADDR_SIZE 8) and then return the actual length of the return MAC
address.
The application passes a buffer and a buffer size (this could be 6 if the
Need a success/fail return value? User would need to know if the timeout
is still coming, or not...
Why? When (if) the timeout is received, odp_timer_tmo_status() will tell
the application is the timeout is fresh or stale (or orphaned). Which use
case requires the application to
This is an API definition from scratch. I prefer to view and review the
whole API, not one piece at a time. I also like the comment function in
Google docs. And it supports track changes and suggested edits. And
maintains a revision history. What is missing? Probably only knowledge of
how to use
On 10 October 2014 10:05, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
*From:* ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Thursday, October 09, 2014 6:10 PM
*To:* Savolainen, Petri (NSN - FI/Espoo)
*Cc:* lng-odp@lists.linaro.org
*Subject:* Re: [lng
Would we still be able to use the crypto API for encryption/decryption and
secure hashing of raw (non-packet) data?
Petrí once mentioned some use cases here, e.g. encryption of logs or other
sensitive data before they are uploaded. I don't know if the ODP crypto API
is the best for such purposes
Before we can find the solution, we need to understand and agree on the
problem.
On 10 October 2014 09:05, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
“These docs are prose, not code”
This is the main problem. Prose has far less value than code. For exciting
APIs
I am in the process of redesigning the ODP atomic supports, removing all
usage of explicit barriers (e.g. odp_sync_stores) and instead making the
memory model more similar to (functionally a subset of) C11. This will be
more forward-looking and also enable higher performance for many operations
on
* Schedule one buffer
*
* Like odp_schedule(), but is *quaranteed* to schedule only one buffer at
a time.
* Each call will perform global scheduling and will reserve one buffer per
* thread in maximum. When called after other schedule functions, returns
* locally stored buffers (if any)
to optimize for QoS instead of throughput.
-Petri
From: lng-odp-boun...@lists.linaro.org [mailto:
lng-odp-boun...@lists.linaro.org] On Behalf Of ext Alexandru Badicioiu
Sent: Wednesday, October 15, 2014 3:52 PM
To: Ola Liljedahl
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp
, no? Again, I
don't think this is something we need to worry about for ODP v1.0. It
should be properly addressed in a wider context post-v1.0.
On Wed, Oct 15, 2014 at 10:51 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
What if a thread wants to stop consuming and processing events? We don't
For atomic queues, it makes sense to release the queue as quickly as
possibly (e.g. when the queue context is no longer accessed) and allow the
scheduler to schedule another packet from the same (atomic) queue to some
other thread. The current thread could continue processing, doing some
final
these additional semantics with it.
On Wed, Oct 15, 2014 at 2:12 PM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
For atomic queues, it makes sense to release the queue as quickly as
possibly (e.g. when the queue context is no longer accessed) and allow the
scheduler to schedule another
)
{
return __atomic_fetch_add (ptr, value, __ATOMIC_RELAXED)
}
-Petri
From: lng-odp-boun...@lists.linaro.org [mailto:
lng-odp-boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
Sent: Thursday, October 16, 2014 11:42 AM
To: Bill Fischofer
Cc: lng-odp-forward
Subject: Re: [lng
Ola Liljedahl
Sent: Thursday, October 16, 2014 11:42 AM
To: Bill Fischofer
Cc: lng-odp-forward
Subject: Re: [lng-odp] [ODP/PATCH v1] Look ma, no barriers! C11 memory
model
These suffixes stand for relaxed, release and acquire. They are important
concepts in C11/C++11 atomics and memory models
. odp_counter.h in future, if
that’s the main use case for applications…
-Petri
*From:* ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Thursday, October 16, 2014 3:05 PM
*To:* Savolainen, Petri (NSN - FI/Espoo)
*Cc:* Bill Fischofer; lng-odp-forward
*Subject:* Re: [lng
The vDSO code is very small:
+__attribute__((no_instrument_function)) int __vdso__perf_read_counter(void)
+{
+int ret = 0;
+asm volatile(mrs %0, pmccntr_el0 : =r (ret));
+return ret;
+}
If this system call is called from an application instead of the
corresponding mrs instruction being inlined
a
lot.
-Petri
*From:* ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Thursday, October 16, 2014 4:45 PM
*To:* Savolainen, Petri (NSN - FI/Espoo)
*Cc:* Bill Fischofer; lng-odp-forward
*Subject:* Re: [lng-odp] [ODP/PATCH v1] Look ma, no barriers! C11 memory
model
On 17 October 2014 11:05, Ola Liljedahl ola.liljed...@linaro.org wrote:
On 17 October 2014 10:46, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
+ * Atomic fetch and add to 32-bit atomic variable
+ * @note Relaxed memory model, no barriers.
+ * @note A - B = A + (-B
On 17 October 2014 11:07, Jerin Jacob jerin.ja...@caviumnetworks.com
wrote:
On Fri, Oct 17, 2014 at 10:22:37AM +0200, Ola Liljedahl wrote:
If there is some architecture that has atomic instructions for
incrementing/decrementing by 1 and using those instructions actually
increases
What characters in this patch cannot be represented by pure ASCII?
odp_check or checkpatch doesn't check for ASCII only?
Single quote (tick) and back tick characters are available in ASCII. By
using UTF-8 encoding, perhaps these characters will be represented using
their ASCII codes?
-- Ola
On
Personally I don't see any need for segmentation support in buffers. I am
just trying to shoot down what I think is flawed reasoning.
-- Ola#1
On 17 October 2014 15:03, Ola Liljedahl ola.liljed...@linaro.org wrote:
But segmentation is already needed in a current and known subclass (i.e
is not the same as right single quotation mark.
Do we have any rules or recommendations on the coding of ODP source files?
ASCII only? UTF-8? Everyone should support UTF-8 today.
On 17 October 2014 14:03, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 10/17/2014 03:54 PM, Ola Liljedahl wrote:
What
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Added header file odp_counter.h with support for 32- and 64-bit atomic counters
using relaxed memory order. 6 operations (init/read/write/add/read_inc/inc) on
32-bit and 64-bit counters respectively.A
Renamed odp_atomic_test
?
These seem to be new APIs and we need to be clear about their proposed
semantics and intended use.
Thanks.
Bill
On Mon, Oct 20, 2014 at 9:40 AM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
On 17 October 2014 10:01, Alexandru Badicioiu
alexandru.badici...@linaro.org wrote:
Hi Bill
On 20 October 2014 17:35, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
Hi,
This patch should be split into many. It's modifying atomic API,
introducing a new API (counters) as well as fixing various implementation
issues (e.g. barrier).
I'd prefer to define counters
, while
allowing parallelism in between, would seem to be one of the main design
points for ODP.
Please find a specific scenario where a chain of ordered processing stages
will not maintain global ingress-to-egress ordering.
-- Ola
Bill
On Mon, Oct 20, 2014 at 10:02 AM, Ola Liljedahl
This is an updated version of the Atomics patch:
http://lists.linaro.org/pipermail/lng-odp/2014-October/004096.html
-- Ola
On 21 October 2014 02:11, Bill Fischofer bill.fischo...@linaro.org wrote:
The agenda for this week's ODP call is as follows:
Agenda:
-
Revised Packet API
- 10:02AM
0 min
https://plus.google.com/107909139112066426665
Ola Liljedahl
10:02AM - 11:00AM
0 min
10:02AM - 10:38AM
0 min
Kamensky Victor
10:03AM - 11:07AM
0 min
Bala Manoharan
10:04AM - 11:07AM
0 min
https://plus.google.com/101798775278741634979
On 13 October 2014 16:24, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
*From:* ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
*Sent:* Friday, October 10, 2014 4:34 PM
*To:* Savolainen, Petri (NSN - FI/Espoo)
*Cc:* lng-odp@lists.linaro.org
*Subject:* Re: [lng
Why is the param parameter not marked as const? This is an input only
parameter?!
odp_queue_t odp_queue_create(const char *name, odp_queue_type_t type,
odp_queue_param_t *param);
Any other such cases?
-- Ola
___
lng-odp
On 5 November 2014 20:12, Victor Kamensky victor.kamen...@linaro.org wrote:
Hi Ola,
Below is an example of one issue I noticed.
If you would post arm counter implementation in separate
patch, I would be able to comment on all relevant places,
but with current huge patch I just give one
On 6 November 2014 00:38, Victor Kamensky victor.kamen...@linaro.org wrote:
On 5 November 2014 14:54, Mike Holmes mike.hol...@linaro.org wrote:
On 5 November 2014 15:26, Victor Kamensky victor.kamen...@linaro.org
wrote:
Hi Ola,
Please see below general comment about your approach.
On 6 November 2014 09:20, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
-Original Message-
From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
boun...@lists.linaro.org] On Behalf Of ext Victor Kamensky
Sent: Thursday, November 06, 2014 1:38 AM
To: Mike
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
New API odp_counter.h with support for 32- and 64-bit shared (atomic) counters.
Implementation uses GCC __atomic builtins behind a wrapper type and wrapper API
which enforces the usage of the appropriate access functions.
This also provides
On 7 November 2014 14:07, Bill Fischofer bill.fischo...@linaro.org wrote:
In working through the packet implementation in linux-generic, it seems that
headroom serves two purposes and my thought is to simply document this
officially and I'd like to get thoughts on this.
Headroom permits
Isn't a pktio instance (pure HW or SW like in this case) allowed to
put requirements on what kind of buffers (e.g. number and sizes of
segments) that are required for reception?
On transmission, the pktio instance ought to handle segmented buffers.
Possibly linux-generic could use writev() to
I'd be interested in hearing if any implementations have problems doing
this.
Bill
On Sun, Nov 9, 2014 at 3:00 PM, Ola Liljedahl ola.liljed...@linaro.org
wrote:
On 7 November 2014 14:07, Bill Fischofer bill.fischo...@linaro.org
wrote:
In working through the packet implementation
On 10 November 2014 09:57, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
This is exactly the point I have been trying to make on this C11
atomics thread. Maybe today, the C11 style atomics fit ARMv8.0 ISA
perfectly, but the day when ARM ISA will have proper far atomics -
On 10 November 2014 13:04, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 11/10/2014 03:19 AM, Ola Liljedahl wrote:
Checkpatch complains on a lot of stuff that is legitimate C... And
many things are considered errors when I personally think a warning
should suffice.
I also had a case where
anonymous reduces the chance of stray
references to them and also makes it clear to all that they are not to be
used.
On Mon, Nov 10, 2014 at 6:04 AM, Maxim Uvarov maxim.uva...@linaro.org
wrote:
On 11/10/2014 03:19 AM, Ola Liljedahl wrote:
Checkpatch complains on a lot of stuff
platform/linux-generic/odp_packet_socket.c:
static inline void mmap_rx_user_ready(struct tpacket2_hdr *hdr)
{
hdr-tp_status = TP_STATUS_KERNEL;
__sync_synchronize();
}
static inline void mmap_tx_user_ready(struct tpacket2_hdr *hdr)
{
hdr-tp_status =
On 12 November 2014 13:48, Savolainen, Petri (NSN - FI/Espoo)
petri.savolai...@nsn.com wrote:
Hi,
Hopefully the ascii graphics underneath renders correctly. Here's an example
where timer API without cancel status (return value) is causing, not only
potential implementation inefficiency, but
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
This patches introduces odp_atomic_internal.h and changes the usage from GCC
__atomic builtins to the odp_atomic_internal.h API where possible. Only
odp_ring.c (which is not a proper ODP module) still uses GCC __atomic builtins
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Some of these changes are in preparation for the appearance of
odp_atomic_internal.h but this patch can be merged separately.
odp_atomic.h: Use struct for 32- and 64-bit atomic types, this prevents
non-atomic access to atomic variables. 64
Liljedahl
Sent: Wednesday, November 19, 2014 12:55 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCH 1/2] atomics typedef/implementation/usage fixes
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Some of these changes are in preparation for the appearance
syntax. Added usage of odp_barrier_t
instead of home grown thread barrier.
Ola Liljedahl (7):
api: odp_atomic.h: use struct type, relaxed implem, missing funcs
api: odp_barrier.h: signature change, use odp_atomic.h, atomic
wrap-around fix
linux-generic: odp_ring.c: use __atomic cmpset, added
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
platform/linux-generic/odp_ticketlock.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/platform/linux-generic/odp_ticketlock.c
b/platform/linux-generic/odp_ticketlock.c
index be5b885..dc6ff83 100644
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
platform/linux-generic/include/api/odp_atomic.h | 269 +++-
test/api_test/odp_atomic_test.c | 31 +--
2 files changed, 182 insertions(+), 118 deletions(-)
diff --git a/platform/linux-generic/include
bisect
impossible.
On 20 November 2014 06:53, Ola Liljedahl ola.liljed...@linaro.org wrote:
Some of these changes (e.g. use of GCC __atomic builtins) are in
preparation
for the appearance of odp_atomic_internal.h but these patches can be
merged
separately.
odp_atomic.h:
Use struct for 32
-
boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
Sent: Thursday, November 20, 2014 1:54 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCH 2/7] api: odp_barrier.h: signature change, use
odp_atomic.h, atomic wrap-around fix
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
On 21 November 2014 19:57, Shmulik Ladkani shmulik.ladk...@gmail.com wrote:
These functions do not change their parameter. Express that.
Prevents warnings when argument passed is an address of a constant
atomic variable.
Even though this seems like a good idea, it is actually not. Or it
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Added missing release barriers. Updated to use GCC __atomic cmpset facility
(temporary fix).
platform/linux-generic/odp_ring.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/platform
missing barrier in ticketlock_lock().
odp_atomic_test.c: update to conform to latest odp_atomic.h syntax. Added
usage of odp_barrier_t instead of home grown thread barrier. Updated some
descriptions and help texts.
Ola Liljedahl (9):
linux-generic: odp_ring.c use __atomic
linux-generic
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Updated to use GCC __atomic barriers.
platform/linux-generic/odp_barrier.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/platform/linux-generic/odp_barrier.c
b/platform/linux-generic/odp_barrier.c
index 87be2a1
Signed-off-by: Ola Liljedahl ola.liljed...@linaro.org
---
Removed odp_mem_barrier() which is a compiler only barrier and basically
useless and dangerous on all weakly ordered architectures.
platform/linux-generic/include/odp_spin_internal.h | 9 -
1 file changed, 9 deletions(-)
diff
On 24 November 2014 at 20:08, Maxim Uvarov maxim.uva...@linaro.org wrote:
On 11/24/2014 09:05 PM, Bill Fischofer wrote:
Returning a pointer to an internal structure should be discouraged. You
have no idea what the caller will do with what you return so better that
they pass in something that
1 - 100 of 896 matches
Mail list logo
