date:20151117

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

2015-11-17 Thread Bill Fischofer

We can discuss it during today's public call.  Thanks.



On Tue, Nov 17, 2015 at 2:23 AM, Nicolas Morey-Chaisemartin <
nmo...@kalray.eu> wrote:

> I have read few things here and there about the repo split but haven't
> seen the full plan of the ML (maybe I missed it).
> Is there some more information somewhere ?
>
> Nicolas
>
>
> On 11/17/2015 05:21 AM, Bill Fischofer wrote:
>
> This seems reasonable, but is probably already part of the new odp-api.git
> repo creation activity.
>
> On Thu, Nov 12, 2015 at 8:22 AM, Nicolas Morey-Chaisemartin <
> nmo...@kalray.eu> wrote:
>
>> Signed-off-by: Nicolas Morey-Chaisemartin 
>> ---
>>  platform/Makefile.inc  | 39
>> ++
>>  platform/linux-generic/Makefile.am | 39
>> --
>>  2 files changed, 39 insertions(+), 39 deletions(-)
>>
>> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
>> index 8e8e97b..14e134c 100644
>> --- a/platform/Makefile.inc
>> +++ b/platform/Makefile.inc
>> @@ -15,3 +15,42 @@ AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
>>  GIT_DESC = `$(top_srcdir)/scripts/git_hash.sh $(top_srcdir)`
>>  AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
>>  AM_CFLAGS += -DPLATFORM=${with_platform}
>> +
>> +odpapiincludedir= $(includedir)/odp/api
>> +odpapiinclude_HEADERS = \
>> + $(top_srcdir)/include/odp/api/align.h \
>> + $(top_srcdir)/include/odp/api/atomic.h \
>> + $(top_srcdir)/include/odp/api/barrier.h \
>> + $(top_srcdir)/include/odp/api/buffer.h \
>> + $(top_srcdir)/include/odp/api/byteorder.h \
>> + $(top_srcdir)/include/odp/api/classification.h \
>> + $(top_srcdir)/include/odp/api/compiler.h \
>> + $(top_srcdir)/include/odp/api/config.h \
>> + $(top_srcdir)/include/odp/api/cpu.h \
>> + $(top_srcdir)/include/odp/api/cpumask.h \
>> + $(top_srcdir)/include/odp/api/crypto.h \
>> + $(top_srcdir)/include/odp/api/debug.h \
>> + $(top_srcdir)/include/odp/api/errno.h \
>> + $(top_srcdir)/include/odp/api/event.h \
>> + $(top_srcdir)/include/odp/api/hints.h \
>> + $(top_srcdir)/include/odp/api/init.h \
>> + $(top_srcdir)/include/odp/api/packet.h \
>> + $(top_srcdir)/include/odp/api/packet_flags.h \
>> + $(top_srcdir)/include/odp/api/packet_io.h \
>> + $(top_srcdir)/include/odp/api/pool.h \
>> + $(top_srcdir)/include/odp/api/queue.h \
>> + $(top_srcdir)/include/odp/api/random.h \
>> + $(top_srcdir)/include/odp/api/rwlock.h \
>> + $(top_srcdir)/include/odp/api/schedule.h \
>> + $(top_srcdir)/include/odp/api/schedule_types.h \
>> + $(top_srcdir)/include/odp/api/shared_memory.h \
>> + $(top_srcdir)/include/odp/api/spinlock.h \
>> + $(top_srcdir)/include/odp/api/std_types.h \
>> + $(top_srcdir)/include/odp/api/sync.h \
>> + $(top_srcdir)/include/odp/api/system_info.h \
>> + $(top_srcdir)/include/odp/api/thread.h \
>> + $(top_srcdir)/include/odp/api/thrmask.h \
>> + $(top_srcdir)/include/odp/api/ticketlock.h \
>> + $(top_srcdir)/include/odp/api/time.h \
>> + $(top_srcdir)/include/odp/api/timer.h \
>> + $(top_srcdir)/include/odp/api/version.h
>> \ No newline at end of file
>> diff --git a/platform/linux-generic/Makefile.am
>> b/platform/linux-generic/Makefile.am
>> index 0135947..610e04d 100644
>> --- a/platform/linux-generic/Makefile.am
>> +++ b/platform/linux-generic/Makefile.am
>> @@ -73,45 +73,6 @@ odpplatinclude_HEADERS = \
>>   $(srcdir)/include/odp/plat/timer_types.h \
>>   $(srcdir)/include/odp/plat/version_types.h
>>
>> -odpapiincludedir= $(includedir)/odp/api
>> -odpapiinclude_HEADERS = \
>> - $(top_srcdir)/include/odp/api/align.h \
>> - $(top_srcdir)/include/odp/api/atomic.h \
>> - $(top_srcdir)/include/odp/api/barrier.h \
>> - $(top_srcdir)/include/odp/api/buffer.h \
>> - $(top_srcdir)/include/odp/api/byteorder.h \
>> - $(top_srcdir)/include/odp/api/classification.h \
>> - $(top_srcdir)/include/odp/api/compiler.h \
>> - $(top_srcdir)/include/odp/api/config.h \
>> - $(top_srcdir)/include/odp/api/cpu.h \
>> - $(top_srcdir)/include/odp/api/cpumask.h \
>> - $(top_srcdir)/include/odp/api/crypto.h \
>> - $(top_srcdir)/include/odp/api/debug.h \
>> - $(top_srcdir)/include/odp/api/errno.h \
>> -

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

2015-11-17 Thread Mike Holmes

I am wondering if it makes more sense to have odp-framework.git which
contains the api, docs, helpers and tests and then separate out the
platform specific linux-generic renaming it to odp-linux to match the other
platforms.

Then all platforms are odp-framework + the platforms they want to include

I think splitting out just the api leaves us with a mess of parts when what
needs to be reused is the framework

Mike

On 17 November 2015 at 08:07, Bill Fischofer 
wrote:

> We can discuss it during today's public call.  Thanks.
>
>
>
> On Tue, Nov 17, 2015 at 2:23 AM, Nicolas Morey-Chaisemartin <
> nmo...@kalray.eu> wrote:
>
>> I have read few things here and there about the repo split but haven't
>> seen the full plan of the ML (maybe I missed it).
>> Is there some more information somewhere ?
>>
>> Nicolas
>>
>>
>> On 11/17/2015 05:21 AM, Bill Fischofer wrote:
>>
>> This seems reasonable, but is probably already part of the new
>> odp-api.git repo creation activity.
>>
>> On Thu, Nov 12, 2015 at 8:22 AM, Nicolas Morey-Chaisemartin <
>> nmo...@kalray.eu> wrote:
>>
>>> Signed-off-by: Nicolas Morey-Chaisemartin 
>>> ---
>>>  platform/Makefile.inc  | 39
>>> ++
>>>  platform/linux-generic/Makefile.am | 39
>>> --
>>>  2 files changed, 39 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
>>> index 8e8e97b..14e134c 100644
>>> --- a/platform/Makefile.inc
>>> +++ b/platform/Makefile.inc
>>> @@ -15,3 +15,42 @@ AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
>>>  GIT_DESC = `$(top_srcdir)/scripts/git_hash.sh $(top_srcdir)`
>>>  AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
>>>  AM_CFLAGS += -DPLATFORM=${with_platform}
>>> +
>>> +odpapiincludedir= $(includedir)/odp/api
>>> +odpapiinclude_HEADERS = \
>>> + $(top_srcdir)/include/odp/api/align.h \
>>> + $(top_srcdir)/include/odp/api/atomic.h \
>>> + $(top_srcdir)/include/odp/api/barrier.h \
>>> + $(top_srcdir)/include/odp/api/buffer.h \
>>> + $(top_srcdir)/include/odp/api/byteorder.h \
>>> + $(top_srcdir)/include/odp/api/classification.h \
>>> + $(top_srcdir)/include/odp/api/compiler.h \
>>> + $(top_srcdir)/include/odp/api/config.h \
>>> + $(top_srcdir)/include/odp/api/cpu.h \
>>> + $(top_srcdir)/include/odp/api/cpumask.h \
>>> + $(top_srcdir)/include/odp/api/crypto.h \
>>> + $(top_srcdir)/include/odp/api/debug.h \
>>> + $(top_srcdir)/include/odp/api/errno.h \
>>> + $(top_srcdir)/include/odp/api/event.h \
>>> + $(top_srcdir)/include/odp/api/hints.h \
>>> + $(top_srcdir)/include/odp/api/init.h \
>>> + $(top_srcdir)/include/odp/api/packet.h \
>>> + $(top_srcdir)/include/odp/api/packet_flags.h \
>>> + $(top_srcdir)/include/odp/api/packet_io.h \
>>> + $(top_srcdir)/include/odp/api/pool.h \
>>> + $(top_srcdir)/include/odp/api/queue.h \
>>> + $(top_srcdir)/include/odp/api/random.h \
>>> + $(top_srcdir)/include/odp/api/rwlock.h \
>>> + $(top_srcdir)/include/odp/api/schedule.h \
>>> + $(top_srcdir)/include/odp/api/schedule_types.h \
>>> + $(top_srcdir)/include/odp/api/shared_memory.h \
>>> + $(top_srcdir)/include/odp/api/spinlock.h \
>>> + $(top_srcdir)/include/odp/api/std_types.h \
>>> + $(top_srcdir)/include/odp/api/sync.h \
>>> + $(top_srcdir)/include/odp/api/system_info.h \
>>> + $(top_srcdir)/include/odp/api/thread.h \
>>> + $(top_srcdir)/include/odp/api/thrmask.h \
>>> + $(top_srcdir)/include/odp/api/ticketlock.h \
>>> + $(top_srcdir)/include/odp/api/time.h \
>>> + $(top_srcdir)/include/odp/api/timer.h \
>>> + $(top_srcdir)/include/odp/api/version.h
>>> \ No newline at end of file
>>> diff --git a/platform/linux-generic/Makefile.am
>>> b/platform/linux-generic/Makefile.am
>>> index 0135947..610e04d 100644
>>> --- a/platform/linux-generic/Makefile.am
>>> +++ b/platform/linux-generic/Makefile.am
>>> @@ -73,45 +73,6 @@ odpplatinclude_HEADERS = \
>>>   $(srcdir)/include/odp/plat/timer_types.h \
>>>   $(srcdir)/include/odp/plat/version_types.h
>>>
>>> -odpapiincludedir= $(includedir)/odp/api
>>> -odpapiinclude_HEADERS = \
>>> - $(top_srcdir)/include/odp/api/align.h \
>>> - $(top_srcdir)/include/odp/api/atomic.h \
>>> - $(top_srcdir)/include/odp/api/barrier.h \
>>> - $(top_srcdir)/include/odp/api/buffer.h \
>>> -

Re: [lng-odp] [API-NEXT PATCHv10 0/4] Egress Traffic Manager

2015-11-17 Thread Maxim Uvarov



Problem with building 32 bit app:

 /* A hash table entry is LOGICALLY either empty, a pointer to a 64-byte
 * aligned name_tbl_entry_t OR a pointer to a 64-byte aligned secondary 
hash

 * table.  Since the bottom 6-bits of this value are not needed to hold the
 * address, these 6 bits are used to indicate the what type of object this
 * address refers to AND in one case the maximum number of hash 
"collisions"
 * at this level.  Specifically, if the entire value is 0 then this 
entry is
 * empty, else if the bottom 6 bits are 0, then this hash_tbl_entry_t 
value is

 * a pointer to a secondary hash table.  Otherwise if the bottom 6 bits are
 * NOT zero then this values points to a (linked list of) 
name_table_entry_t

 * records AND the bottom 6 bits are the length of this list.
 */
typedef uintptr_t hash_tbl_entry_t;


Code uses shift on 48 which makes that hash not workable. Define it as 
uint64_t makes

new problem with cast to and from pointer to hash_tbl_entry_t.

I think that needed to be replaced with some more advance type. Like 
struct with ptr and bits.


Maxim.


On 11/12/2015 19:36, Bill Fischofer wrote:

Changes in v10
- Add back ARM definitions for _crc32w() from Alex that got dropped in v9

Note: Checkpatch complains about the _asm() line.  Says spaces are needed but
if spaces are added then complains that spaces are prohibited.  Rules need to
be updated to ignore these sort of constructs.

Changes in v9
- Rebase on top of latest queue fixes

Changes in v8
- add ARM definition for __crc32w() function (from Alex)

Changes in v7 (review comments by Maxim)
- Correct architecture ifdefs (use of arch dir in later patch)
- Correct doxygen for queue types
- Change internal APIs that use odp_ prefix to use _odp prefix
- Rebase to latest api-next

Changes in v6
- Move documentation of packet colors to main API file
- Add ODP prefix to odp_tm_egress_kind_t enums

Changes in v5
- Add include file odp_traffic_mngr_internal.h
- Add support for odp_tm_enq() from packets originating from ordered queues

Changes in v4
- Incorporate API changes suggested by Petri

Changes in v3
- Fix checkpatch errors (Bill)

Changes in v2
- Full patch submission (Barry)

Barry Spinney (4):
   api: tm: add tm API definitions
   linux-generic: tm: implement traffic manager
   linux-generic: tm: add tm to build
   example: tm: traffic manager example

  configure.ac   |1 +
  example/Makefile.am|2 +-
  example/traffic_mgmt/.gitignore|1 +
  example/traffic_mgmt/Makefile.am   |9 +
  example/traffic_mgmt/odp_traffic_mgmt.c|  781 ++
  include/odp.h  |1 +
  include/odp/api/packet.h   |   69 +
  include/odp/api/traffic_mngr.h | 1611 +++
  platform/linux-generic/Makefile.am |   13 +
  .../linux-generic/include/odp/plat/packet_types.h  |   11 +
  .../linux-generic/include/odp/plat/queue_types.h   |7 +
  .../include/odp/plat/traffic_mngr_types.h  |  185 ++
  platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
  platform/linux-generic/include/odp_internal.h  |2 +
  .../include/odp_name_table_internal.h  |   61 +
  .../linux-generic/include/odp_packet_internal.h|5 +
  .../linux-generic/include/odp_pkt_queue_internal.h |   62 +
  .../linux-generic/include/odp_queue_internal.h |6 +
  .../include/odp_sorted_list_internal.h |   78 +
  .../include/odp_timer_wheel_internal.h |   68 +
  .../include/odp_traffic_mngr_internal.h|  324 +++
  platform/linux-generic/odp_init.c  |5 +
  platform/linux-generic/odp_name_table.c| 1371 ++
  platform/linux-generic/odp_packet_flags.c  |   46 +-
  platform/linux-generic/odp_pkt_queue.c |  379 +++
  platform/linux-generic/odp_queue.c |   60 +
  platform/linux-generic/odp_sorted_list.c   |  271 ++
  platform/linux-generic/odp_timer_wheel.c   |  907 +++
  platform/linux-generic/odp_traffic_mngr.c  | 2799 
  29 files changed, 9168 insertions(+), 2 deletions(-)
  create mode 100644 example/traffic_mgmt/.gitignore
  create mode 100644 example/traffic_mgmt/Makefile.am
  create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c
  create mode 100644 include/odp/api/traffic_mngr.h
  create mode 100644 
