On 11 May 2015 at 20:23, Stuart Haslam stuart.has...@linaro.org wrote:
On Mon, May 11, 2015 at 12:48:24PM +0200, Christophe Milard wrote:
Hopefully according to the agreement of last week.
The changes are applyed to module random, one of the simplest.
Please review carefully as all modules
Hi,
Interface names become just plain number when you bind them to DPDK
drivers (which are not actual kernel drivers, just make sure the kernel
doesn't bother your interface). AFAIK they they are incremented from 0
in the order you added your cards to DPDK.
Regards,
Zoltan
On 12/05/15
Hi,
I may have missed some mail but ... don't get why the third string is needed.
API string (odp_version_api_str()) is the API version number in string format
(in addition to macros in numeric format). Implementation string
(odp_version_impl_str()) is a free form string containing whatever
I dont think you can implement a mandatory ODP API based on an optional
helper api.
The ring implementation should be inside the linux-generic implementation
if you want to use it, other implementations can copy it as they do now
from linux-generic for other features such as timers.
Helpers need
On 12 May 2015 at 09:30, Maxim Uvarov maxim.uva...@linaro.org wrote:
take date as date of the latest commit in ./platform/linux-generic,
not as current compilation date.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
---
v2: somehow latest change did not amend to v1, use v2.
I can't find the original of this mail in my Thunderbird, but anyhow:
Reviewed-by: Zoltan Kiss zoltan.k...@linaro.org
And I've tested the packet_flags changes with ODP-DPDK.
Zoli
___
lng-odp mailing list
lng-odp@lists.linaro.org
The helpers need to be tested independently from the ODP API, create a
folder to contain helper tests, adding tests for process and thread
creation.
Signed-off-by: Mike Holmes mike.hol...@linaro.org
---
Makefile.am | 2 +-
configure.ac | 16 +
On Tue, May 12, 2015 at 09:02:18AM +0200, Christophe Milard wrote:
On 11 May 2015 at 20:23, Stuart Haslam stuart.has...@linaro.org wrote:
On Mon, May 11, 2015 at 12:48:24PM +0200, Christophe Milard wrote:
Hopefully according to the agreement of last week.
The changes are applyed to
I think it should be OK to use ordered queues instead of atomic queues,
e.g. for sequence number allocation (which will need an atomic variable to
hold the seqno counter). Packet ingress order will be maintained but might
not always correspond to sequence number order. This is not a problem a the
On 05/12/2015 14:47, Mike Holmes wrote:
On 12 May 2015 at 04:14, Savolainen, Petri (Nokia - FI/Espoo)
petri.savolai...@nokia.com mailto:petri.savolai...@nokia.com wrote:
Hi,
I may have missed some mail but ... don't get why the third string
is needed. API string
On 12 May 2015 at 18:06, Ola Liljedahl ola.liljed...@linaro.org wrote:
On 12 May 2015 at 14:28, Bala Manoharan bala.manoha...@linaro.org wrote:
IMO, using atomic variable instead of atomic queues will work for this Ipsec
example use-case as in this case the critical section is required only
IMO, using atomic variable instead of atomic queues will work for this
Ipsec example use-case as in this case the critical section is required
only for updating the sequence number but in a generic use-case the
atomicity should be protected over a region of code which the application
wants to be
Thanks for the book reference. Another reason why you want HW scheduling
as the number of parallel flows increases. Doing everything in SW has its
limits.
On Tue, May 12, 2015 at 6:47 AM, Alexandru Badicioiu
alexandru.badici...@linaro.org wrote:
Atomic increment performance gets worse by
Yes the seqno counter is a shared resource and the atomic_fetch_and_add
will eventually become a bottleneck for per-SA throughput. But one could
hope that it should scale better than using atomic queues although this
depends on the actual microarchitecture.
Freescale PPC has decorated storage,
On 12 May 2015 at 04:14, Savolainen, Petri (Nokia - FI/Espoo)
petri.savolai...@nokia.com wrote:
Hi,
I may have missed some mail but ... don't get why the third string is
needed. API string (odp_version_api_str()) is the API version number in
string format (in addition to macros in numeric
On 12 May 2015 at 03:02, Christophe Milard christophe.mil...@linaro.org
wrote:
On 11 May 2015 at 20:23, Stuart Haslam stuart.has...@linaro.org wrote:
On Mon, May 11, 2015 at 12:48:24PM +0200, Christophe Milard wrote:
Hopefully according to the agreement of last week.
The changes are
Ping. These patches need review.
Thanks,
Maxim.
On 05/08/2015 12:57, Maxim Uvarov wrote:
v5: - accounted all comments for previous v4 review.
- do not modify any api function, everything is done inside linux-generic.
Please review that version.
Thank you,
Maxim.
Maxim Uvarov (4):
https://bugs.linaro.org/show_bug.cgi?id=1541
Bug ID: 1541
Summary: Untested API verify_pmr_packet_len
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
take date as date of the latest commit in ./platform/linux-generic,
not as current compilation date.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
---
platform/Makefile.inc | 5 +
platform/linux-generic/odp_impl.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
In my understanding, releasing the atomic context implies _only_ that the
scheduler is free to return an event from the same atomic queue as the
previous event. Conversion to ordered should be explicit (or create the
queue with ATOMIC | ORDERED params) and currently is not defined.
However, there
take date as date of the latest commit in ./platform/linux-generic,
not as current compilation date.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
---
v2: somehow latest change did not amend to v1, use v2.
platform/Makefile.inc | 5 +
platform/linux-generic/odp_impl.c | 2
take date as date of the latest commit in ./platform/linux-generic,
not as current compilation date.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
---
platform/Makefile.inc | 4
platform/linux-generic/odp_impl.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff
Hello,
New information for ODP API-NEXT has been published to the ODP website.
http://www.opendataplane.org/documentation/
and
http://www.opendataplane.org/testing/
--
Sincerely,
Marshall Guillory
Technical Program Enabler, Agile Coach, Scrum master
Networking (LNG) and Platform (LAB, QAS,
https://bugs.linaro.org/show_bug.cgi?id=1544
Bug ID: 1544
Summary: Untested API verify_pmr_tcp_sport
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1547
Bug ID: 1547
Summary: Untested API copy_md_to_packet
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1548
Bug ID: 1548
Summary: Untested API parse_ipv6
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1542
Bug ID: 1542
Summary: Unteszted API verify_pmr_ip_proto
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1543
Bug ID: 1543
Summary: Untested API verify_pmr_ipv4_daddr
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1545
Bug ID: 1545
Summary: Untested API verify_pmr_tcp_dport
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1546
Bug ID: 1546
Summary: Untested API verify_pmr_udp_dport
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
https://bugs.linaro.org/show_bug.cgi?id=1549
Bug ID: 1549
Summary: Untested API parse_tcp
Product: OpenDataPlane
Version: 1.0.4
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
So callers can add extra params to configure
Signed-off-by: Zoltan Kiss zoltan.k...@linaro.org
---
helper/generic | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/helper/generic b/helper/generic
index f49f509..aa1b10a 100644
--- a/helper/generic
+++ b/helper/generic
@@ -3,7
On 12 May 2015 at 15:30, Alexandru Badicioiu alexandru.badici...@linaro.org
wrote:
In my understanding, releasing the atomic context implies _only_ that the
scheduler is free to return an event from the same atomic queue as the
previous event. Conversion to ordered should be explicit (or
33 matches
Mail list logo