platform/linux-generic/include/odp/plat/traffic_mngr_types.h
  create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h
  create mode 100644 platform/linux-generic/include/odp_name_table_internal.h
  create mode 100644 platform/linux-generic/include/odp_pkt_queue_internal.h
  create mode 100644 platform/linux-generic/include/odp_sorted_list_internal.h
  create mode 100644 platform/linux-generic/include/odp_timer_wheel_internal.h
  create mode 100644

[lng-odp] [PATCH] scripts: git_hash: support gitfiles

2015-11-17 Thread Nicolas Morey-Chaisemartin

With recent git releases, the .git at the top of a repo is not necessary
 a directory but can be a gitfile pointing to a remote git directory.
This is commonly used by git-worktree and git-submodule.
This patch changes the check for .git to allow for any file (symlinks too)

Signed-off-by: Nicolas Morey-Chaisemartin 
---
 scripts/git_hash.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/git_hash.sh b/scripts/git_hash.sh
index ccd62ab..e7f43f2 100755
--- a/scripts/git_hash.sh
+++ b/scripts/git_hash.sh
@@ -6,7 +6,7 @@ if [ -z ${1} ]; then
 fi
 ROOTDIR=${1}
 
-if [ -d ${ROOTDIR}/.git ]; then
+if [ -e ${ROOTDIR}/.git ]; then
hash=$(git --git-dir=${ROOTDIR}/.git describe | tr -d "\n")
if [[ $(git --git-dir=${ROOTDIR}/.git diff --shortstat 2> /dev/null \
| tail -n1) != "" ]]; then
@@ -18,7 +18,7 @@ if [ -d ${ROOTDIR}/.git ]; then
sed -i "s|-|.git|" ${ROOTDIR}/.scmversion
sed -i "s|-|.|g" ${ROOTDIR}/.scmversion
sed -i "s|^v||g" ${ROOTDIR}/.scmversion
-elif [ ! -d ${ROOTDIR}/.git -a ! -f ${ROOTDIR}/.scmversion ]; then
+elif [ ! -e ${ROOTDIR}/.git -a ! -f ${ROOTDIR}/.scmversion ]; then
echo -n "File ROOTDIR/.scmversion not found, "
echo "and not inside a git repository"
echo "Bailing out! Not recoverable!"
-- 
2.6.3.372.gcb93895

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [Bug 1906] New: not tested uint64_t odp_cpu_cycles_resolution(void)

2015-11-17 Thread bugzilla-daemon

https://bugs.linaro.org/show_bug.cgi?id=1906

Bug ID: 1906
   Summary: not tested uint64_t odp_cpu_cycles_resolution(void)
   Product: OpenDataPlane - linux- generic reference
   Version: api-next
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: Validation
  Assignee: lng-odp@lists.linaro.org
  Reporter: mike.hol...@linaro.org

http://docs.opendataplane.org/api-next/linux-generic-lcov-html/linux-generic/arch/x86/odp_cpu_cycles.c.gcov.html

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

Add a basic ODP overview to the User's Guide, providing
an overview of ODP concepts, components, etc. Included
are a number of diagrams covering component structure
as well as packet RX, event scheduling, and packet TX
processing.

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/users-guide.adoc | 400 ++-
 1 file changed, 398 insertions(+), 2 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 7f70046..cf77fa0 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
 Abstract
 
 This document is intended to guide a new ODP application developer.
-Further details about ODP may be found at then http://opendataplane.org[ODP] 
home page.
+Further details about ODP may be found at the http://opendataplane.org[ODP] 
home page.
 
 .Overview of a system running ODP applications
 image::../images/overview.png[align="center"]
@@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
 ODP is an API specification that allows many implementations to provide 
platform independence, automatic hardware acceleration and CPU scaling to high 
performance networking  applications.
 This document describes how to write an application that can successfully take 
advantage of the API.
 
+:numbered:
+== Introduction ==
+.OpenDataPlane Components
+image::../images/odp_components.png[align="center"]
+
+.The ODP API Specification
+ODP consists of three separate but related component parts. First, ODP is an
+abstract API specification that describes a functional model for
+data plane applications. This specification covers many common data plane
+application programming needs, such as the ability to receive, manipulate, and
+transmit packet data, without specifying how these functions are performed. 
This
+is quite intentional. It is precisely because ODP APIs do not have a preferred
+embodiment that they permit innovation in how these functions can
+be realized on various platforms that offer implementations of ODP. To achieve
+this goal, ODP APIs are described using abstract data types whose definition
+is left up to the ODP implementer.  For example, in ODP packets are referenced
+by abstract handles of type +odp_packet_t+, and packet-related APIs take
+arguments of this type. What an +odp_packet_t+ actually is is not part of the
+ODP API specification--that is the responsibility of each ODP implementation.
+
+.Summary: ODP API attributes:
+* Open Source, open contribution, BSD-3 licensed.
+* Vendor and platform neutral.
+* Application-centric.  Covers functional needs of data plane applications.
+* Ensures portability by specifying the functional behavior of ODP.
+* Defined jointly and openly by application writers and platform implementers.
+* Archiected to be implementable on a wide range of platforms efficiently
+* Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
+
+.ODP Implementations
+Second, ODP consists of multiple implementations of this API specification,
+each tailored to a specific target platform. ODP implementations determine
+how each ODP abstract type is represented on that platform and how each ODP
+API is realized. On some platforms, ODP APIs will
+be realized using specialized instructions that accelerate the functional
+behavior specified by the API. On others, hardware co-processing engines may
+completely offload the API so that again it can be performed with little or no
+involvement by a CPU. In all cases, the application sees the same
+functional behavior independent of how a given platform has chosen to realize
+it. By allowing each platform the freedom to determine how best to realize each
+API's specified functional behavior in an optimal manner, ODP permits
+applications written to its APIs to take full advantage of the unique
+capabilities of each platform without the application programmer needing to
+have specialist knowledge of that platform or to be concerned with how best
+to tune the application to a particular platform. This latter consideration is
+particularly important in Network Function Virtualization (NFV) environments
+where the application will run on a target platform chosen by someone else.
+
+.Summary: ODP Implementation Characteristics
+* One size does not fit all--supporting multiple implementations allows ODP
+to adapt to widely differing internals among platforms.
+* Anyone can create an ODP implementation tailored to their platform
+* Distribution and mainteinance of each implementation is as owner wishes
+  - Open source or closed source as business needs determine
+  - Have independent release cycles and service streams
+* Allows HW and SW innovation in how ODP APIs are implemented on each platform.
+
+.Reference Implementations
+To make it easy to get started with implementing ODP on a new platform, ODP
+supplies a number of _reference

[lng-odp] [PATCH] helper: test: add odp_table to .gitignore file

2015-11-17 Thread Bill Fischofer

Signed-off-by: Bill Fischofer 
---
 helper/test/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/helper/test/.gitignore b/helper/test/.gitignore
index 213bc5e..50a0da4 100644
--- a/helper/test/.gitignore
+++ b/helper/test/.gitignore
@@ -2,5 +2,6 @@
 *.log
 odp_chksum
 odp_process
+odp_table
 odp_thread
 odph_pause
-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

2015-11-17 Thread Bill Fischofer

That might be a reasonable split.  Of course when complete we could just
call the framework repo odp.git.  The net result of this would be that the
final split is simply to take the platforms out of the existing odp.git and
move them to their own repo.  In this case platform/linux-generic moves to
odp-linux.git and everything else in the current odp.git stays?

On Tue, Nov 17, 2015 at 7:11 AM, Mike Holmes  wrote:

> I am wondering if it makes more sense to have odp-framework.git which
> contains the api, docs, helpers and tests and then separate out the
> platform specific linux-generic renaming it to odp-linux to match the other
> platforms.
>
> Then all platforms are odp-framework + the platforms they want to include
>
> I think splitting out just the api leaves us with a mess of parts when
> what needs to be reused is the framework
>
> Mike
>
> On 17 November 2015 at 08:07, Bill Fischofer 
> wrote:
>
>> We can discuss it during today's public call.  Thanks.
>>
>>
>>
>> On Tue, Nov 17, 2015 at 2:23 AM, Nicolas Morey-Chaisemartin <
>> nmo...@kalray.eu> wrote:
>>
>>> I have read few things here and there about the repo split but haven't
>>> seen the full plan of the ML (maybe I missed it).
>>> Is there some more information somewhere ?
>>>
>>> Nicolas
>>>
>>>
>>> On 11/17/2015 05:21 AM, Bill Fischofer wrote:
>>>
>>> This seems reasonable, but is probably already part of the new
>>> odp-api.git repo creation activity.
>>>
>>> On Thu, Nov 12, 2015 at 8:22 AM, Nicolas Morey-Chaisemartin <
>>> nmo...@kalray.eu> wrote:
>>>
 Signed-off-by: Nicolas Morey-Chaisemartin 
 ---
  platform/Makefile.inc  | 39
 ++
  platform/linux-generic/Makefile.am | 39
 --
  2 files changed, 39 insertions(+), 39 deletions(-)

 diff --git a/platform/Makefile.inc b/platform/Makefile.inc
 index 8e8e97b..14e134c 100644
 --- a/platform/Makefile.inc
 +++ b/platform/Makefile.inc
 @@ -15,3 +15,42 @@ AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
  GIT_DESC = `$(top_srcdir)/scripts/git_hash.sh $(top_srcdir)`
  AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
  AM_CFLAGS += -DPLATFORM=${with_platform}
 +
 +odpapiincludedir= $(includedir)/odp/api
 +odpapiinclude_HEADERS = \
 + $(top_srcdir)/include/odp/api/align.h \
 + $(top_srcdir)/include/odp/api/atomic.h \
 + $(top_srcdir)/include/odp/api/barrier.h \
 + $(top_srcdir)/include/odp/api/buffer.h \
 + $(top_srcdir)/include/odp/api/byteorder.h \
 + $(top_srcdir)/include/odp/api/classification.h \
 + $(top_srcdir)/include/odp/api/compiler.h \
 + $(top_srcdir)/include/odp/api/config.h \
 + $(top_srcdir)/include/odp/api/cpu.h \
 + $(top_srcdir)/include/odp/api/cpumask.h \
 + $(top_srcdir)/include/odp/api/crypto.h \
 + $(top_srcdir)/include/odp/api/debug.h \
 + $(top_srcdir)/include/odp/api/errno.h \
 + $(top_srcdir)/include/odp/api/event.h \
 + $(top_srcdir)/include/odp/api/hints.h \
 + $(top_srcdir)/include/odp/api/init.h \
 + $(top_srcdir)/include/odp/api/packet.h \
 + $(top_srcdir)/include/odp/api/packet_flags.h \
 + $(top_srcdir)/include/odp/api/packet_io.h \
 + $(top_srcdir)/include/odp/api/pool.h \
 + $(top_srcdir)/include/odp/api/queue.h \
 + $(top_srcdir)/include/odp/api/random.h \
 + $(top_srcdir)/include/odp/api/rwlock.h \
 + $(top_srcdir)/include/odp/api/schedule.h \
 + $(top_srcdir)/include/odp/api/schedule_types.h \
 + $(top_srcdir)/include/odp/api/shared_memory.h \
 + $(top_srcdir)/include/odp/api/spinlock.h \
 + $(top_srcdir)/include/odp/api/std_types.h \
 + $(top_srcdir)/include/odp/api/sync.h \
 + $(top_srcdir)/include/odp/api/system_info.h \
 + $(top_srcdir)/include/odp/api/thread.h \
 + $(top_srcdir)/include/odp/api/thrmask.h \
 + $(top_srcdir)/include/odp/api/ticketlock.h \
 + $(top_srcdir)/include/odp/api/time.h \
 + $(top_srcdir)/include/odp/api/timer.h \
 + $(top_srcdir)/include/odp/api/version.h
 \ No newline at end of file
 diff --git a/platform/linux-generic/Makefile.am
 b/platform/linux-generic/Makefile.am
 index 0135947..610e04d 100644
 --- a/platform/linux-generic/Makefile.am
 +++

Re: [lng-odp] [PATCH 1/5] api: classification: add odp_cls_cos_pool_set() api

2015-11-17 Thread Bill Fischofer

This should be marked API-NEXT.

On Tue, Nov 17, 2015 at 12:16 AM, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:

> odp_cls_cos_pool_set() api is used to configure packet pool to CoS.
> The packets arriving at the CoS is allocated from the configured pool
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  include/odp/api/classification.h | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/include/odp/api/classification.h
> b/include/odp/api/classification.h
> index 380d91b..bb52c10 100644
> --- a/include/odp/api/classification.h
> +++ b/include/odp/api/classification.h
> @@ -379,6 +379,33 @@ int odp_pktio_pmr_match_set_cos(odp_pmr_set_t
> pmr_set_id, odp_pktio_t src_pktio,
> odp_cos_t dst_cos);
>
>  /**
> +* Assigns a packet buffer pool for a specific Class of service.
> +* All the packets belonging to the given class of service will
> +* be allocated from the assigned packet pool.
> +*
> +* @param   cos_id  class-of-service handle
> +* @param   pool_id Packet buffer pool handle
> +*
> +* @return  0 on success
> +* @return  <0 on failure
> +*
> +* @noteThe packet pool associated with CoS will supersede
> +*  the packet pool associated with the pktio interface
> +*/
> +int odp_cls_cos_pool_set(odp_cos_t cos_id, odp_pool_t pool_id);
> +
> +/**
> +* Get the pool associated with the given class of service
> +*
> +* @param   cos_id  class-of-service handle
> +*
> +* @retval  pool handle of the associated pool
> +* @retval  ODP_POO_INVALID in case of failure
> +*
> +*/
> +odp_pool_t odp_cls_cos_pool(odp_cos_t cos_id);
> +
> +/**
>   * Get printable value for an odp_cos_t
>   *
>   * @param hdl  odp_cos_t handle to be printed
> --
> 1.9.1
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 1/5] api: classification: add odp_cls_cos_pool_set() api

2015-11-17 Thread Bala Manoharan

Thanks for pointing out.
Will update in the next version.

Regards,
Bala

On 17 November 2015 at 18:46, Bill Fischofer  wrote:
> This should be marked API-NEXT.
>
> On Tue, Nov 17, 2015 at 12:16 AM, Balasubramanian Manoharan
>  wrote:
>>
>> odp_cls_cos_pool_set() api is used to configure packet pool to CoS.
>> The packets arriving at the CoS is allocated from the configured pool
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  include/odp/api/classification.h | 27 +++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index 380d91b..bb52c10 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -379,6 +379,33 @@ int odp_pktio_pmr_match_set_cos(odp_pmr_set_t
>> pmr_set_id, odp_pktio_t src_pktio,
>> odp_cos_t dst_cos);
>>
>>  /**
>> +* Assigns a packet buffer pool for a specific Class of service.
>> +* All the packets belonging to the given class of service will
>> +* be allocated from the assigned packet pool.
>> +*
>> +* @param   cos_id  class-of-service handle
>> +* @param   pool_id Packet buffer pool handle
>> +*
>> +* @return  0 on success
>> +* @return  <0 on failure
>> +*
>> +* @noteThe packet pool associated with CoS will supersede
>> +*  the packet pool associated with the pktio interface
>> +*/
>> +int odp_cls_cos_pool_set(odp_cos_t cos_id, odp_pool_t pool_id);
>> +
>> +/**
>> +* Get the pool associated with the given class of service
>> +*
>> +* @param   cos_id  class-of-service handle
>> +*
>> +* @retval  pool handle of the associated pool
>> +* @retval  ODP_POO_INVALID in case of failure
>> +*
>> +*/
>> +odp_pool_t odp_cls_cos_pool(odp_cos_t cos_id);
>> +
>> +/**
>>   * Get printable value for an odp_cos_t
>>   *
>>   * @param hdl  odp_cos_t handle to be printed
>> --
>> 1.9.1
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

That's what make does :)

On Tue, Nov 17, 2015 at 11:57 AM, Mike Holmes 
wrote:

>
>
> On 17 November 2015 at 12:54, Bill Fischofer 
> wrote:
>
>> Is that a review comment?  Is there a problem with the rendering?
>>
>
> Not a review comment just to make it easier for folks to read initially.
>
>
>> On Tue, Nov 17, 2015 at 11:51 AM, Mike Holmes 
>> wrote:
>>
>>> This is the rendered doc
>>>
>>> http://people.linaro.org/~mike.holmes/output/users-guide.html
>>>
>>> On 17 November 2015 at 12:15, Bill Fischofer 
>>> wrote:
>>>
 Add a basic ODP overview to the User's Guide, providing
 an overview of ODP concepts, components, etc. Included
 are a number of diagrams covering component structure
 as well as packet RX, event scheduling, and packet TX
 processing.

 Signed-off-by: Bill Fischofer 
 ---
  doc/users-guide/users-guide.adoc | 400
 ++-
  1 file changed, 398 insertions(+), 2 deletions(-)

 diff --git a/doc/users-guide/users-guide.adoc
 b/doc/users-guide/users-guide.adoc
 index 7f70046..cf77fa0 100644
 --- a/doc/users-guide/users-guide.adoc
 +++ b/doc/users-guide/users-guide.adoc
 @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
  Abstract
  
  This document is intended to guide a new ODP application developer.
 -Further details about ODP may be found at then
 http://opendataplane.org[ODP] home page.
 +Further details about ODP may be found at the 
 http://opendataplane.org[ODP]
 home page.

  .Overview of a system running ODP applications
  image::../images/overview.png[align="center"]
 @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
  ODP is an API specification that allows many implementations to
 provide platform independence, automatic hardware acceleration and CPU
 scaling to high performance networking  applications.
  This document describes how to write an application that can
 successfully take advantage of the API.

 +:numbered:
 +== Introduction ==
 +.OpenDataPlane Components
 +image::../images/odp_components.png[align="center"]
 +
 +.The ODP API Specification
 +ODP consists of three separate but related component parts. First, ODP
 is an
 +abstract API specification that describes a functional model for
 +data plane applications. This specification covers many common data
 plane
 +application programming needs, such as the ability to receive,
 manipulate, and
 +transmit packet data, without specifying how these functions are
 performed. This
 +is quite intentional. It is precisely because ODP APIs do not have a
 preferred
 +embodiment that they permit innovation in how these functions can
 +be realized on various platforms that offer implementations of ODP. To
 achieve
 +this goal, ODP APIs are described using abstract data types whose
 definition
 +is left up to the ODP implementer.  For example, in ODP packets are
 referenced
 +by abstract handles of type +odp_packet_t+, and packet-related APIs
 take
 +arguments of this type. What an +odp_packet_t+ actually is is not part
 of the
 +ODP API specification--that is the responsibility of each ODP
 implementation.
 +
 +.Summary: ODP API attributes:
 +* Open Source, open contribution, BSD-3 licensed.
 +* Vendor and platform neutral.
 +* Application-centric.  Covers functional needs of data plane
 applications.
 +* Ensures portability by specifying the functional behavior of ODP.
 +* Defined jointly and openly by application writers and platform
 implementers.
 +* Archiected to be implementable on a wide range of platforms
 efficiently
 +* Sponsored, governed, and maintained by the Linaro Networking Group
 (LNG)
 +
 +.ODP Implementations
 +Second, ODP consists of multiple implementations of this API
 specification,
 +each tailored to a specific target platform. ODP implementations
 determine
 +how each ODP abstract type is represented on that platform and how
 each ODP
 +API is realized. On some platforms, ODP APIs will
 +be realized using specialized instructions that accelerate the
 functional
 +behavior specified by the API. On others, hardware co-processing
 engines may
 +completely offload the API so that again it can be performed with
 little or no
 +involvement by a CPU. In all cases, the application sees the same
 +functional behavior independent of how a given platform has chosen to
 realize
 +it. By allowing each platform the freedom to determine how best to
 realize each
 +API's specified functional behavior in an optimal manner, ODP permits

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Mike Holmes

On 17 November 2015 at 13:15, Bill Fischofer 
wrote:

> That's what make does :)
>

Indeed - but reviews on docs are very hard to get, hopefully some one reads
it and objects who would normally ignore it!


>
> On Tue, Nov 17, 2015 at 11:57 AM, Mike Holmes 
> wrote:
>
>>
>>
>> On 17 November 2015 at 12:54, Bill Fischofer 
>> wrote:
>>
>>> Is that a review comment?  Is there a problem with the rendering?
>>>
>>
>> Not a review comment just to make it easier for folks to read initially.
>>
>>
>>> On Tue, Nov 17, 2015 at 11:51 AM, Mike Holmes 
>>> wrote:
>>>
 This is the rendered doc

 http://people.linaro.org/~mike.holmes/output/users-guide.html

 On 17 November 2015 at 12:15, Bill Fischofer  wrote:

> Add a basic ODP overview to the User's Guide, providing
> an overview of ODP concepts, components, etc. Included
> are a number of diagrams covering component structure
> as well as packet RX, event scheduling, and packet TX
> processing.
>
> Signed-off-by: Bill Fischofer 
> ---
>  doc/users-guide/users-guide.adoc | 400
> ++-
>  1 file changed, 398 insertions(+), 2 deletions(-)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 7f70046..cf77fa0 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>  Abstract
>  
>  This document is intended to guide a new ODP application developer.
> -Further details about ODP may be found at then
> http://opendataplane.org[ODP] home page.
> +Further details about ODP may be found at the
> http://opendataplane.org[ODP] home page.
>
>  .Overview of a system running ODP applications
>  image::../images/overview.png[align="center"]
> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>  ODP is an API specification that allows many implementations to
> provide platform independence, automatic hardware acceleration and CPU
> scaling to high performance networking  applications.
>  This document describes how to write an application that can
> successfully take advantage of the API.
>
> +:numbered:
> +== Introduction ==
> +.OpenDataPlane Components
> +image::../images/odp_components.png[align="center"]
> +
> +.The ODP API Specification
> +ODP consists of three separate but related component parts. First,
> ODP is an
> +abstract API specification that describes a functional model for
> +data plane applications. This specification covers many common data
> plane
> +application programming needs, such as the ability to receive,
> manipulate, and
> +transmit packet data, without specifying how these functions are
> performed. This
> +is quite intentional. It is precisely because ODP APIs do not have a
> preferred
> +embodiment that they permit innovation in how these functions can
> +be realized on various platforms that offer implementations of ODP.
> To achieve
> +this goal, ODP APIs are described using abstract data types whose
> definition
> +is left up to the ODP implementer.  For example, in ODP packets are
> referenced
> +by abstract handles of type +odp_packet_t+, and packet-related APIs
> take
> +arguments of this type. What an +odp_packet_t+ actually is is not
> part of the
> +ODP API specification--that is the responsibility of each ODP
> implementation.
> +
> +.Summary: ODP API attributes:
> +* Open Source, open contribution, BSD-3 licensed.
> +* Vendor and platform neutral.
> +* Application-centric.  Covers functional needs of data plane
> applications.
> +* Ensures portability by specifying the functional behavior of ODP.
> +* Defined jointly and openly by application writers and platform
> implementers.
> +* Archiected to be implementable on a wide range of platforms
> efficiently
> +* Sponsored, governed, and maintained by the Linaro Networking Group
> (LNG)
> +
> +.ODP Implementations
> +Second, ODP consists of multiple implementations of this API
> specification,
> +each tailored to a specific target platform. ODP implementations
> determine
> +how each ODP abstract type is represented on that platform and how
> each ODP
> +API is realized. On some platforms, ODP APIs will
> +be realized using specialized instructions that accelerate the
> functional
> +behavior specified by the API. On others, hardware co-processing
> engines may
> +completely offload the API so that again it can be performed with
> little or no
> +involvement by

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Mike Holmes

On 17 November 2015 at 12:54, Bill Fischofer 
wrote:

> Is that a review comment?  Is there a problem with the rendering?
>

Not a review comment just to make it easier for folks to read initially.


> On Tue, Nov 17, 2015 at 11:51 AM, Mike Holmes 
> wrote:
>
>> This is the rendered doc
>>
>> http://people.linaro.org/~mike.holmes/output/users-guide.html
>>
>> On 17 November 2015 at 12:15, Bill Fischofer 
>> wrote:
>>
>>> Add a basic ODP overview to the User's Guide, providing
>>> an overview of ODP concepts, components, etc. Included
>>> are a number of diagrams covering component structure
>>> as well as packet RX, event scheduling, and packet TX
>>> processing.
>>>
>>> Signed-off-by: Bill Fischofer 
>>> ---
>>>  doc/users-guide/users-guide.adoc | 400
>>> ++-
>>>  1 file changed, 398 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/users-guide/users-guide.adoc
>>> b/doc/users-guide/users-guide.adoc
>>> index 7f70046..cf77fa0 100644
>>> --- a/doc/users-guide/users-guide.adoc
>>> +++ b/doc/users-guide/users-guide.adoc
>>> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>>>  Abstract
>>>  
>>>  This document is intended to guide a new ODP application developer.
>>> -Further details about ODP may be found at then 
>>> http://opendataplane.org[ODP]
>>> home page.
>>> +Further details about ODP may be found at the http://opendataplane.org[ODP]
>>> home page.
>>>
>>>  .Overview of a system running ODP applications
>>>  image::../images/overview.png[align="center"]
>>> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>>>  ODP is an API specification that allows many implementations to provide
>>> platform independence, automatic hardware acceleration and CPU scaling to
>>> high performance networking  applications.
>>>  This document describes how to write an application that can
>>> successfully take advantage of the API.
>>>
>>> +:numbered:
>>> +== Introduction ==
>>> +.OpenDataPlane Components
>>> +image::../images/odp_components.png[align="center"]
>>> +
>>> +.The ODP API Specification
>>> +ODP consists of three separate but related component parts. First, ODP
>>> is an
>>> +abstract API specification that describes a functional model for
>>> +data plane applications. This specification covers many common data
>>> plane
>>> +application programming needs, such as the ability to receive,
>>> manipulate, and
>>> +transmit packet data, without specifying how these functions are
>>> performed. This
>>> +is quite intentional. It is precisely because ODP APIs do not have a
>>> preferred
>>> +embodiment that they permit innovation in how these functions can
>>> +be realized on various platforms that offer implementations of ODP. To
>>> achieve
>>> +this goal, ODP APIs are described using abstract data types whose
>>> definition
>>> +is left up to the ODP implementer.  For example, in ODP packets are
>>> referenced
>>> +by abstract handles of type +odp_packet_t+, and packet-related APIs take
>>> +arguments of this type. What an +odp_packet_t+ actually is is not part
>>> of the
>>> +ODP API specification--that is the responsibility of each ODP
>>> implementation.
>>> +
>>> +.Summary: ODP API attributes:
>>> +* Open Source, open contribution, BSD-3 licensed.
>>> +* Vendor and platform neutral.
>>> +* Application-centric.  Covers functional needs of data plane
>>> applications.
>>> +* Ensures portability by specifying the functional behavior of ODP.
>>> +* Defined jointly and openly by application writers and platform
>>> implementers.
>>> +* Archiected to be implementable on a wide range of platforms
>>> efficiently
>>> +* Sponsored, governed, and maintained by the Linaro Networking Group
>>> (LNG)
>>> +
>>> +.ODP Implementations
>>> +Second, ODP consists of multiple implementations of this API
>>> specification,
>>> +each tailored to a specific target platform. ODP implementations
>>> determine
>>> +how each ODP abstract type is represented on that platform and how each
>>> ODP
>>> +API is realized. On some platforms, ODP APIs will
>>> +be realized using specialized instructions that accelerate the
>>> functional
>>> +behavior specified by the API. On others, hardware co-processing
>>> engines may
>>> +completely offload the API so that again it can be performed with
>>> little or no
>>> +involvement by a CPU. In all cases, the application sees the same
>>> +functional behavior independent of how a given platform has chosen to
>>> realize
>>> +it. By allowing each platform the freedom to determine how best to
>>> realize each
>>> +API's specified functional behavior in an optimal manner, ODP permits
>>> +applications written to its APIs to take full advantage of the unique
>>> +capabilities of each platform without the application programmer
>>> needing to
>>> +have specialist knowledge of that platform or to be concerned with how
>>> best
>>> +to

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Mike Holmes

This is the rendered doc

http://people.linaro.org/~mike.holmes/output/users-guide.html

On 17 November 2015 at 12:15, Bill Fischofer 
wrote:

> Add a basic ODP overview to the User's Guide, providing
> an overview of ODP concepts, components, etc. Included
> are a number of diagrams covering component structure
> as well as packet RX, event scheduling, and packet TX
> processing.
>
> Signed-off-by: Bill Fischofer 
> ---
>  doc/users-guide/users-guide.adoc | 400
> ++-
>  1 file changed, 398 insertions(+), 2 deletions(-)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 7f70046..cf77fa0 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>  Abstract
>  
>  This document is intended to guide a new ODP application developer.
> -Further details about ODP may be found at then http://opendataplane.org[ODP]
> home page.
> +Further details about ODP may be found at the http://opendataplane.org[ODP]
> home page.
>
>  .Overview of a system running ODP applications
>  image::../images/overview.png[align="center"]
> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>  ODP is an API specification that allows many implementations to provide
> platform independence, automatic hardware acceleration and CPU scaling to
> high performance networking  applications.
>  This document describes how to write an application that can successfully
> take advantage of the API.
>
> +:numbered:
> +== Introduction ==
> +.OpenDataPlane Components
> +image::../images/odp_components.png[align="center"]
> +
> +.The ODP API Specification
> +ODP consists of three separate but related component parts. First, ODP is
> an
> +abstract API specification that describes a functional model for
> +data plane applications. This specification covers many common data plane
> +application programming needs, such as the ability to receive,
> manipulate, and
> +transmit packet data, without specifying how these functions are
> performed. This
> +is quite intentional. It is precisely because ODP APIs do not have a
> preferred
> +embodiment that they permit innovation in how these functions can
> +be realized on various platforms that offer implementations of ODP. To
> achieve
> +this goal, ODP APIs are described using abstract data types whose
> definition
> +is left up to the ODP implementer.  For example, in ODP packets are
> referenced
> +by abstract handles of type +odp_packet_t+, and packet-related APIs take
> +arguments of this type. What an +odp_packet_t+ actually is is not part of
> the
> +ODP API specification--that is the responsibility of each ODP
> implementation.
> +
> +.Summary: ODP API attributes:
> +* Open Source, open contribution, BSD-3 licensed.
> +* Vendor and platform neutral.
> +* Application-centric.  Covers functional needs of data plane
> applications.
> +* Ensures portability by specifying the functional behavior of ODP.
> +* Defined jointly and openly by application writers and platform
> implementers.
> +* Archiected to be implementable on a wide range of platforms efficiently
> +* Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
> +
> +.ODP Implementations
> +Second, ODP consists of multiple implementations of this API
> specification,
> +each tailored to a specific target platform. ODP implementations determine
> +how each ODP abstract type is represented on that platform and how each
> ODP
> +API is realized. On some platforms, ODP APIs will
> +be realized using specialized instructions that accelerate the functional
> +behavior specified by the API. On others, hardware co-processing engines
> may
> +completely offload the API so that again it can be performed with little
> or no
> +involvement by a CPU. In all cases, the application sees the same
> +functional behavior independent of how a given platform has chosen to
> realize
> +it. By allowing each platform the freedom to determine how best to
> realize each
> +API's specified functional behavior in an optimal manner, ODP permits
> +applications written to its APIs to take full advantage of the unique
> +capabilities of each platform without the application programmer needing
> to
> +have specialist knowledge of that platform or to be concerned with how
> best
> +to tune the application to a particular platform. This latter
> consideration is
> +particularly important in Network Function Virtualization (NFV)
> environments
> +where the application will run on a target platform chosen by someone
> else.
> +
> +.Summary: ODP Implementation Characteristics
> +* One size does not fit all--supporting multiple implementations allows
> ODP
> +to adapt to widely differing internals among platforms.
> +* Anyone can create an ODP implementation tailored to their platform
> +* Distribution and mainteinance of each

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

Is that a review comment?  Is there a problem with the rendering?

On Tue, Nov 17, 2015 at 11:51 AM, Mike Holmes 
wrote:

> This is the rendered doc
>
> http://people.linaro.org/~mike.holmes/output/users-guide.html
>
> On 17 November 2015 at 12:15, Bill Fischofer 
> wrote:
>
>> Add a basic ODP overview to the User's Guide, providing
>> an overview of ODP concepts, components, etc. Included
>> are a number of diagrams covering component structure
>> as well as packet RX, event scheduling, and packet TX
>> processing.
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>>  doc/users-guide/users-guide.adoc | 400
>> ++-
>>  1 file changed, 398 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/users-guide/users-guide.adoc
>> b/doc/users-guide/users-guide.adoc
>> index 7f70046..cf77fa0 100644
>> --- a/doc/users-guide/users-guide.adoc
>> +++ b/doc/users-guide/users-guide.adoc
>> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>>  Abstract
>>  
>>  This document is intended to guide a new ODP application developer.
>> -Further details about ODP may be found at then http://opendataplane.org[ODP]
>> home page.
>> +Further details about ODP may be found at the http://opendataplane.org[ODP]
>> home page.
>>
>>  .Overview of a system running ODP applications
>>  image::../images/overview.png[align="center"]
>> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>>  ODP is an API specification that allows many implementations to provide
>> platform independence, automatic hardware acceleration and CPU scaling to
>> high performance networking  applications.
>>  This document describes how to write an application that can
>> successfully take advantage of the API.
>>
>> +:numbered:
>> +== Introduction ==
>> +.OpenDataPlane Components
>> +image::../images/odp_components.png[align="center"]
>> +
>> +.The ODP API Specification
>> +ODP consists of three separate but related component parts. First, ODP
>> is an
>> +abstract API specification that describes a functional model for
>> +data plane applications. This specification covers many common data plane
>> +application programming needs, such as the ability to receive,
>> manipulate, and
>> +transmit packet data, without specifying how these functions are
>> performed. This
>> +is quite intentional. It is precisely because ODP APIs do not have a
>> preferred
>> +embodiment that they permit innovation in how these functions can
>> +be realized on various platforms that offer implementations of ODP. To
>> achieve
>> +this goal, ODP APIs are described using abstract data types whose
>> definition
>> +is left up to the ODP implementer.  For example, in ODP packets are
>> referenced
>> +by abstract handles of type +odp_packet_t+, and packet-related APIs take
>> +arguments of this type. What an +odp_packet_t+ actually is is not part
>> of the
>> +ODP API specification--that is the responsibility of each ODP
>> implementation.
>> +
>> +.Summary: ODP API attributes:
>> +* Open Source, open contribution, BSD-3 licensed.
>> +* Vendor and platform neutral.
>> +* Application-centric.  Covers functional needs of data plane
>> applications.
>> +* Ensures portability by specifying the functional behavior of ODP.
>> +* Defined jointly and openly by application writers and platform
>> implementers.
>> +* Archiected to be implementable on a wide range of platforms efficiently
>> +* Sponsored, governed, and maintained by the Linaro Networking Group
>> (LNG)
>> +
>> +.ODP Implementations
>> +Second, ODP consists of multiple implementations of this API
>> specification,
>> +each tailored to a specific target platform. ODP implementations
>> determine
>> +how each ODP abstract type is represented on that platform and how each
>> ODP
>> +API is realized. On some platforms, ODP APIs will
>> +be realized using specialized instructions that accelerate the functional
>> +behavior specified by the API. On others, hardware co-processing engines
>> may
>> +completely offload the API so that again it can be performed with little
>> or no
>> +involvement by a CPU. In all cases, the application sees the same
>> +functional behavior independent of how a given platform has chosen to
>> realize
>> +it. By allowing each platform the freedom to determine how best to
>> realize each
>> +API's specified functional behavior in an optimal manner, ODP permits
>> +applications written to its APIs to take full advantage of the unique
>> +capabilities of each platform without the application programmer needing
>> to
>> +have specialist knowledge of that platform or to be concerned with how
>> best
>> +to tune the application to a particular platform. This latter
>> consideration is
>> +particularly important in Network Function Virtualization (NFV)
>> environments
>> +where the application will run on a target platform chosen by someone
>> else.
>> +
>> +.Summary: ODP Implementation

[lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

2015-11-17 Thread Zoltan Kiss


Hi all,

Our odp_init_global() has a second parameter with type 
odp_platform_init_t. It's supposed to convey platform specific init 
parameters, however neither linux-generic nor linux-dpdk uses that. In 
the latter we use instead the ODP_PLATFORM_PARAMS environment variable. 
It has the little advantage that you don't have to modify your 
application's code, but it limits you to strings. In case of ODP-OVS we 
store this in OVSDB and retrieve it from the startup script (or specify 
it manually if you don't use the startup script.)
I'm tempted to change ODP-OVS and ODP-DPDK to use odp_platform_init_t, 
would be cleaner for OVS and for any bigger application which have a 
nice, full-fledged config database solution. But that would immediately 
bring us a bigger problem: none of our unit tests or example 
applications supports passing this parameter at all. They are small 
applications, implementing a proper config management would be an 
overkill. I have two options to solve this:


Apart from keeping the odp_platform_init_t type to be passed 
odp_init_global()


A) change our code in linux-generic for examples and tests (>20 places 
in the repo) to get the platform parameters from ODP_PLATFORM_PARAMS env 
variable, and pass it down to odp_init_global() as a string.


B) Or just allow a platform to use both ways, document this, and require 
that if both are present, the odp_platform_init_t passed as parameter 
should take precedence. So smaller applications using simply 
configurable platforms (like ODP-DPDK) don't have to figure out a way to 
deal with this problem.


I have a slight preference towards B), but I could be convinced that 
it's a bad idea to have 2 ways to do the same thing.


Thoughts?

Zoltan
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Mike Holmes

General comments to hash as we get docs moving.

   - I think this would be a lot easier to review in smaller pieces, a
   section at a time, for future patches I think we should do that. Images
   should go in first and  it occurs to me we never add an image that is not
   used in a doc - maybe images and their use in the doc are a single patch ?
   If there are not too many objections I can live with these two patches as
   they are though.
   - We should pick one heading tag style, I have no preference but you and
   I differ currently in this doc so we should convert them all to the same
   style
   - We should pick a line style, again we differ. I put one sentence per
   line as we try to do with doxygen so that git diffs are per logical
   sentence rather than being slightly more random diffs of clumps of chars.
   The down side it in raw form the doc looks a little longer - but I think
   the diff ability makes it worth it.
   - Also this patch has introduced highlighting for ODP types and enums
   using "+" which I like, but is it not used consistently with the initial
   doc, If we are going to use this I think we should update the existing doc
   to use them also.


On 17 November 2015 at 12:15, Bill Fischofer 
wrote:

> Add a basic ODP overview to the User's Guide, providing
> an overview of ODP concepts, components, etc. Included
> are a number of diagrams covering component structure
> as well as packet RX, event scheduling, and packet TX
> processing.
>
> Signed-off-by: Bill Fischofer 
> ---
>  doc/users-guide/users-guide.adoc | 400
> ++-
>  1 file changed, 398 insertions(+), 2 deletions(-)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 7f70046..cf77fa0 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>  Abstract
>  
>  This document is intended to guide a new ODP application developer.
> -Further details about ODP may be found at then http://opendataplane.org[ODP]
> home page.
> +Further details about ODP may be found at the http://opendataplane.org[ODP]
> home page.
>
>  .Overview of a system running ODP applications
>  image::../images/overview.png[align="center"]
> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>  ODP is an API specification that allows many implementations to provide
> platform independence, automatic hardware acceleration and CPU scaling to
> high performance networking  applications.
>  This document describes how to write an application that can successfully
> take advantage of the API.
>
> +:numbered:
> +== Introduction ==
> +.OpenDataPlane Components
> +image::../images/odp_components.png[align="center"]
> +
> +.The ODP API Specification
> +ODP consists of three separate but related component parts. First, ODP is
> an
> +abstract API specification that describes a functional model for
> +data plane applications. This specification covers many common data plane
> +application programming needs, such as the ability to receive,
> manipulate, and
> +transmit packet data, without specifying how these functions are
> performed. This
> +is quite intentional. It is precisely because ODP APIs do not have a
> preferred
> +embodiment that they permit innovation in how these functions can
> +be realized on various platforms that offer implementations of ODP. To
> achieve
> +this goal, ODP APIs are described using abstract data types whose
> definition
> +is left up to the ODP implementer.  For example, in ODP packets are
> referenced
> +by abstract handles of type +odp_packet_t+, and packet-related APIs take
> +arguments of this type. What an +odp_packet_t+ actually is is not part of
> the
> +ODP API specification--that is the responsibility of each ODP
> implementation.
> +
> +.Summary: ODP API attributes:
> +* Open Source, open contribution, BSD-3 licensed.
> +* Vendor and platform neutral.
> +* Application-centric.  Covers functional needs of data plane
> applications.
> +* Ensures portability by specifying the functional behavior of ODP.
> +* Defined jointly and openly by application writers and platform
> implementers.
> +* Archiected

to be implementable on a wide range of platforms efficiently
> +* Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
> +
> +.ODP Implementations
> +Second, ODP consists of multiple implementations of this API
> specification,
> +each tailored to a specific target platform. ODP implementations determine
> +how each ODP abstract type is represented on that platform and how each
> ODP
> +API is realized. On some platforms, ODP APIs will
> +be realized using specialized instructions that accelerate the functional
> +behavior specified by the API. On others, hardware co-processing engines
> may
> +completely offload the API so that again it can be performed with little
>

[lng-odp] [API-NEXT PATCHv12 1/3] api: tm: add tm API definitions

2015-11-17 Thread Bill Fischofer

This introduces an API for configuring and using Traffic Management
systems.

The purpose of this API is as a general packet scheduling system that
accepts packets from input queues and applies strict priority
scheduling, weighted fair queuing scheduling and/or bandwidth controls
to decide which input packet should be chosen as the next output
packet and when this output packet can be sent onwards.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 include/odp.h  |1 +
 include/odp/api/packet.h   |   69 +
 include/odp/api/traffic_mngr.h | 1611 
 platform/linux-generic/Makefile.am |3 +
 .../linux-generic/include/odp/plat/packet_types.h  |   11 +
 .../include/odp/plat/traffic_mngr_types.h  |  185 +++
 platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
 .../linux-generic/include/odp_packet_internal.h|5 +
 8 files changed, 1920 insertions(+)
 create mode 100644 include/odp/api/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp/plat/traffic_mngr_types.h
 create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h

diff --git a/include/odp.h b/include/odp.h
index 2adcb8b..4a93c23 100644
--- a/include/odp.h
+++ b/include/odp.h
@@ -55,6 +55,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
index 85cc9c9..9c63b5f 100644
--- a/include/odp/api/packet.h
+++ b/include/odp/api/packet.h
@@ -48,6 +48,26 @@ extern "C" {
  * Invalid packet segment
  */
 
+ /**
+  * @typedef odp_packet_color_t
+  * Color of packet for shaper/drop processing
+  */
+
+ /**
+  * @def ODP_PACKET_GREEN
+  * Packet is green
+  */
+
+ /**
+  * @def ODP_PACKET_YELLOW
+  * Packet is yellow
+  */
+
+ /**
+  * @def ODP_PACKET_RED
+  * Packet is red
+  */
+
 /*
  *
  * Alloc and free
@@ -729,6 +749,55 @@ odp_packet_seg_t odp_packet_last_seg(odp_packet_t pkt);
  */
 odp_packet_seg_t odp_packet_next_seg(odp_packet_t pkt, odp_packet_seg_t seg);
 
+/**
+ * Get packet color
+ *
+ * @param pkt Packet handle
+ * @return packet color
+ */
+odp_packet_color_t odp_packet_color(odp_packet_t pkt);
+
+/**
+ * Set packet color
+ *
+ * @param pkt Packet handle
+ * @param color Color to set
+ */
+void odp_packet_color_set(odp_packet_t pkt, odp_packet_color_t color);
+
+/**
+ * Get drop eligible status
+ *
+ * @param pkt Packet handle
+ * @return Packet drop eligibility status
+ * @retval 0 Packet is not drop eligible
+ * @retval 1 Packet is drop
+ */
+odp_bool_t odp_packet_drop_eligible(odp_packet_t pkt);
+
+/**
+ * Set drop eligible status
+ *
+ * @param pkt Packet handle
+ * @param status Drop eligibility status
+ */
+void odp_packet_drop_eligible_set(odp_packet_t pkt, odp_bool_t status);
+
+/**
+ * Get shaper length adjustment
+ *
+ * @param pkt Packet handle
+ * @return Shaper adjustment (-128..127)
+ */
+int8_t odp_packet_shaper_len_adjust(odp_packet_t pkt);
+
+/**
+ * Set shaper length adjustment
+ *
+ * @param pkt Packet handle
+ * @param adj Signed adjustment value
+ */
+void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, int8_t adj);
 
 /*
  *
diff --git a/include/odp/api/traffic_mngr.h b/include/odp/api/traffic_mngr.h
new file mode 100644
index 000..2459a8b
--- /dev/null
+++ b/include/odp/api/traffic_mngr.h
@@ -0,0 +1,1611 @@
+/** Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_TRAFFIC_MNGR_H_
+#define ODP_TRAFFIC_MNGR_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+
+/**
+ * @file
+ *
+ */
+
+/** @defgroup odp_traffic_mngr ODP TRAFFIC MNGR
+ * @{
+ *
+ * An API for configuring and using Traffic Management systems
+ *
+ * This file forms a simple interface for creating, configuring and using
+ * Traffic Management (TM) subsystems.  By TM subsystem it is meant a general
+ * packet scheduling system that accepts packets from input queues and applies
+ * strict priority scheduling, weighted fair queueing scheduling and/or
+ * bandwidth controls to decide which input packet should be chosen as the
+ * next output packet and when this output packet can be sent onwards.
+ *
+ * A given platform supporting this TM API could support one or more pure
+ * hardware based packet scheduling systems, one or more pure software
+ * based systems or one or more hybrid systems - where because of
+ * hardware constraints some of the packet scheduling is done in hardware
+ * and some is done in software.  In addition, there may also be additional
+ * API's beyond those described here for (a) controlling advanced capabilities
+ * supported by specific hardware, software or hybrid subsystems or (b)
+ * dealing with constraints and limitations of specific implementations.
+ * The intention here is to be the simplest API that

[lng-odp] [API-NEXT PATCHv12 0/3] Egress Traffic Manager

2015-11-17 Thread Bill Fischofer

Changes in v12
- Refactor to enable serial apply-and-build

Changes in v11
- Squash Parts 2 and 3 to give new Part 2 that can build independently
- Change typedef for hash_table_entry_t to uint64_t for 32-bit support

Changes in v10
- Add back ARM definitions for _crc32w() from Alex that got dropped in v9

Note: Checkpatch complains about the _asm() line.  Says spaces are needed but
if spaces are added then complains that spaces are prohibited.  Rules need to
be updated to ignore these sort of constructs.

Changes in v9
- Rebase on top of latest queue fixes

Changes in v8
- add ARM definition for __crc32w() function (from Alex)

Changes in v7 (review comments by Maxim)
- Correct architecture ifdefs (use of arch dir in later patch)
- Correct doxygen for queue types
- Change internal APIs that use odp_ prefix to use _odp prefix
- Rebase to latest api-next

Changes in v6
- Move documentation of packet colors to main API file
- Add ODP prefix to odp_tm_egress_kind_t enums

Changes in v5
- Add include file odp_traffic_mngr_internal.h
- Add support for odp_tm_enq() from packets originating from ordered queues

Changes in v4
- Incorporate API changes suggested by Petri

Changes in v3
- Fix checkpatch errors (Bill)

Changes in v2
- Full patch submission (Barry)

Barry Spinney (3):
  api: tm: add tm API definitions
  linux-generic: tm: implement traffic manager
  example: tm: traffic manager example

 configure.ac   |1 +
 example/Makefile.am|2 +-
 example/traffic_mgmt/.gitignore|1 +
 example/traffic_mgmt/Makefile.am   |9 +
 example/traffic_mgmt/odp_traffic_mgmt.c|  781 ++
 include/odp.h  |1 +
 include/odp/api/packet.h   |   69 +
 include/odp/api/traffic_mngr.h | 1611 +++
 platform/linux-generic/Makefile.am |   13 +
 .../linux-generic/include/odp/plat/packet_types.h  |   11 +
 .../linux-generic/include/odp/plat/queue_types.h   |7 +
 .../include/odp/plat/traffic_mngr_types.h  |  185 ++
 platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
 platform/linux-generic/include/odp_internal.h  |2 +
 .../include/odp_name_table_internal.h  |   61 +
 .../linux-generic/include/odp_packet_internal.h|5 +
 .../linux-generic/include/odp_pkt_queue_internal.h |   62 +
 .../linux-generic/include/odp_queue_internal.h |6 +
 .../include/odp_sorted_list_internal.h |   78 +
 .../include/odp_timer_wheel_internal.h |   68 +
 .../include/odp_traffic_mngr_internal.h|  324 +++
 platform/linux-generic/odp_init.c  |5 +
 platform/linux-generic/odp_name_table.c| 1371 ++
 platform/linux-generic/odp_packet_flags.c  |   46 +-
 platform/linux-generic/odp_pkt_queue.c |  379 +++
 platform/linux-generic/odp_queue.c |   60 +
 platform/linux-generic/odp_sorted_list.c   |  271 ++
 platform/linux-generic/odp_timer_wheel.c   |  907 +++
 platform/linux-generic/odp_traffic_mngr.c  | 2799 
 29 files changed, 9168 insertions(+), 2 deletions(-)
 create mode 100644 example/traffic_mgmt/.gitignore
 create mode 100644 example/traffic_mgmt/Makefile.am
 create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c
 create mode 100644 include/odp/api/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp/plat/traffic_mngr_types.h
 create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp_name_table_internal.h
 create mode 100644 platform/linux-generic/include/odp_pkt_queue_internal.h
 create mode 100644 platform/linux-generic/include/odp_sorted_list_internal.h
 create mode 100644 platform/linux-generic/include/odp_timer_wheel_internal.h
 create mode 100644 platform/linux-generic/include/odp_traffic_mngr_internal.h
 create mode 100644 platform/linux-generic/odp_name_table.c
 create mode 100644 platform/linux-generic/odp_pkt_queue.c
 create mode 100644 platform/linux-generic/odp_sorted_list.c
 create mode 100644 platform/linux-generic/odp_timer_wheel.c
 create mode 100644 platform/linux-generic/odp_traffic_mngr.c

-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv3 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

Add a basic ODP overview to the User's Guide, providing
an overview of ODP concepts, components, etc. Included
are a number of diagrams covering component structure
as well as packet RX, event scheduling, and packet TX
processing.

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/users-guide.adoc | 409 ++-
 1 file changed, 407 insertions(+), 2 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 7f70046..5cc6395 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
 Abstract
 
 This document is intended to guide a new ODP application developer.
-Further details about ODP may be found at then http://opendataplane.org[ODP] 
home page.
+Further details about ODP may be found at the http://opendataplane.org[ODP] 
home page.
 
 .Overview of a system running ODP applications
 image::../images/overview.png[align="center"]
@@ -16,6 +16,412 @@ image::../images/overview.png[align="center"]
 ODP is an API specification that allows many implementations to provide 
platform independence, automatic hardware acceleration and CPU scaling to high 
performance networking  applications.
 This document describes how to write an application that can successfully take 
advantage of the API.
 
+:numbered:
+== Introduction ==
+.OpenDataPlane Components
+image::../images/odp_components.png[align="center"]
+
+.The ODP API Specification
+ODP consists of three separate but related component parts. First, ODP is an
+abstract API specification that describes a functional model for
+data plane applications. This specification covers many common data plane
+application programming needs, such as the ability to receive, manipulate, and
+transmit packet data, without specifying how these functions are performed. 
This
+is quite intentional. It is precisely because ODP APIs do not have a preferred
+embodiment that they permit innovation in how these functions can
+be realized on various platforms that offer implementations of ODP. To achieve
+this goal, ODP APIs are described using abstract data types whose definition
+is left up to the ODP implementer.  For example, in ODP packets are referenced
+by abstract handles of type +odp_packet_t+, and packet-related APIs take
+arguments of this type. What an +odp_packet_t+ actually is is not part of the
+ODP API specification--that is the responsibility of each ODP implementation.
+
+.Summary: ODP API attributes:
+* Open Source, open contribution, BSD-3 licensed.
+* Vendor and platform neutral.
+* Application-centric.  Covers functional needs of data plane applications.
+* Ensures portability by specifying the functional behavior of ODP.
+* Defined jointly and openly by application writers and platform implementers.
+* Architected to be implementable on a wide range of platforms efficiently
+* Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
+
+.ODP Implementations
+Second, ODP consists of multiple implementations of this API specification,
+each tailored to a specific target platform. ODP implementations determine
+how each ODP abstract type is represented on that platform and how each ODP
+API is realized. On some platforms, ODP APIs will
+be realized using specialized instructions that accelerate the functional
+behavior specified by the API. On others, hardware co-processing engines may
+completely offload the API so that again it can be performed with little or no
+involvement by a CPU. In all cases, the application sees the same
+functional behavior independent of how a given platform has chosen to realize
+it. By allowing each platform the freedom to determine how best to realize each
+API's specified functional behavior in an optimal manner, ODP permits
+applications written to its APIs to take full advantage of the unique
+capabilities of each platform without the application programmer needing to
+have specialist knowledge of that platform or to be concerned with how best
+to tune the application to a particular platform. This latter consideration is
+particularly important in Network Function Virtualization (NFV) environments
+where the application will run on a target platform chosen by someone else.
+
+.Summary: ODP Implementation Characteristics
+* One size does not fit all--supporting multiple implementations allows ODP
+to adapt to widely differing internals among platforms.
+* Anyone can create an ODP implementation tailored to their platform
+* Distribution and maintenance of each implementation is as owner wishes
+  - Open source or closed source as business needs determine
+  - Have independent release cycles and service streams
+* Allows HW and SW innovation in how ODP APIs are implemented on each platform.
+
+.Reference Implementations
+To make it easy to get started with implementing ODP on a new platform, ODP
+supplies a number of _reference

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

Thanks for the spelling corrections.  v4 submitted (v3 still had a typo)
that corrects these and others and adds the list you suggested.  Other
comments inline:

On Tue, Nov 17, 2015 at 12:52 PM, Mike Holmes 
wrote:

> General comments to hash as we get docs moving.
>
>- I think this would be a lot easier to review in smaller pieces, a
>section at a time, for future patches I think we should do that. Images
>should go in first and  it occurs to me we never add an image that is not
>used in a doc - maybe images and their use in the doc are a single patch ?
>If there are not too many objections I can live with these two patches as
>they are though.
>
> In general I agree, which is why I stopped here.  I don't think we want to
be too strict here, however.  This isn't code and isn't subject to
bisection.  Images should be in a separate patch because they are large and
non-reviewable in unrendered form since they are binary.  Putting them in
with the text portions just adds clutter for reviewers.


>-
>- We should pick one heading tag style, I have no preference but you
>and I differ currently in this doc so we should convert them all to the
>same style
>
> Agreed.  I prefer the == style since it's very clear that = is 1st level
header == is 2nd etc.  Using -, +, ~, etc. it's not obvious which is what
level. I can submit a patch to standardize on this style.


>
>-
>- We should pick a line style, again we differ. I put one sentence per
>line as we try to do with doxygen so that git diffs are per logical
>sentence rather than being slightly more random diffs of clumps of chars.
>The down side it in raw form the doc looks a little longer - but I think
>the diff ability makes it worth it.
>
> Strongly disagree.  The goal here is to make things readable for the human
writer and reviewer.  Keeping to natural line breaks and our checkpatch 80
char length guidelines do that.  Changes are to improve readability, not to
minimize the number of characters changed in some diff, which is a
completely arbitrary criteria that bears little relevance to how
documentation is intended to be used.  The whole point of using asciidoc is
to make the document source humanly readable.  That trumps all else.

>
>-
>- Also this patch has introduced highlighting for ODP types and enums
>using "+" which I like, but is it not used consistently with the initial
>doc, If we are going to use this I think we should update the existing doc
>to use them also.
>
> Again, additional patches can revise the existing portions of the doc to
standardize.


>
>-
>
> On 17 November 2015 at 12:15, Bill Fischofer 
> wrote:
>
>> Add a basic ODP overview to the User's Guide, providing
>> an overview of ODP concepts, components, etc. Included
>> are a number of diagrams covering component structure
>> as well as packet RX, event scheduling, and packet TX
>> processing.
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>>  doc/users-guide/users-guide.adoc | 400
>> ++-
>>  1 file changed, 398 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/users-guide/users-guide.adoc
>> b/doc/users-guide/users-guide.adoc
>> index 7f70046..cf77fa0 100644
>> --- a/doc/users-guide/users-guide.adoc
>> +++ b/doc/users-guide/users-guide.adoc
>> @@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
>>  Abstract
>>  
>>  This document is intended to guide a new ODP application developer.
>> -Further details about ODP may be found at then http://opendataplane.org[ODP]
>> home page.
>> +Further details about ODP may be found at the http://opendataplane.org[ODP]
>> home page.
>>
>>  .Overview of a system running ODP applications
>>  image::../images/overview.png[align="center"]
>> @@ -16,6 +16,403 @@ image::../images/overview.png[align="center"]
>>  ODP is an API specification that allows many implementations to provide
>> platform independence, automatic hardware acceleration and CPU scaling to
>> high performance networking  applications.
>>  This document describes how to write an application that can
>> successfully take advantage of the API.
>>
>> +:numbered:
>> +== Introduction ==
>> +.OpenDataPlane Components
>> +image::../images/odp_components.png[align="center"]
>> +
>> +.The ODP API Specification
>> +ODP consists of three separate but related component parts. First, ODP
>> is an
>> +abstract API specification that describes a functional model for
>> +data plane applications. This specification covers many common data plane
>> +application programming needs, such as the ability to receive,
>> manipulate, and
>> +transmit packet data, without specifying how these functions are
>> performed. This
>> +is quite intentional. It is precisely because ODP APIs do not have a
>> preferred
>> +embodiment that they permit innovation in how these functions can
>> +be realized on various

Re: [lng-odp] [PATCH] helper: test: add odp_table to .gitignore file

2015-11-17 Thread Mike Holmes

On 17 November 2015 at 12:32, Bill Fischofer 
wrote:

> Signed-off-by: Bill Fischofer 
>

Reviewed-by: Mike Holmes 


> ---
>  helper/test/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/helper/test/.gitignore b/helper/test/.gitignore
> index 213bc5e..50a0da4 100644
> --- a/helper/test/.gitignore
> +++ b/helper/test/.gitignore
> @@ -2,5 +2,6 @@
>  *.log
>  odp_chksum
>  odp_process
> +odp_table
>  odp_thread
>  odph_pause
> --
> 2.1.4
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCHv4 2/2] doc: userguide: add baseline overview to document

2015-11-17 Thread Bill Fischofer

Add a basic ODP overview to the User's Guide, providing
an overview of ODP concepts, components, etc. Included
are a number of diagrams covering component structure
as well as packet RX, event scheduling, and packet TX
processing.

Signed-off-by: Bill Fischofer 
---
 doc/users-guide/users-guide.adoc | 409 ++-
 1 file changed, 407 insertions(+), 2 deletions(-)

diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 7f70046..be40d2f 100644
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -8,7 +8,7 @@ OpenDataPlane (ODP)  Users-Guide
 Abstract
 
 This document is intended to guide a new ODP application developer.
-Further details about ODP may be found at then http://opendataplane.org[ODP] 
home page.
+Further details about ODP may be found at the http://opendataplane.org[ODP] 
home page.
 
 .Overview of a system running ODP applications
 image::../images/overview.png[align="center"]
@@ -16,6 +16,412 @@ image::../images/overview.png[align="center"]
 ODP is an API specification that allows many implementations to provide 
platform independence, automatic hardware acceleration and CPU scaling to high 
performance networking  applications.
 This document describes how to write an application that can successfully take 
advantage of the API.
 
+:numbered:
+== Introduction ==
+.OpenDataPlane Components
+image::../images/odp_components.png[align="center"]
+
+.The ODP API Specification
+ODP consists of three separate but related component parts. First, ODP is an
+abstract API specification that describes a functional model for
+data plane applications. This specification covers many common data plane
+application programming needs, such as the ability to receive, manipulate, and
+transmit packet data, without specifying how these functions are performed. 
This
+is quite intentional. It is precisely because ODP APIs do not have a preferred
+embodiment that they permit innovation in how these functions can
+be realized on various platforms that offer implementations of ODP. To achieve
+this goal, ODP APIs are described using abstract data types whose definition
+is left up to the ODP implementer.  For example, in ODP packets are referenced
+by abstract handles of type +odp_packet_t+, and packet-related APIs take
+arguments of this type. What an +odp_packet_t+ actually is is not part of the
+ODP API specification--that is the responsibility of each ODP implementation.
+
+.Summary: ODP API attributes:
+* Open Source, open contribution, BSD-3 licensed.
+* Vendor and platform neutral.
+* Application-centric.  Covers functional needs of data plane applications.
+* Ensures portability by specifying the functional behavior of ODP.
+* Defined jointly and openly by application writers and platform implementers.
+* Architected to be implementable on a wide range of platforms efficiently
+* Sponsored, governed, and maintained by the Linaro Networking Group (LNG)
+
+.ODP Implementations
+Second, ODP consists of multiple implementations of this API specification,
+each tailored to a specific target platform. ODP implementations determine
+how each ODP abstract type is represented on that platform and how each ODP
+API is realized. On some platforms, ODP APIs will
+be realized using specialized instructions that accelerate the functional
+behavior specified by the API. On others, hardware co-processing engines may
+completely offload the API so that again it can be performed with little or no
+involvement by a CPU. In all cases, the application sees the same
+functional behavior independent of how a given platform has chosen to realize
+it. By allowing each platform the freedom to determine how best to realize each
+API's specified functional behavior in an optimal manner, ODP permits
+applications written to its APIs to take full advantage of the unique
+capabilities of each platform without the application programmer needing to
+have specialist knowledge of that platform or to be concerned with how best
+to tune the application to a particular platform. This latter consideration is
+particularly important in Network Function Virtualization (NFV) environments
+where the application will run on a target platform chosen by someone else.
+
+.Summary: ODP Implementation Characteristics
+* One size does not fit all--supporting multiple implementations allows ODP
+to adapt to widely differing internals among platforms.
+* Anyone can create an ODP implementation tailored to their platform
+* Distribution and maintenance of each implementation is as owner wishes
+  - Open source or closed source as business needs determine
+  - Have independent release cycles and service streams
+* Allows HW and SW innovation in how ODP APIs are implemented on each platform.
+
+.Reference Implementations
+To make it easy to get started with implementing ODP on a new platform, ODP
+supplies a number of _reference

Re: [lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

2015-11-17 Thread Bill Fischofer

I vote for B.  The idea is that if the application wishes to override it
can do so otherwise let the implementation take its defaults from the
environment or however else it wishes to support platform-specific
configuration options.  This is in keeping with how we handle other
overridable defaults for things like log and abort functions.  Specify NULL
== accept whatever default behavior is in effect, otherwise specify what
you want.  Simpler for everyone.

On Tue, Nov 17, 2015 at 1:05 PM, Mike Holmes  wrote:

>
>
> On 17 November 2015 at 13:54, Zoltan Kiss  wrote:
>
>> Hi all,
>>
>> Our odp_init_global() has a second parameter with type
>> odp_platform_init_t. It's supposed to convey platform specific init
>> parameters, however neither linux-generic nor linux-dpdk uses that. In the
>> latter we use instead the ODP_PLATFORM_PARAMS environment variable. It has
>> the little advantage that you don't have to modify your application's code,
>> but it limits you to strings. In case of ODP-OVS we store this in OVSDB and
>> retrieve it from the startup script (or specify it manually if you don't
>> use the startup script.)
>> I'm tempted to change ODP-OVS and ODP-DPDK to use odp_platform_init_t,
>> would be cleaner for OVS and for any bigger application which have a nice,
>> full-fledged config database solution. But that would immediately bring us
>> a bigger problem: none of our unit tests or example applications supports
>> passing this parameter at all. They are small applications, implementing a
>> proper config management would be an overkill. I have two options to solve
>> this:
>>
>> Apart from keeping the odp_platform_init_t type to be passed
>> odp_init_global()
>>
>> A) change our code in linux-generic for examples and tests (>20 places in
>> the repo) to get the platform parameters from ODP_PLATFORM_PARAMS env
>> variable, and pass it down to odp_init_global() as a string.
>>
>> B) Or just allow a platform to use both ways, document this, and require
>> that if both are present, the odp_platform_init_t passed as parameter
>> should take precedence. So smaller applications using simply configurable
>> platforms (like ODP-DPDK) don't have to figure out a way to deal with this
>> problem.
>>
>> I have a slight preference towards B), but I could be convinced that it's
>> a bad idea to have 2 ways to do the same thing.
>>
>
> I like A, two ways always feels bad to me.
> I like that it is explicitly passed in and you know what you have. Env
> vars can change without the difference being seen in the code as easily and
> not all OS'es have env vars. Env vars are a great way to do system
> dependent things but I think the application should translate them into the
> odp_platform_init_t so that the fudging is the apps problem and the app
> knows more about the portability compromises it is making when using
> platform specifics.
>
>
>>
>> Thoughts?
>>
>> Zoltan
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
>
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

2015-11-17 Thread Mike Holmes

On 17 November 2015 at 13:54, Zoltan Kiss  wrote:

> Hi all,
>
> Our odp_init_global() has a second parameter with type
> odp_platform_init_t. It's supposed to convey platform specific init
> parameters, however neither linux-generic nor linux-dpdk uses that. In the
> latter we use instead the ODP_PLATFORM_PARAMS environment variable. It has
> the little advantage that you don't have to modify your application's code,
> but it limits you to strings. In case of ODP-OVS we store this in OVSDB and
> retrieve it from the startup script (or specify it manually if you don't
> use the startup script.)
> I'm tempted to change ODP-OVS and ODP-DPDK to use odp_platform_init_t,
> would be cleaner for OVS and for any bigger application which have a nice,
> full-fledged config database solution. But that would immediately bring us
> a bigger problem: none of our unit tests or example applications supports
> passing this parameter at all. They are small applications, implementing a
> proper config management would be an overkill. I have two options to solve
> this:
>
> Apart from keeping the odp_platform_init_t type to be passed
> odp_init_global()
>
> A) change our code in linux-generic for examples and tests (>20 places in
> the repo) to get the platform parameters from ODP_PLATFORM_PARAMS env
> variable, and pass it down to odp_init_global() as a string.
>
> B) Or just allow a platform to use both ways, document this, and require
> that if both are present, the odp_platform_init_t passed as parameter
> should take precedence. So smaller applications using simply configurable
> platforms (like ODP-DPDK) don't have to figure out a way to deal with this
> problem.
>
> I have a slight preference towards B), but I could be convinced that it's
> a bad idea to have 2 ways to do the same thing.
>

I like A, two ways always feels bad to me.
I like that it is explicitly passed in and you know what you have. Env vars
can change without the difference being seen in the code as easily and not
all OS'es have env vars. Env vars are a great way to do system dependent
things but I think the application should translate them into the
odp_platform_init_t so that the fudging is the apps problem and the app
knows more about the portability compromises it is making when using
platform specifics.


>
> Thoughts?
>
> Zoltan
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

2015-11-17 Thread Bill Fischofer

Changes in v11
- Squash Parts 2 and 3 to give new Part 2 that can build independently
- Change typedef for hash_table_entry_t to uint64_t for 32-bit support

Changes in v10
- Add back ARM definitions for _crc32w() from Alex that got dropped in v9

Note: Checkpatch complains about the _asm() line.  Says spaces are needed but
if spaces are added then complains that spaces are prohibited.  Rules need to
be updated to ignore these sort of constructs.

Changes in v9
- Rebase on top of latest queue fixes

Changes in v8
- add ARM definition for __crc32w() function (from Alex)

Changes in v7 (review comments by Maxim)
- Correct architecture ifdefs (use of arch dir in later patch)
- Correct doxygen for queue types
- Change internal APIs that use odp_ prefix to use _odp prefix
- Rebase to latest api-next

Changes in v6
- Move documentation of packet colors to main API file
- Add ODP prefix to odp_tm_egress_kind_t enums

Changes in v5
- Add include file odp_traffic_mngr_internal.h
- Add support for odp_tm_enq() from packets originating from ordered queues

Changes in v4
- Incorporate API changes suggested by Petri

Changes in v3
- Fix checkpatch errors (Bill)

Changes in v2
- Full patch submission (Barry)

Barry Spinney (3):
  api: tm: add tm API definitions
  linux-generic: tm: implement traffic manager
  example: tm: traffic manager example

 configure.ac   |1 +
 example/Makefile.am|2 +-
 example/traffic_mgmt/.gitignore|1 +
 example/traffic_mgmt/Makefile.am   |9 +
 example/traffic_mgmt/odp_traffic_mgmt.c|  781 ++
 include/odp.h  |1 +
 include/odp/api/packet.h   |   69 +
 include/odp/api/traffic_mngr.h | 1611 +++
 platform/linux-generic/Makefile.am |   13 +
 .../linux-generic/include/odp/plat/packet_types.h  |   11 +
 .../linux-generic/include/odp/plat/queue_types.h   |7 +
 .../include/odp/plat/traffic_mngr_types.h  |  185 ++
 platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
 platform/linux-generic/include/odp_internal.h  |2 +
 .../include/odp_name_table_internal.h  |   61 +
 .../linux-generic/include/odp_packet_internal.h|5 +
 .../linux-generic/include/odp_pkt_queue_internal.h |   62 +
 .../linux-generic/include/odp_queue_internal.h |6 +
 .../include/odp_sorted_list_internal.h |   78 +
 .../include/odp_timer_wheel_internal.h |   68 +
 .../include/odp_traffic_mngr_internal.h|  324 +++
 platform/linux-generic/odp_init.c  |5 +
 platform/linux-generic/odp_name_table.c| 1371 ++
 platform/linux-generic/odp_packet_flags.c  |   46 +-
 platform/linux-generic/odp_pkt_queue.c |  379 +++
 platform/linux-generic/odp_queue.c |   60 +
 platform/linux-generic/odp_sorted_list.c   |  271 ++
 platform/linux-generic/odp_timer_wheel.c   |  907 +++
 platform/linux-generic/odp_traffic_mngr.c  | 2799 
 29 files changed, 9168 insertions(+), 2 deletions(-)
 create mode 100644 example/traffic_mgmt/.gitignore
 create mode 100644 example/traffic_mgmt/Makefile.am
 create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c
 create mode 100644 include/odp/api/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp/plat/traffic_mngr_types.h
 create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp_name_table_internal.h
 create mode 100644 platform/linux-generic/include/odp_pkt_queue_internal.h
 create mode 100644 platform/linux-generic/include/odp_sorted_list_internal.h
 create mode 100644 platform/linux-generic/include/odp_timer_wheel_internal.h
 create mode 100644 platform/linux-generic/include/odp_traffic_mngr_internal.h
 create mode 100644 platform/linux-generic/odp_name_table.c
 create mode 100644 platform/linux-generic/odp_pkt_queue.c
 create mode 100644 platform/linux-generic/odp_sorted_list.c
 create mode 100644 platform/linux-generic/odp_timer_wheel.c
 create mode 100644 platform/linux-generic/odp_traffic_mngr.c

-- 
2.1.4

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [API-NEXT PATCHv12 3/3] example: tm: traffic manager example

2015-11-17 Thread Bill Fischofer

This commit includes all of the changes to build the traffic_mgr example
application.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/traffic_mgmt/.gitignore |   1 +
 example/traffic_mgmt/Makefile.am|   9 +
 example/traffic_mgmt/odp_traffic_mgmt.c | 781 
 5 files changed, 793 insertions(+), 1 deletion(-)
 create mode 100644 example/traffic_mgmt/.gitignore
 create mode 100644 example/traffic_mgmt/Makefile.am
 create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c

diff --git a/configure.ac b/configure.ac
index 2c47358..ae5395a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -325,6 +325,7 @@ AC_CONFIG_FILES([Makefile
 example/ipsec/Makefile
 example/packet/Makefile
 example/timer/Makefile
+example/traffic_mgmt/Makefile
 helper/Makefile
 helper/test/Makefile
 pkgconfig/libodp.pc
diff --git a/example/Makefile.am b/example/Makefile.am
index 353f397..6b67bf5 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = classifier generator ipsec packet timer
+SUBDIRS = classifier generator ipsec packet timer traffic_mgmt
diff --git a/example/traffic_mgmt/.gitignore b/example/traffic_mgmt/.gitignore
new file mode 100644
index 000..9e742f0
--- /dev/null
+++ b/example/traffic_mgmt/.gitignore
@@ -0,0 +1 @@
+odp_traffic_mgmt
\ No newline at end of file
diff --git a/example/traffic_mgmt/Makefile.am b/example/traffic_mgmt/Makefile.am
new file mode 100644
index 000..c8ff797
--- /dev/null
+++ b/example/traffic_mgmt/Makefile.am
@@ -0,0 +1,9 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_traffic_mgmt$(EXEEXT)
+odp_traffic_mgmt_LDFLAGS = $(AM_LDFLAGS) -static
+odp_traffic_mgmt_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = $(top_srcdir)/example/example_debug.h
+
+dist_odp_traffic_mgmt_SOURCES = odp_traffic_mgmt.c
diff --git a/example/traffic_mgmt/odp_traffic_mgmt.c 
b/example/traffic_mgmt/odp_traffic_mgmt.c
new file mode 100644
index 000..37a85c7
--- /dev/null
+++ b/example/traffic_mgmt/odp_traffic_mgmt.c
@@ -0,0 +1,781 @@
+/* Copyright 2015 EZchip Semiconductor Ltd. All Rights Reserved.
+ *
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_SVC_CLASSES 4
+#define USERS_PER_SVC_CLASS 2
+#define APPS_PER_USER   2
+#define TM_QUEUES_PER_APP   2
+#define NUM_USERS   (USERS_PER_SVC_CLASS * NUM_SVC_CLASSES)
+#define NUM_TM_QUEUES   (NUM_USERS * APPS_PER_USER * TM_QUEUES_PER_APP)
+#define TM_QUEUES_PER_USER  (TM_QUEUES_PER_APP * APPS_PER_USER)
+#define TM_QUEUES_PER_CLASS (USERS_PER_SVC_CLASS * TM_QUEUES_PER_USER)
+
+#define Kbps   1000
+#define Mbps   100
+#define PERCENT(percent)  (100 * percent)
+
+#define FALSE  0
+#define TRUE   1
+
+#define MAX(a, b) (((a) > (b)) ? (a) : (b))
+#define MIN(a, b) (((a) < (b)) ? (a) : (b))
+
+#define RANDOM_BUF_LEN  1024
+
+typedef struct {
+   odp_tm_shaper_params_tshaper_params;
+   odp_tm_threshold_params_t threshold_params;
+   odp_tm_wred_params_t  wred_params[ODP_NUM_PACKET_COLORS];
+} profile_params_set_t;
+
+typedef struct {
+   odp_tm_shaper_tshaper_profile;
+   odp_tm_threshold_t threshold_profile;
+   odp_tm_wred_t  wred_profiles[ODP_NUM_PACKET_COLORS];
+} profile_set_t;
+
+static const odp_init_t ODP_INIT_PARAMS = {
+   .log_fn   = odp_override_log,
+   .abort_fn = odp_override_abort
+};
+
+static const odp_platform_init_t PLATFORM_PARAMS = {
+};
+
+static profile_params_set_t COMPANY_PROFILE_PARAMS = {
+   .shaper_params = {
+   .commit_bps = 50  * Mbps,  .commit_burst  = 100,
+   .peak_bps   = 0,   .peak_burst= 0,
+   .dual_rate  = FALSE,   .shaper_len_adjust = 20
+   },
+
+   .threshold_params = {
+   .max_pkts  = 10,.enable_max_pkts  = TRUE,
+   .max_bytes = 1000,  .enable_max_bytes = TRUE
+   },
+
+   .wred_params = {
+   [ODP_PACKET_GREEN ... ODP_PACKET_YELLOW] = {
+   .min_threshold = PERCENT(70),
+   .med_threshold = PERCENT(90),
+   .med_drop_prob = PERCENT(80),
+   .max_drop_prob = PERCENT(100),
+   .enable_wred   = TRUE,
+   .use_byte_fullness = FALSE,
+   },
+
+   [ODP_PACKET_RED] = {
+   .min_threshold = PERCENT(40),
+   .med_threshold =

Re: [lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

2015-11-17 Thread Bill Fischofer

Sorry about that.  v12 submitted.  Passed apply-and-build and build-all for
me.

On Tue, Nov 17, 2015 at 4:31 PM, Mike Holmes  wrote:

> apply and build issues still show up for me - I used v11 - three patches
>
> ~/incoming/bill$ ls -l
> total 452
> -rw--- 1 mike mike 127026 Nov 17 17:17
> lng-odp_API-NEXT_PATCHv11_1-3_api_tm_add_tm_API_definitions.mbox
> -rw--- 1 mike mike 286282 Nov 17 17:17
> lng-odp_API-NEXT_PATCHv11_2-3_linux-generic_tm_implement_traffic_manager.mbox
> -rw--- 1 mike mike  41280 Nov 17 17:17
> lng-odp_API-NEXT_PATCHv11_3-3_example_tm_traffic_manager_example.mbox
>
> GIT_BRANCH=api-next PATCH_DIR=~/incoming/bill ./apply-and-build.sh
>
> ...
> odp_new_workdir: calling
> Branch git___git_linaro_org_lng_odp_git_api_next set up to track remote
> branch api-next from git___git_linaro_org_lng_odp_git.
> Switched to a new branch 'git___git_linaro_org_lng_odp_git_api_next'
> Cloning into '/home/mike/git/check-odp/build/odp-apply'...
> done.
> Building baseline: git://git.linaro.org/lng/odp.git
>
> ..
> In file included from ../../../../platform/linux-generic/pktio/loop.c:12:0:
> ../../../../include/odp.h:58:30: fatal error: odp/traffic_mngr.h: No such
> file or directory
>
>
> On 17 November 2015 at 15:40, Bill Fischofer 
> wrote:
>
>> Changes in v11
>> - Squash Parts 2 and 3 to give new Part 2 that can build independently
>> - Change typedef for hash_table_entry_t to uint64_t for 32-bit support
>>
>> Changes in v10
>> - Add back ARM definitions for _crc32w() from Alex that got dropped in v9
>>
>> Note: Checkpatch complains about the _asm() line.  Says spaces are needed
>> but
>> if spaces are added then complains that spaces are prohibited.  Rules
>> need to
>> be updated to ignore these sort of constructs.
>>
>> Changes in v9
>> - Rebase on top of latest queue fixes
>>
>> Changes in v8
>> - add ARM definition for __crc32w() function (from Alex)
>>
>> Changes in v7 (review comments by Maxim)
>> - Correct architecture ifdefs (use of arch dir in later patch)
>> - Correct doxygen for queue types
>> - Change internal APIs that use odp_ prefix to use _odp prefix
>> - Rebase to latest api-next
>>
>> Changes in v6
>> - Move documentation of packet colors to main API file
>> - Add ODP prefix to odp_tm_egress_kind_t enums
>>
>> Changes in v5
>> - Add include file odp_traffic_mngr_internal.h
>> - Add support for odp_tm_enq() from packets originating from ordered
>> queues
>>
>> Changes in v4
>> - Incorporate API changes suggested by Petri
>>
>> Changes in v3
>> - Fix checkpatch errors (Bill)
>>
>> Changes in v2
>> - Full patch submission (Barry)
>>
>> Barry Spinney (3):
>>   api: tm: add tm API definitions
>>   linux-generic: tm: implement traffic manager
>>   example: tm: traffic manager example
>>
>>  configure.ac   |1 +
>>  example/Makefile.am|2 +-
>>  example/traffic_mgmt/.gitignore|1 +
>>  example/traffic_mgmt/Makefile.am   |9 +
>>  example/traffic_mgmt/odp_traffic_mgmt.c|  781 ++
>>  include/odp.h  |1 +
>>  include/odp/api/packet.h   |   69 +
>>  include/odp/api/traffic_mngr.h | 1611 +++
>>  platform/linux-generic/Makefile.am |   13 +
>>  .../linux-generic/include/odp/plat/packet_types.h  |   11 +
>>  .../linux-generic/include/odp/plat/queue_types.h   |7 +
>>  .../include/odp/plat/traffic_mngr_types.h  |  185 ++
>>  platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
>>  platform/linux-generic/include/odp_internal.h  |2 +
>>  .../include/odp_name_table_internal.h  |   61 +
>>  .../linux-generic/include/odp_packet_internal.h|5 +
>>  .../linux-generic/include/odp_pkt_queue_internal.h |   62 +
>>  .../linux-generic/include/odp_queue_internal.h |6 +
>>  .../include/odp_sorted_list_internal.h |   78 +
>>  .../include/odp_timer_wheel_internal.h |   68 +
>>  .../include/odp_traffic_mngr_internal.h|  324 +++
>>  platform/linux-generic/odp_init.c  |5 +
>>  platform/linux-generic/odp_name_table.c| 1371 ++
>>  platform/linux-generic/odp_packet_flags.c  |   46 +-
>>  platform/linux-generic/odp_pkt_queue.c |  379 +++
>>  platform/linux-generic/odp_queue.c |   60 +
>>  platform/linux-generic/odp_sorted_list.c   |  271 ++
>>  platform/linux-generic/odp_timer_wheel.c   |  907 +++
>>  platform/linux-generic/odp_traffic_mngr.c  | 2799
>> 
>>  29 files changed, 9168 insertions(+), 2 deletions(-)
>>  create mode 100644 example/traffic_mgmt/.gitignore
>>  create mode 100644 example/traffic_mgmt/Makefile.am
>>  create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c
>>  create mode 100644

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

2015-11-17 Thread Nicolas Morey-Chaisemartin

I have read few things here and there about the repo split but haven't seen the 
full plan of the ML (maybe I missed it).
Is there some more information somewhere ?

Nicolas

On 11/17/2015 05:21 AM, Bill Fischofer wrote:
> This seems reasonable, but is probably already part of the new odp-api.git 
> repo creation activity.
>
> On Thu, Nov 12, 2015 at 8:22 AM, Nicolas Morey-Chaisemartin  > wrote:
>
> Signed-off-by: Nicolas Morey-Chaisemartin  >
> ---
>  platform/Makefile.inc  | 39 
> ++
>  platform/linux-generic/Makefile.am | 39 
> --
>  2 files changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
> index 8e8e97b..14e134c 100644
> --- a/platform/Makefile.inc
> +++ b/platform/Makefile.inc
> @@ -15,3 +15,42 @@ AM_LDFLAGS += -version-number '$(ODP_LIBSO_VERSION)'
>  GIT_DESC = `$(top_srcdir)/scripts/git_hash.sh $(top_srcdir)`
>  AM_CFLAGS += "-DGIT_HASH=$(GIT_DESC)"
>  AM_CFLAGS += -DPLATFORM=${with_platform}
> +
> +odpapiincludedir= $(includedir)/odp/api
> +odpapiinclude_HEADERS = \
> + $(top_srcdir)/include/odp/api/align.h \
> + $(top_srcdir)/include/odp/api/atomic.h \
> + $(top_srcdir)/include/odp/api/barrier.h \
> + $(top_srcdir)/include/odp/api/buffer.h \
> + $(top_srcdir)/include/odp/api/byteorder.h \
> + $(top_srcdir)/include/odp/api/classification.h \
> + $(top_srcdir)/include/odp/api/compiler.h \
> + $(top_srcdir)/include/odp/api/config.h \
> + $(top_srcdir)/include/odp/api/cpu.h \
> + $(top_srcdir)/include/odp/api/cpumask.h \
> + $(top_srcdir)/include/odp/api/crypto.h \
> + $(top_srcdir)/include/odp/api/debug.h \
> + $(top_srcdir)/include/odp/api/errno.h \
> + $(top_srcdir)/include/odp/api/event.h \
> + $(top_srcdir)/include/odp/api/hints.h \
> + $(top_srcdir)/include/odp/api/init.h \
> + $(top_srcdir)/include/odp/api/packet.h \
> + $(top_srcdir)/include/odp/api/packet_flags.h \
> + $(top_srcdir)/include/odp/api/packet_io.h \
> + $(top_srcdir)/include/odp/api/pool.h \
> + $(top_srcdir)/include/odp/api/queue.h \
> + $(top_srcdir)/include/odp/api/random.h \
> + $(top_srcdir)/include/odp/api/rwlock.h \
> + $(top_srcdir)/include/odp/api/schedule.h \
> + $(top_srcdir)/include/odp/api/schedule_types.h \
> + $(top_srcdir)/include/odp/api/shared_memory.h \
> + $(top_srcdir)/include/odp/api/spinlock.h \
> + $(top_srcdir)/include/odp/api/std_types.h \
> + $(top_srcdir)/include/odp/api/sync.h \
> + $(top_srcdir)/include/odp/api/system_info.h \
> + $(top_srcdir)/include/odp/api/thread.h \
> + $(top_srcdir)/include/odp/api/thrmask.h \
> + $(top_srcdir)/include/odp/api/ticketlock.h \
> + $(top_srcdir)/include/odp/api/time.h \
> + $(top_srcdir)/include/odp/api/timer.h \
> + $(top_srcdir)/include/odp/api/version.h
> \ No newline at end of file
> diff --git a/platform/linux-generic/Makefile.am 
> b/platform/linux-generic/Makefile.am
> index 0135947..610e04d 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -73,45 +73,6 @@ odpplatinclude_HEADERS = \
>   $(srcdir)/include/odp/plat/timer_types.h \
>   $(srcdir)/include/odp/plat/version_types.h
>
> -odpapiincludedir= $(includedir)/odp/api
> -odpapiinclude_HEADERS = \
> - $(top_srcdir)/include/odp/api/align.h \
> - $(top_srcdir)/include/odp/api/atomic.h \
> - $(top_srcdir)/include/odp/api/barrier.h \
> - $(top_srcdir)/include/odp/api/buffer.h \
> - $(top_srcdir)/include/odp/api/byteorder.h \
> - $(top_srcdir)/include/odp/api/classification.h \
> - $(top_srcdir)/include/odp/api/compiler.h \
> - $(top_srcdir)/include/odp/api/config.h \
> - $(top_srcdir)/include/odp/api/cpu.h \
> - $(top_srcdir)/include/odp/api/cpumask.h \
> - $(top_srcdir)/include/odp/api/crypto.h \
> - $(top_srcdir)/include/odp/api/debug.h \
> -

[lng-odp] [API-NEXT PATCHv11 3/3] example: tm: traffic manager example

2015-11-17 Thread Bill Fischofer

From: Barry Spinney 

This commit includes all of the changes to build the traffic_mgr example
application.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 configure.ac|   1 +
 example/Makefile.am |   2 +-
 example/traffic_mgmt/.gitignore |   1 +
 example/traffic_mgmt/Makefile.am|   9 +
 example/traffic_mgmt/odp_traffic_mgmt.c | 781 
 5 files changed, 793 insertions(+), 1 deletion(-)
 create mode 100644 example/traffic_mgmt/.gitignore
 create mode 100644 example/traffic_mgmt/Makefile.am
 create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c

diff --git a/configure.ac b/configure.ac
index 2c47358..ae5395a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -325,6 +325,7 @@ AC_CONFIG_FILES([Makefile
 example/ipsec/Makefile
 example/packet/Makefile
 example/timer/Makefile
+example/traffic_mgmt/Makefile
 helper/Makefile
 helper/test/Makefile
 pkgconfig/libodp.pc
diff --git a/example/Makefile.am b/example/Makefile.am
index 353f397..6b67bf5 100644
--- a/example/Makefile.am
+++ b/example/Makefile.am
@@ -1 +1 @@
-SUBDIRS = classifier generator ipsec packet timer
+SUBDIRS = classifier generator ipsec packet timer traffic_mgmt
diff --git a/example/traffic_mgmt/.gitignore b/example/traffic_mgmt/.gitignore
new file mode 100644
index 000..9e742f0
--- /dev/null
+++ b/example/traffic_mgmt/.gitignore
@@ -0,0 +1 @@
+odp_traffic_mgmt
\ No newline at end of file
diff --git a/example/traffic_mgmt/Makefile.am b/example/traffic_mgmt/Makefile.am
new file mode 100644
index 000..c8ff797
--- /dev/null
+++ b/example/traffic_mgmt/Makefile.am
@@ -0,0 +1,9 @@
+include $(top_srcdir)/example/Makefile.inc
+
+bin_PROGRAMS = odp_traffic_mgmt$(EXEEXT)
+odp_traffic_mgmt_LDFLAGS = $(AM_LDFLAGS) -static
+odp_traffic_mgmt_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example
+
+noinst_HEADERS = $(top_srcdir)/example/example_debug.h
+
+dist_odp_traffic_mgmt_SOURCES = odp_traffic_mgmt.c
diff --git a/example/traffic_mgmt/odp_traffic_mgmt.c 
b/example/traffic_mgmt/odp_traffic_mgmt.c
new file mode 100644
index 000..37a85c7
--- /dev/null
+++ b/example/traffic_mgmt/odp_traffic_mgmt.c
@@ -0,0 +1,781 @@
+/* Copyright 2015 EZchip Semiconductor Ltd. All Rights Reserved.
+ *
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_SVC_CLASSES 4
+#define USERS_PER_SVC_CLASS 2
+#define APPS_PER_USER   2
+#define TM_QUEUES_PER_APP   2
+#define NUM_USERS   (USERS_PER_SVC_CLASS * NUM_SVC_CLASSES)
+#define NUM_TM_QUEUES   (NUM_USERS * APPS_PER_USER * TM_QUEUES_PER_APP)
+#define TM_QUEUES_PER_USER  (TM_QUEUES_PER_APP * APPS_PER_USER)
+#define TM_QUEUES_PER_CLASS (USERS_PER_SVC_CLASS * TM_QUEUES_PER_USER)
+
+#define Kbps   1000
+#define Mbps   100
+#define PERCENT(percent)  (100 * percent)
+
+#define FALSE  0
+#define TRUE   1
+
+#define MAX(a, b) (((a) > (b)) ? (a) : (b))
+#define MIN(a, b) (((a) < (b)) ? (a) : (b))
+
+#define RANDOM_BUF_LEN  1024
+
+typedef struct {
+   odp_tm_shaper_params_tshaper_params;
+   odp_tm_threshold_params_t threshold_params;
+   odp_tm_wred_params_t  wred_params[ODP_NUM_PACKET_COLORS];
+} profile_params_set_t;
+
+typedef struct {
+   odp_tm_shaper_tshaper_profile;
+   odp_tm_threshold_t threshold_profile;
+   odp_tm_wred_t  wred_profiles[ODP_NUM_PACKET_COLORS];
+} profile_set_t;
+
+static const odp_init_t ODP_INIT_PARAMS = {
+   .log_fn   = odp_override_log,
+   .abort_fn = odp_override_abort
+};
+
+static const odp_platform_init_t PLATFORM_PARAMS = {
+};
+
+static profile_params_set_t COMPANY_PROFILE_PARAMS = {
+   .shaper_params = {
+   .commit_bps = 50  * Mbps,  .commit_burst  = 100,
+   .peak_bps   = 0,   .peak_burst= 0,
+   .dual_rate  = FALSE,   .shaper_len_adjust = 20
+   },
+
+   .threshold_params = {
+   .max_pkts  = 10,.enable_max_pkts  = TRUE,
+   .max_bytes = 1000,  .enable_max_bytes = TRUE
+   },
+
+   .wred_params = {
+   [ODP_PACKET_GREEN ... ODP_PACKET_YELLOW] = {
+   .min_threshold = PERCENT(70),
+   .med_threshold = PERCENT(90),
+   .med_drop_prob = PERCENT(80),
+   .max_drop_prob = PERCENT(100),
+   .enable_wred   = TRUE,
+   .use_byte_fullness = FALSE,
+   },
+
+   [ODP_PACKET_RED] = {
+   .min_threshold = PERCENT(40),
+

[lng-odp] [API-NEXT PATCHv11 1/3] api: tm: add tm API definitions

2015-11-17 Thread Bill Fischofer

From: Barry Spinney 

This introduces an API for configuring and using Traffic Management
systems.

The purpose of this API is as a general packet scheduling system that
accepts packets from input queues and applies strict priority
scheduling, weighted fair queuing scheduling and/or bandwidth controls
to decide which input packet should be chosen as the next output
packet and when this output packet can be sent onwards.

Signed-off-by: Barry Spinney 
Signed-off-by: Bill Fischofer 
---
 include/odp.h  |1 +
 include/odp/api/packet.h   |   69 +
 include/odp/api/traffic_mngr.h | 1611 
 .../linux-generic/include/odp/plat/packet_types.h  |   11 +
 .../include/odp/plat/traffic_mngr_types.h  |  185 +++
 platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
 .../linux-generic/include/odp_packet_internal.h|5 +
 7 files changed, 1917 insertions(+)
 create mode 100644 include/odp/api/traffic_mngr.h
 create mode 100644 platform/linux-generic/include/odp/plat/traffic_mngr_types.h
 create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h

diff --git a/include/odp.h b/include/odp.h
index 2adcb8b..4a93c23 100644
--- a/include/odp.h
+++ b/include/odp.h
@@ -55,6 +55,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
index 85cc9c9..9c63b5f 100644
--- a/include/odp/api/packet.h
+++ b/include/odp/api/packet.h
@@ -48,6 +48,26 @@ extern "C" {
  * Invalid packet segment
  */
 
+ /**
+  * @typedef odp_packet_color_t
+  * Color of packet for shaper/drop processing
+  */
+
+ /**
+  * @def ODP_PACKET_GREEN
+  * Packet is green
+  */
+
+ /**
+  * @def ODP_PACKET_YELLOW
+  * Packet is yellow
+  */
+
+ /**
+  * @def ODP_PACKET_RED
+  * Packet is red
+  */
+
 /*
  *
  * Alloc and free
@@ -729,6 +749,55 @@ odp_packet_seg_t odp_packet_last_seg(odp_packet_t pkt);
  */
 odp_packet_seg_t odp_packet_next_seg(odp_packet_t pkt, odp_packet_seg_t seg);
 
+/**
+ * Get packet color
+ *
+ * @param pkt Packet handle
+ * @return packet color
+ */
+odp_packet_color_t odp_packet_color(odp_packet_t pkt);
+
+/**
+ * Set packet color
+ *
+ * @param pkt Packet handle
+ * @param color Color to set
+ */
+void odp_packet_color_set(odp_packet_t pkt, odp_packet_color_t color);
+
+/**
+ * Get drop eligible status
+ *
+ * @param pkt Packet handle
+ * @return Packet drop eligibility status
+ * @retval 0 Packet is not drop eligible
+ * @retval 1 Packet is drop
+ */
+odp_bool_t odp_packet_drop_eligible(odp_packet_t pkt);
+
+/**
+ * Set drop eligible status
+ *
+ * @param pkt Packet handle
+ * @param status Drop eligibility status
+ */
+void odp_packet_drop_eligible_set(odp_packet_t pkt, odp_bool_t status);
+
+/**
+ * Get shaper length adjustment
+ *
+ * @param pkt Packet handle
+ * @return Shaper adjustment (-128..127)
+ */
+int8_t odp_packet_shaper_len_adjust(odp_packet_t pkt);
+
+/**
+ * Set shaper length adjustment
+ *
+ * @param pkt Packet handle
+ * @param adj Signed adjustment value
+ */
+void odp_packet_shaper_len_adjust_set(odp_packet_t pkt, int8_t adj);
 
 /*
  *
diff --git a/include/odp/api/traffic_mngr.h b/include/odp/api/traffic_mngr.h
new file mode 100644
index 000..2459a8b
--- /dev/null
+++ b/include/odp/api/traffic_mngr.h
@@ -0,0 +1,1611 @@
+/** Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_TRAFFIC_MNGR_H_
+#define ODP_TRAFFIC_MNGR_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+
+/**
+ * @file
+ *
+ */
+
+/** @defgroup odp_traffic_mngr ODP TRAFFIC MNGR
+ * @{
+ *
+ * An API for configuring and using Traffic Management systems
+ *
+ * This file forms a simple interface for creating, configuring and using
+ * Traffic Management (TM) subsystems.  By TM subsystem it is meant a general
+ * packet scheduling system that accepts packets from input queues and applies
+ * strict priority scheduling, weighted fair queueing scheduling and/or
+ * bandwidth controls to decide which input packet should be chosen as the
+ * next output packet and when this output packet can be sent onwards.
+ *
+ * A given platform supporting this TM API could support one or more pure
+ * hardware based packet scheduling systems, one or more pure software
+ * based systems or one or more hybrid systems - where because of
+ * hardware constraints some of the packet scheduling is done in hardware
+ * and some is done in software.  In addition, there may also be additional
+ * API's beyond those described here for (a) controlling advanced capabilities
+ * supported by specific hardware, software or hybrid subsystems or (b)
+ * dealing with constraints and limitations of specific implementations.
+ * The intention here is to be the simplest API that covers the vast majority

[lng-odp] [PATCH v2] remove hard platform links

2015-11-17 Thread Mike Holmes

Signed-off-by: Mike Holmes 
---
 example/Makefile.inc | 1 -
 helper/Makefile.am   | 1 -
 test/Makefile.inc| 1 -
 3 files changed, 3 deletions(-)

diff --git a/example/Makefile.inc b/example/Makefile.inc
index 05021d4..170f32e 100644
--- a/example/Makefile.inc
+++ b/example/Makefile.inc
@@ -5,7 +5,6 @@ AM_CFLAGS += \
-I$(srcdir) \
-I$(top_srcdir)/example \
-I$(top_srcdir)/platform/@with_platform@/include \
-   -I$(top_srcdir)/platform/linux-generic/include \
-I$(top_srcdir)/include/ \
-I$(top_srcdir)/helper/include
 
diff --git a/helper/Makefile.am b/helper/Makefile.am
index e72507e..bed8683 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -4,7 +4,6 @@ pkgconfig_DATA = $(top_builddir)/pkgconfig/libodphelper.pc
 LIB   = $(top_builddir)/lib
 AM_CFLAGS  = -I$(srcdir)/include
 AM_CFLAGS += -I$(top_srcdir)/platform/@with_platform@/include
-AM_CFLAGS += -I$(top_srcdir)/platform/linux-generic/include
 AM_CFLAGS += -I$(top_srcdir)/include
 
 helperincludedir = $(includedir)/odp/helper/
diff --git a/test/Makefile.inc b/test/Makefile.inc
index 2700b18..183d0a5 100644
--- a/test/Makefile.inc
+++ b/test/Makefile.inc
@@ -8,7 +8,6 @@ LDADD = $(PRE_LDADD) $(LIB)/libodphelper.la $(LIB)/libodp.la
 
 INCFLAGS = -I$(top_srcdir)/test \
-I$(top_srcdir)/platform/@with_platform@/include \
-   -I$(top_srcdir)/platform/linux-generic/include \
-I$(top_srcdir)/include \
-I$(top_srcdir)/helper/include
 AM_CFLAGS += $(INCFLAGS)
-- 
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

2015-11-17 Thread Mike Holmes

apply and build issues still show up for me - I used v11 - three patches

~/incoming/bill$ ls -l
total 452
-rw--- 1 mike mike 127026 Nov 17 17:17
lng-odp_API-NEXT_PATCHv11_1-3_api_tm_add_tm_API_definitions.mbox
-rw--- 1 mike mike 286282 Nov 17 17:17
lng-odp_API-NEXT_PATCHv11_2-3_linux-generic_tm_implement_traffic_manager.mbox
-rw--- 1 mike mike  41280 Nov 17 17:17
lng-odp_API-NEXT_PATCHv11_3-3_example_tm_traffic_manager_example.mbox

GIT_BRANCH=api-next PATCH_DIR=~/incoming/bill ./apply-and-build.sh

...
odp_new_workdir: calling
Branch git___git_linaro_org_lng_odp_git_api_next set up to track remote
branch api-next from git___git_linaro_org_lng_odp_git.
Switched to a new branch 'git___git_linaro_org_lng_odp_git_api_next'
Cloning into '/home/mike/git/check-odp/build/odp-apply'...
done.
Building baseline: git://git.linaro.org/lng/odp.git

..
In file included from ../../../../platform/linux-generic/pktio/loop.c:12:0:
../../../../include/odp.h:58:30: fatal error: odp/traffic_mngr.h: No such
file or directory


On 17 November 2015 at 15:40, Bill Fischofer 
wrote:

> Changes in v11
> - Squash Parts 2 and 3 to give new Part 2 that can build independently
> - Change typedef for hash_table_entry_t to uint64_t for 32-bit support
>
> Changes in v10
> - Add back ARM definitions for _crc32w() from Alex that got dropped in v9
>
> Note: Checkpatch complains about the _asm() line.  Says spaces are needed
> but
> if spaces are added then complains that spaces are prohibited.  Rules need
> to
> be updated to ignore these sort of constructs.
>
> Changes in v9
> - Rebase on top of latest queue fixes
>
> Changes in v8
> - add ARM definition for __crc32w() function (from Alex)
>
> Changes in v7 (review comments by Maxim)
> - Correct architecture ifdefs (use of arch dir in later patch)
> - Correct doxygen for queue types
> - Change internal APIs that use odp_ prefix to use _odp prefix
> - Rebase to latest api-next
>
> Changes in v6
> - Move documentation of packet colors to main API file
> - Add ODP prefix to odp_tm_egress_kind_t enums
>
> Changes in v5
> - Add include file odp_traffic_mngr_internal.h
> - Add support for odp_tm_enq() from packets originating from ordered queues
>
> Changes in v4
> - Incorporate API changes suggested by Petri
>
> Changes in v3
> - Fix checkpatch errors (Bill)
>
> Changes in v2
> - Full patch submission (Barry)
>
> Barry Spinney (3):
>   api: tm: add tm API definitions
>   linux-generic: tm: implement traffic manager
>   example: tm: traffic manager example
>
>  configure.ac   |1 +
>  example/Makefile.am|2 +-
>  example/traffic_mgmt/.gitignore|1 +
>  example/traffic_mgmt/Makefile.am   |9 +
>  example/traffic_mgmt/odp_traffic_mgmt.c|  781 ++
>  include/odp.h  |1 +
>  include/odp/api/packet.h   |   69 +
>  include/odp/api/traffic_mngr.h | 1611 +++
>  platform/linux-generic/Makefile.am |   13 +
>  .../linux-generic/include/odp/plat/packet_types.h  |   11 +
>  .../linux-generic/include/odp/plat/queue_types.h   |7 +
>  .../include/odp/plat/traffic_mngr_types.h  |  185 ++
>  platform/linux-generic/include/odp/traffic_mngr.h  |   35 +
>  platform/linux-generic/include/odp_internal.h  |2 +
>  .../include/odp_name_table_internal.h  |   61 +
>  .../linux-generic/include/odp_packet_internal.h|5 +
>  .../linux-generic/include/odp_pkt_queue_internal.h |   62 +
>  .../linux-generic/include/odp_queue_internal.h |6 +
>  .../include/odp_sorted_list_internal.h |   78 +
>  .../include/odp_timer_wheel_internal.h |   68 +
>  .../include/odp_traffic_mngr_internal.h|  324 +++
>  platform/linux-generic/odp_init.c  |5 +
>  platform/linux-generic/odp_name_table.c| 1371 ++
>  platform/linux-generic/odp_packet_flags.c  |   46 +-
>  platform/linux-generic/odp_pkt_queue.c |  379 +++
>  platform/linux-generic/odp_queue.c |   60 +
>  platform/linux-generic/odp_sorted_list.c   |  271 ++
>  platform/linux-generic/odp_timer_wheel.c   |  907 +++
>  platform/linux-generic/odp_traffic_mngr.c  | 2799
> 
>  29 files changed, 9168 insertions(+), 2 deletions(-)
>  create mode 100644 example/traffic_mgmt/.gitignore
>  create mode 100644 example/traffic_mgmt/Makefile.am
>  create mode 100644 example/traffic_mgmt/odp_traffic_mgmt.c
>  create mode 100644 include/odp/api/traffic_mngr.h
>  create mode 100644
> platform/linux-generic/include/odp/plat/traffic_mngr_types.h
>  create mode 100644 platform/linux-generic/include/odp/traffic_mngr.h
>  create mode 100644
> platform/linux-generic/include/odp_name_table_internal.h
>  create mode 100644

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

Re: [lng-odp] [API-NEXT PATCHv10 0/4] Egress Traffic Manager

[lng-odp] [PATCH] scripts: git_hash: support gitfiles

[lng-odp] [Bug 1906] New: not tested uint64_t odp_cpu_cycles_resolution(void)

[lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

[lng-odp] [PATCH] helper: test: add odp_table to .gitignore file

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

Re: [lng-odp] [PATCH 1/5] api: classification: add odp_cls_cos_pool_set() api

Re: [lng-odp] [PATCH 1/5] api: classification: add odp_cls_cos_pool_set() api

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

[lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

[lng-odp] [API-NEXT PATCHv12 1/3] api: tm: add tm API definitions

[lng-odp] [API-NEXT PATCHv12 0/3] Egress Traffic Manager

[lng-odp] [PATCHv3 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCHv2 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] [PATCH] helper: test: add odp_table to .gitignore file

[lng-odp] [PATCHv4 2/2] doc: userguide: add baseline overview to document

Re: [lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

Re: [lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS

[lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

[lng-odp] [API-NEXT PATCHv12 3/3] example: tm: traffic manager example

Re: [lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

Re: [lng-odp] [PATCH] platform: move list of API files to Makefile.inc so it is common to all platforms

[lng-odp] [API-NEXT PATCHv11 3/3] example: tm: traffic manager example

[lng-odp] [API-NEXT PATCHv11 1/3] api: tm: add tm API definitions

[lng-odp] [PATCH v2] remove hard platform links

Re: [lng-odp] [API-NEXT PATCHv11 0/3] Egress Traffic Manager

33 matches

Site Navigation

Mail list logo

Footer information