Re: [lng-odp] Pool DMA mapping

[Maxim Uvarov]

On 12/16/2015 19:48, Zoltan Kiss wrote:



On 16/12/15 16:47, Zoltan Kiss wrote:



On 16/12/15 15:39, Christophe Milard wrote:

Hi,

Following the discussion at the ARCH call, today, would it be 
reasonable

to require that all packet pools that can be used by a NIC have to be
created before the related nic pktio is opened? -This is implicitly
required in RX, as the pool handle from which buffer should be 
allocated

in RX is a parameter to the  pktio_open() function.


Yes, for me it's quite obvious.

How you can do it opposite? odp_pktio_open() requires pool as parameter:

odp_pktio_t odp_pktio_open(const char *dev, odp_pool_t pool,
   const odp_pktio_param_t *param)




? Is the fact that an

application will not be able to transmit packets from a pool created
AFTER pktio open() was called acceptable?


I think TX is different from that point of view. The packet should
obviously exist at the time of TX, but whether it came from the pool
supplied to odp_pktio_open() or not shouldn't really matter.


Or is there a particular reason you need this? I think I've missed 
during the arch call why is this important.






/Christophe.


___
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


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

Re: [lng-odp] [PATCH 2/2] doc: release-guide: add deprecated api section

[Maxim Uvarov]

On 12/16/2015 20:22, Mike Holmes wrote:



On 16 December 2015 at 05:50, Maxim Uvarov > wrote:


On 12/15/2015 21:06, Mike Holmes wrote:

Describe how changes to the public api are handled from
release to release.

Signed-off-by: Mike Holmes >
---
  doc/process-guide/release-guide.adoc | 38

  1 file changed, 38 insertions(+)

diff --git a/doc/process-guide/release-guide.adoc
b/doc/process-guide/release-guide.adoc
index f5d29d2..d932118 100644
--- a/doc/process-guide/release-guide.adoc
+++ b/doc/process-guide/release-guide.adoc
@@ -134,3 +134,41 @@ made every month if sufficient change has
accumulated.
=== Implementation (Impl) ===
  Platform specific free form text relating to the version.
+
+== Deprecated APIs
+
+Whenever an API is changed as part of an api-next patch the
following rules
+apply to provide a warning to implementers and users.
+
+* A patch will be applied to api-next that adds the
deprecated indication to
+the old public API in odp/include

That sentence should never be in product documentation. Plans can
be in
Jira cards, bugs, mailing list, but published docs should relay
only on work
which is already done.


I dont follow the rationale that this is the wrong place,  this is the 
document that does describe how we will operate, we dont specify which 
patch just how they will be used.


Sorry, for first read I thought that want to send patch to api-next to 
mark functions as deprecated. Instead of current one. But you
just defining list of rules for such deprecated patch. It's a little bit 
confusing senescence for me as non native English.

Might be:
1. add ":" after "users". So reader can expect some list.
2. Rephrase sentence to: "Patch which marks existence api (odp/include) 
with deprecated indication should be applied on api-next first. Same way 
as all other api changes patches."


(if we name it "rules", not "plans" - it has to be not future form, 
right? I.e. have to, must).





+* A patch will be applied to api-next that adds the new API
and removes the
+old, in these cases the implementation and tests must also
change at the same
+time to ensure that CI shows no regressions in the api-next
branch.

same here.

describing how we operate is the purpose of this doc

That also I understood wrongly.

But replace old by new is not deprecation. It's just api replacement. 
That should be in api-next branch
description. And chapter Deprecated APIs should have rules only suitable 
for deprecation.





+* When the Release Manager has scheduled the api change to be
released in a
+future version, the initial deprecated patch will be moved to
next branch and
+released in the next release cycle.
+* When at a minim of one release cycle has passed, and
possibly longer as
+specified by the Release Manager the complete change will be
merged to next and
+then released in the next cycle.

Release Manager scheduled in next release cycle ... It's it too
complex
to read and understand when and what will be done. How about be more
community friendly in sentences? Something like:


We can certainly try to make it clearer and put the points on a 
diagram to show how they relate in time.


My point is - it's easy to mark function as deprecated. But you never 
know what time will take transition period
that everybody will stop using it. Linux kernel has some deprecated 
function which warn for years. And I think
that right thing will be discussion before next big release if we want 
to remove some specific functions.




""
ODP API provides special API to mark function and data types as
deprecated.


This is not true, there is no API only a doxygen comment.


everything what is in ./include/odp/api we consider as API, right?

include/odp/api/hints.h
#define ODP_DEPRECATED __attribute__((__deprecated__))


Marking function as deprecated means that ODP Community will
support all
functionality for that function, validation tests and test
execution in CI system.


No, deprecated means literally that you should stop using something. 
In our case becasue it will change and you can view the new version in 
api-next.


It depends from with point of view you are looking. Yes it says - stop 
using it. But that api should still have implementation and validation tests
for linux-generic. I.e. we have to support it for some time until it's 
completely removed.



Because of support of both new API and deprecated adds additional
load and
increase 

Re: [lng-odp] [HELP] Question about API Classification and Traffic Manager

[Kury Nicolas]

Hi!

I see now. Thank you very much!

Nicolas


De : Bala Manoharan 
Envoyé : mercredi 16 décembre 2015 16:23
À : Kury Nicolas
Cc : lng-odp@lists.linaro.org
Objet : Re: [lng-odp] [HELP] Question about API Classification and Traffic 
Manager

Hi,

On 16 December 2015 at 20:22, Kury Nicolas
 wrote:
> Hi!
>
> I have some questions about Traffic Manager and Classifier.
>
> Traffic Manager:
> I see there is the possibility to send back the packets. Do you have any 
> example where this would be used ? I don't really see how we can combine the 
> different algorithms, example Strict Priority scheduling with Bandwidth 
> Shaping, etc.
> http://img11.hostingpics.net/pics/882875tarfficmanager.png

One use-case where you could use loopback is for crypto coz before
decrypting the packet you will not be able to access the packet fields
and hence you could receive the encrypted packets in a single flow
through a PMR rule decrypt the packet on the flow and send the clear
packet back through loopback interface to be classified to a specific
flow.
>
> Classifiers
> It is possible to have such a loopback ? 
> http://img11.hostingpics.net/pics/729760loop.png
> For example, a packet is classified in flow #1 with processing #1, and then 
> is classified in flow #2 with processing #2, etc. ?

Yes. This scenario is possible through loop back interface.
Since classifier is enabled on the interface level the packets coming
back through the loopback interface will be classified into their
respective flow in your example it will be flow #2

Hopefully the processing on the initial packet changes the packet
header fields or the fields which are configured as part of PMR rule.
Another example could be that the incoming packet is encrypted and the
initial processing decrypts the packets and sends it to the loopback
interface to be classified into a different flow.

Regards,
Bala
>
> Thank you very much!
> Nicolas
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp



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

Re: [lng-odp] [PATCH 2/2] doc: release-guide: add deprecated api section

[Mike Holmes]

On 16 December 2015 at 05:50, Maxim Uvarov  wrote:

> On 12/15/2015 21:06, Mike Holmes wrote:
>
>> Describe how changes to the public api are handled from release to
>> release.
>>
>> Signed-off-by: Mike Holmes 
>> ---
>>   doc/process-guide/release-guide.adoc | 38
>> 
>>   1 file changed, 38 insertions(+)
>>
>> diff --git a/doc/process-guide/release-guide.adoc
>> b/doc/process-guide/release-guide.adoc
>> index f5d29d2..d932118 100644
>> --- a/doc/process-guide/release-guide.adoc
>> +++ b/doc/process-guide/release-guide.adoc
>> @@ -134,3 +134,41 @@ made every month if sufficient change has
>> accumulated.
>> === Implementation (Impl) ===
>>   Platform specific free form text relating to the version.
>> +
>> +== Deprecated APIs
>> +
>> +Whenever an API is changed as part of an api-next patch the following
>> rules
>> +apply to provide a warning to implementers and users.
>> +
>> +* A patch will be applied to api-next that adds the deprecated
>> indication to
>> +the old public API in odp/include
>>
> That sentence should never be in product documentation. Plans can be in
> Jira cards, bugs, mailing list, but published docs should relay only on
> work
> which is already done.


I dont follow the rationale that this is the wrong place,  this is the
document that does describe how we will operate, we dont specify which
patch just how they will be used.


>
>
> +* A patch will be applied to api-next that adds the new API and removes
>> the
>> +old, in these cases the implementation and tests must also change at the
>> same
>> +time to ensure that CI shows no regressions in the api-next branch.
>>
> same here.


describing how we operate is the purpose of this doc


>
>
> +* When the Release Manager has scheduled the api change to be released in
>> a
>> +future version, the initial deprecated patch will be moved to next
>> branch and
>> +released in the next release cycle.
>> +* When at a minim of one release cycle has passed, and possibly longer as
>> +specified by the Release Manager the complete change will be merged to
>> next and
>> +then released in the next cycle.
>>
> Release Manager scheduled in next release cycle ... It's it too complex
> to read and understand when and what will be done. How about be more
> community friendly in sentences? Something like:
>

We can certainly try to make it clearer and put the points on a diagram to
show how they relate in time.


>
> ""
> ODP API provides special API to mark function and data types as deprecated.
>

This is not true, there is no API only a doxygen comment.


> Marking function as deprecated means that ODP Community will support all
> functionality for that function, validation tests and test execution in CI
> system.
>

No, deprecated means literally that you should stop using something. In our
case becasue it will change and you can view the new version in api-next.


> Because of support of both new API and deprecated adds additional load and
> increase complexity marking functions as deprecated will happen only for
> specific reason.


We will mark them deprecated when the current API can be shown to be
deficient and a better alternative has already been proven in api-next.

That reason should be valuable, discussed in ODP community meetings,
> recorded in mailing list and corresponding bug entry should be open.


Yes, that is why we created api-next so that the community can  comment and
give feedback


> Also some transition
> period for supporting old API should be defined.
>
>
The release manager role is the one that ensures that all the process has
been completed and schedules the change to actually occur, at no point will
the old api be supported concurrently unless it is in a long term support
version. The period for which the deprecated element is flagged will vary
and will generally be reached by consensus in api-next discussion.


> +
>> +NOTE: Any given release never supports two versions of an API
>> +
>>
>
> That is not what deprecated means. I.e. deprecated means absolutely
> opposite - support old version
> and new at the same time.


No, "*Deprecation* is an attribute applied to a computer software
 feature, characteristic,
or practice to indicate that it should be avoided (often because it is
being superseded). "
It says nothing about supporting it in parallel with a new variant.
ODP support during this  period comes in the form that the old api will
still work while the warning is in effect that you should plan on stopping
using it. You don't have to stop using it, you could remain
on that release.


>
>
> +.Marking a deprecated API element
>> +[source,c]
>> +
>> +/**
>> + * Get buffer handle from event
>> + *
>> + * Converts an ODP_EVENT_BUFFER type event to a buffer.
>> + *
>> + * @deprecated  This api will be removed for some good reason defined
>> here
>>
> doxygen is not enough I 

Re: [lng-odp] [PATCHv17 04/10] helpers: remove odp_ prefix for tests source files

[Mike Holmes]

Using patch:
lng-odp_PATCHv17_04-10_helpers_remove_odp_prefix_for_tests_source_files.mbox
  Trying to apply patch
  Patch applied
Applying: helpers: remove odp_ prefix for tests source files
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:47: indent
with spaces.
  thread$(EXEEXT) \
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:48: indent
with spaces.
  process$(EXEEXT)\
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:49: indent
with spaces.
  pause$(EXEEXT)\
/home/mike/git/check-odp/build/odp-apply/.git/rebase-apply/patch:50: indent
with spaces.
  table$(EXEEXT)
warning: 4 lines add whitespace errors.

On 10 December 2015 at 09:24, Maxim Uvarov  wrote:

> Prefixed were removed for validation test suite and to
> be consistent we need to do the same for helpers.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  helper/test/.gitignore   | 10 +-
>  helper/test/Makefile.am  | 25 -
>  helper/test/{odp_chksum.c => chksum.c}   |  3 +--
>  helper/test/{odph_pause.c => pause.c}|  0
>  helper/test/{odp_process.c => process.c} |  3 ++-
>  helper/test/{odp_table.c => table.c} |  1 -
>  helper/test/{odp_thread.c => thread.c}   |  3 ++-
>  7 files changed, 22 insertions(+), 23 deletions(-)
>  rename helper/test/{odp_chksum.c => chksum.c} (98%)
>  rename helper/test/{odph_pause.c => pause.c} (100%)
>  rename helper/test/{odp_process.c => process.c} (96%)
>  rename helper/test/{odp_table.c => table.c} (99%)
>  rename helper/test/{odp_thread.c => thread.c} (96%)
>
> diff --git a/helper/test/.gitignore b/helper/test/.gitignore
> index 50a0da4..1984139 100644
> --- a/helper/test/.gitignore
> +++ b/helper/test/.gitignore
> @@ -1,7 +1,7 @@
>  *.trs
>  *.log
> -odp_chksum
> -odp_process
> -odp_table
> -odp_thread
> -odph_pause
> +chksum
> +process
> +table
> +thread
> +pause
> diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
> index d6820e1..760dac1 100644
> --- a/helper/test/Makefile.am
> +++ b/helper/test/Makefile.am
> @@ -5,11 +5,11 @@ AM_LDFLAGS += -static
>
>  TESTS_ENVIRONMENT += TEST_DIR=${builddir}
>
> -EXECUTABLES = odp_chksum$(EXEEXT) \
> -  odp_thread$(EXEEXT) \
> -  odp_process$(EXEEXT)\
> -  odph_pause$(EXEEXT)\
> -  odp_table$(EXEEXT)
> +EXECUTABLES = chksum$(EXEEXT) \
> +  thread$(EXEEXT) \
> +  process$(EXEEXT)\
> +  pause$(EXEEXT)\
> +  table$(EXEEXT)
>
>  COMPILE_ONLY =
>
> @@ -23,11 +23,10 @@ dist_bin_SCRIPTS =
>
>  bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
>
> -
> -dist_odp_chksum_SOURCES = odp_chksum.c
> -dist_odp_thread_SOURCES = odp_thread.c
> -odp_thread_LDADD = $(LIB)/libodphelper.la $(LIB)/libodp.la
> -dist_odp_process_SOURCES = odp_process.c
> -odp_process_LDADD = $(LIB)/libodphelper.la $(LIB)/libodp.la
> -odph_pause_SOURCES = odph_pause.c
> -dist_odp_table_SOURCES = odp_table.c
> +dist_chksum_SOURCES = chksum.c
> +dist_thread_SOURCES = thread.c
> +thread_LDADD = $(LIB)/libodphelper.la $(LIB)/libodp.la
> +dist_process_SOURCES = process.c
> +process_LDADD = $(LIB)/libodphelper.la $(LIB)/libodp.la
> +odph_pause_SOURCES = pause.c
> +dist_odp_table_SOURCES = table.c
> diff --git a/helper/test/odp_chksum.c b/helper/test/chksum.c
> similarity index 98%
> rename from helper/test/odp_chksum.c
> rename to helper/test/chksum.c
> index 1d417a8..c987905 100644
> --- a/helper/test/odp_chksum.c
> +++ b/helper/test/chksum.c
> @@ -64,10 +64,9 @@ static int scan_ip(const char *buf, unsigned int *paddr)
> if (paddr)
> *paddr = part1 << 24 | part2 << 16 | part3 << 8 |
> part4;
> return 1;
> -   } else {
> -   printf("not good ip %d:%d:%d:%d/n", part1, part2, part3,
> part4);
> }
>
> +   printf("not good ip %d:%d:%d:%d/n", part1, part2, part3, part4);
> return 0;
>  }
>
> diff --git a/helper/test/odph_pause.c b/helper/test/pause.c
> similarity index 100%
> rename from helper/test/odph_pause.c
> rename to helper/test/pause.c
> diff --git a/helper/test/odp_process.c b/helper/test/process.c
> similarity index 96%
> rename from helper/test/odp_process.c
> rename to helper/test/process.c
> index cb9b328..6648627 100644
> --- a/helper/test/odp_process.c
> +++ b/helper/test/process.c
> @@ -53,7 +53,8 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
> cpu = odp_cpumask_first(_mask);
> printf("the first CPU:  %i\n", cpu);
>
> -   /* reserve cpu 0 for the control plane so remove it from the
> default mask */
> +   /* reserve cpu 0 for the control plane so remove it from
> +* the default mask */
> odp_cpumask_clr(_mask, 0);
> num_workers = odp_cpumask_count(_mask);
> (void)odp_cpumask_to_str(_mask, cpumaskstr,
> sizeof(cpumaskstr));
> diff 

Re: [lng-odp] Pool DMA mapping

[Bill Fischofer]

It's an application responsibility to ensure that a packet sent directly to
a pktio is in storage that is addressable to that interface.  For packets
being transmitted via the traffic manager (via odp_tm_enq()) again it is
the responsibility of the application to ensure that the tm system was
configured properly to be able to address the packets being enqueued to it.

Given that we don't have explicit NUMA support (yet) this is sort of a moot
point.  More germane to this question is adding NUMA information to the
odp_pool_param_t structure used on odp_pool_create().  That's where this
question becomes interesting.

On Wed, Dec 16, 2015 at 1:44 PM, Maxim Uvarov 
wrote:

> On 12/16/2015 19:48, Zoltan Kiss wrote:
>
>>
>>
>> On 16/12/15 16:47, Zoltan Kiss wrote:
>>
>>>
>>>
>>> On 16/12/15 15:39, Christophe Milard wrote:
>>>
 Hi,

 Following the discussion at the ARCH call, today, would it be reasonable
 to require that all packet pools that can be used by a NIC have to be
 created before the related nic pktio is opened? -This is implicitly
 required in RX, as the pool handle from which buffer should be allocated
 in RX is a parameter to the  pktio_open() function.

>>>
>>> Yes, for me it's quite obvious.
>>>
>> How you can do it opposite? odp_pktio_open() requires pool as parameter:
>
> odp_pktio_t odp_pktio_open(const char *dev, odp_pool_t pool,
>const odp_pktio_param_t *param)
>
>
>
>
>>> ? Is the fact that an
>>>
 application will not be able to transmit packets from a pool created
 AFTER pktio open() was called acceptable?

>>>
>>> I think TX is different from that point of view. The packet should
>>> obviously exist at the time of TX, but whether it came from the pool
>>> supplied to odp_pktio_open() or not shouldn't really matter.
>>>
>>
>> Or is there a particular reason you need this? I think I've missed during
>> the arch call why is this important.
>>
>>
>>>
 /Christophe.


 ___
 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
>>
>
> ___
> 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] [API-NEXT PATCH 00/19] Multi-queue pktio scheduler support

[Bill Fischofer]

For this series:

Reviewed-and-Tested-by: Bill Fischofer 

On Wed, Dec 16, 2015 at 7:45 AM, Petri Savolainen <
petri.savolai...@nokia.com> wrote:

>
> This patch set includes netmap implementation of the new pktio multi-queue
> API
> and scheduler integration.
>
> Netmap code is based on "netmap pktio multi queue support v2" patch series.
> Modifications include mainly bug fixes and performance optimizations,
> functionality is more or less the same (with previous patch set).
>
> Scheduler modifications enable multi-queue API usage with odp_queue_t
> queues
> (scheduled and poll type). L2fwd test application has been ported to use
> multi-queue API also with scheduled queues.
>
> Old pktio (single queue) interface is still functional. Next steps include
> removal of the old API.
>
>
> Matias Elo (13):
>   linux-generic: pktio: enable using PKTIO_MAX_QUEUES in pktio
> implementations
>   linux-generic: pktio: add RSS helper functions
>   linux-generic: netmap: add odp_pktio_start()
>   linux-generic: netmap: add odp_pktio_capability()
>   linux-generic: netmap: add initial multi queue support
>   linux-generic: netmap: add functions for fetching pktio queues
>   linux-generic: netmap: odp_pktio_recv() from all pktin queues
>   linux-generic: netmap: use select() instead of poll() in recv
>   linux-generic: netmap: add netmap_link_status() function
>   linux-generic: netmap: add netmap_close_descriptors() function
>   linux-generic: netmap: add start()/stop() functionality
>   linux-generic: netmap: fix netmap_mtu_get()
>   linux-generic: netmap: disable debug prints
>
> Petri Savolainen (6):
>   linux-generic: pktio: added scheduler multi-queue support
>   linux-generic: netmap: add scheduler multi-queue support
>   test: l2fwd: use multi-queue API for scheduled queues
>   test: l2fwd: use multiple queues in sched mode
>   linux-generic: scheduler: improve pktio polling
>   api: pktio: refine multiqueue API spec
>
>  include/odp/api/packet_io.h|  14 +-
>  .../linux-generic/include/odp_packet_io_internal.h |  19 +-
>  platform/linux-generic/include/odp_packet_netmap.h |  43 +-
>  platform/linux-generic/include/odp_packet_socket.h |  47 ++
>  .../linux-generic/include/odp_schedule_internal.h  |   3 +-
>  platform/linux-generic/odp_packet_io.c | 135 +++--
>  platform/linux-generic/odp_schedule.c  | 226 ---
>  platform/linux-generic/pktio/netmap.c  | 669
> ++---
>  platform/linux-generic/pktio/socket.c  | 234 +++
>  test/performance/odp_l2fwd.c   | 103 ++--
>  10 files changed, 1234 insertions(+), 259 deletions(-)
>
> --
> 2.6.3
>
> ___
> 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 v2] test: performance: add crypto test

[Mike Holmes]

with apply and build

Using patch: lng-odp_PATCH_v2_test_performance_add_crypto_test.mbox
  Trying to apply patch
  Patch applied

WARNING: 'Imediately' may be misspelled - perhaps 'Immediately'?
#645: FILE: test/performance/odp_crypto.c:582:
+ print_mem("Imediately encrypted packet", mem,

total: 0 errors, 1 warnings, 0 checks, 958 lines checked

And compiling

odp_crypto.c: In function ‘create_session_from_config’:
odp_crypto.c:428:33: error: storage size of ‘ses_create_rc’ isn’t known
  enum odp_crypto_ses_create_err ses_create_rc;
 ^
odp_crypto.c:428:33: error: unused variable ‘ses_create_rc’
[-Werror=unused-variable]
odp_crypto.c: In function ‘main’:
odp_crypto.c:777:17: error: implicit declaration of function
‘odp_cpumask_def_worker’ [-Werror=implicit-function-declaration]
   num_workers = odp_cpumask_def_worker(,
 ^
odp_crypto.c:777:3: error: nested extern declaration of
‘odp_cpumask_def_worker’ [-Werror=nested-externs]
   num_workers = odp_cpumask_def_worker(,
   ^
odp_crypto.c:795:4: error: too few arguments to function
‘odph_linux_pthread_create’
odph_linux_pthread_create(, ,
^
In file included from odp_crypto.c:20:0:
../../helper/include/odp/helper/linux.h:67:5: note: declared here
 int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
 ^
cc1: all warnings being treated as errors

So it looks like it needs a rebase.

On 4 November 2015 at 10:07, Nicolas Morey-Chaisemartin 
wrote:

>
> On 11/04/2015 09:12 AM, alexandru.badici...@linaro.org wrote:
> > From: Alexandru Badicioiu 
> >
> > Test program to measure crypto operation performance.
> > Measures the time required to launch and get the result
> > of ODP crypto operations in async and sync API mode with
> > configurable payload size, crypto algorithms and iteration
> > number.
> > Both asynchronous scheduled and polled are supported.
> > In scheduled mode a separate worker thread is used to
> > get the crypto completion events.
> > Output packet can be reused as the input of the next
> > operation or a new packet can be allocated for each
> > operation.
> > Based on a previous work :
> > https://lists.linaro.org/pipermail/lng-odp/2014-September/003251.html.
> >
> > Signed-off-by: Alexandru Badicioiu 
> > v1
> > ---
> > - replaced cspeed with crypto
> > - removed unused parameter core_count
> > v2
> > --
> > - alphabetical order in Makefile.am
> > - replaced pool params memset with init call
> >
> > ---
> >  test/performance/Makefile.am  |   5 +-
> >  test/performance/odp_crypto.c | 935
> ++
> >  2 files changed, 939 insertions(+), 1 deletion(-)
> >  create mode 100644 test/performance/odp_crypto.c
>
> > +/**
> > + * Snap current time values and put them into 'rec'.
> > + */
> > +static void
> > +fill_time_record(time_record_t *rec)
> > +{
> > + gettimeofday(>tv, NULL);
> > + getrusage(RUSAGE_SELF, >ru_self);
> > + getrusage(RUSAGE_THREAD, >ru_thread);
> This is *very* linux oriented and not platform agnostic.
> getrusage is POSIX 2001 (though we don't support it) but RUSAGE_THREAD is
> _GNU_SOURCE and kernel > 2.6.26
>
> Couldn't we use ODP API to keep track of time ?
>

Nicolas, in the call today we put out the idea that it would be better to
use an odp time api, but that maybe it was ok to use linux for now.
Re reading the patch I think this is problem since it will break on your
platform and not just be less clean, is that correct ?


> > +int main(int argc, char *argv[])
> > +{
> > + crypto_args_t cargs;
> > + odp_pool_t pool;
> > + odp_queue_param_t qparam;
> > + odp_pool_param_t params;
> > + odph_linux_pthread_t thr;
> > + odp_queue_t out_queue = ODP_QUEUE_INVALID;
> > + thr_arg_t thr_arg;
> > + int num_workers = 1;
> > + odp_cpumask_t cpumask;
> > + char cpumaskstr[ODP_CPUMASK_STR_SIZE];
> > +
> > + /* Parse and store the application arguments */
> > + parse_args(argc, argv, );
> > +
> > + /* Init ODP before calling anything else */
> > + if (odp_init_global(NULL, NULL)) {
> > + app_err("ODP global init failed.\n");
> > + exit(EXIT_FAILURE);
> > + }
> > +
> > + /* Init this thread */
> > + odp_init_local(ODP_THREAD_WORKER);
> > +
> > + /* Create packet pool */
> > + odp_pool_param_init();
> > + params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
> > + params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
> > + params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
> > + params.type= ODP_POOL_PACKET;
> > + pool = odp_pool_create("packet_pool", );
> > +
> > + if (pool == ODP_POOL_INVALID) {
> > + app_err("packet pool create failed.\n");
> > + exit(EXIT_FAILURE);
> > + }
> > + odp_pool_print(pool);
> > +
> > + if (cargs.schedule) {
> > + qparam.sched.prio  = 

Re: [lng-odp] [API-NEXT PATCH v2 0/6] api: time: add rate and delay APIs

[Mike Holmes]

On 16 December 2015 at 05:24, Ivan Khoronzhuk 
wrote:

>
>
> On 16.12.15 05:30, Mike Holmes wrote:
>
>>
>> On 15 December 2015 at 07:29, Ivan Khoronzhuk > > wrote:
>>
>> This series adds odp_time_local_res() and odp_time_wait() calls to
>> time API and it's validation tests and usage.
>>
>>
>> When do we start requiring that new api work comes with a corresponding
>> update to the user-guide <
>> http://docs.opendataplane.org/master/linux-generic/output/users-guide.html>
>> ?
>> I think we should just start now so that the doc get builts up and not
>> eroded by new API work.
>> This would be a new requirement just as adding validation tests already
>> is, and it would become a blocker on api work moving to master.
>>
> Time API after this series requires only global time API that is not very
> different from local time API.
> Only functions with "local" word will be duplicated with "global" word and
> it can be used between threads.
> The validation test for global time API will be slightly different. I
> think we can start but whole picture will be visible after
> adding global time API.
>

Ok, I am fine for it to live in api-next, but I think that to move to
master it needs to have a user-guide section added.



>
>
>>
>> Based on:
>> [lng-odp] [API-NEXT PATCHv4] linux-generic: time: remove posix bleed
>> through on odp_time_t
>> https://lists.linaro.org/pipermail/lng-odp/2015-December/018465.html
>>
>> Since v1:
>> - used "wait" instead of "delay"
>> - used "res" instead of "rate"
>> - used inlined functions in odp_time_wait()
>> - corrected new API descriptions
>>
>> Ivan Khoronzhuk (6):
>>api: time: add resolution and wait API calls
>>performance: pktio_perf: use odp_time_wait() function instead of
>>  looping
>>validation: time: test time constants in ns
>>validation: time: add test convertsion on 0
>>validation: time: add test for odp_time_local_res() and use
>> resolution
>>validation: time: add test for odp_time_wait()
>>
>>   include/odp/api/time.h| 17 
>>   platform/linux-generic/odp_time.c | 71
>> 
>>   test/performance/odp_pktio_perf.c | 17 +---
>>   test/validation/time/time.c   | 86
>> ---
>>   test/validation/time/time.h   |  3 ++
>>   5 files changed, 148 insertions(+), 46 deletions(-)
>>
>> --
>> 1.9.1
>>
>> ___
>> 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
>>
>> __
>>
>>
>>
> --
> Regards,
> Ivan Khoronzhuk
>



-- 
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

Re: [lng-odp] [PATCH] linux-generic: include netmap headers with -isystem

[Bill Fischofer]

On Tue, Dec 15, 2015 at 5:18 AM, Stuart Haslam 
wrote:

> The netmap header file has some dubious casts that generate errors when
> -Wcast-qual is enabled. Include it as a system header so that the
> compiler ignores those errors without having to ignore errors in our own
> source files.
>
> Signed-off-by: Stuart Haslam 
>

Reviewed-by: Bill Fischofer 


> ---
>  platform/linux-generic/m4/odp_netmap.m4 | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/platform/linux-generic/m4/odp_netmap.m4
> b/platform/linux-generic/m4/odp_netmap.m4
> index 72c3fab..d39301f 100644
> --- a/platform/linux-generic/m4/odp_netmap.m4
> +++ b/platform/linux-generic/m4/odp_netmap.m4
> @@ -14,7 +14,7 @@ AC_ARG_WITH([netmap-path],
>  AC_HELP_STRING([--with-netmap-path=DIR   path to netmap root directory],
> [(or in the default path if not specified).]),
>  [NETMAP_PATH=$withval
> -AM_CPPFLAGS="$AM_CPPFLAGS -I$NETMAP_PATH/sys"
> +AM_CPPFLAGS="$AM_CPPFLAGS -isystem $NETMAP_PATH/sys"
>  netmap_support=yes],[])
>
>  ##
> @@ -35,13 +35,7 @@ else
>  netmap_support=no
>  fi
>
> -# Disable cast errors until the problem in netmap_user.h is fixed upstream
> -if test x$netmap_support = xyes
> -then
> -ODP_CFLAGS_EXTRA="$ODP_CFLAGS_EXTRA -Wno-cast-qual"
> -fi
> -
>  ##
>  # Restore old saved variables
>  ##
> -CPPFLAGS=$OLD_CPPFLAGS
> \ No newline at end of file
> +CPPFLAGS=$OLD_CPPFLAGS
> --
> 2.1.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] [API-NEXT/PATCHv2 5/6] api: classification: rename odp_drop_e to odp_cls_drop_t

[Bala Manoharan]

Hi,

On 17 December 2015 at 08:54, Bill Fischofer  wrote:
>
>
> On Wed, Dec 16, 2015 at 3:28 AM, Balasubramanian Manoharan
>  wrote:
>>
>> Changes drop policy enum name from odp_drop_e to odp_cls_drop_t
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>  include/odp/api/classification.h | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index 4db5bf0..c9493c2 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -65,7 +65,7 @@ extern "C" {
>>  typedef enum odp_cls_drop {
>> ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
>> ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool
>> policy */
>> -} odp_drop_e;
>> +} odp_cls_drop_t;
>>
>>  /**
>>   * Packet header field enumeration
>> @@ -95,7 +95,7 @@ typedef enum odp_cos_hdr_flow_fields {
>>  typedef struct odp_cls_cos_param {
>> odp_queue_t queue;  /**< Queue associated with CoS */
>> odp_pool_t pool;/**< Pool associated with CoS */
>> -   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
>> +   odp_cls_drop_t drop_policy; /**< Drop policy associated with
>> CoS */
>
>
> Changing this to odp_cos_drop_t instead of odp_cls_drop_t would be more
> consistent.  The object metadata belongs to an odp_cos_t, not an odp_cls_t.

As explained in the previous mail odp_cls_xxx is used as a prefix
since it is common for PMR and CoS.

>
>>
>>  } odp_cls_cos_param_t;
>>
>>  /**
>> @@ -170,7 +170,7 @@ odp_queue_t odp_cos_queue(odp_cos_t cos_id);
>>   *
>>   * @note Optional.
>>   */
>> -int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e drop_policy);
>> +int odp_cos_drop_set(odp_cos_t cos_id, odp_cls_drop_t drop_policy);
>>
>>  /**
>>  * Get the drop policy configured for a specific class-of-service
>> instance.
>> @@ -180,7 +180,7 @@ int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e
>> drop_policy);
>>  * @retval  Drop policy configured with the given
>>  *  class-of-service
>>  */
>> -odp_drop_e odp_cos_drop(odp_cos_t cos_id);
>> +odp_cls_drop_t odp_cos_drop(odp_cos_t cos_id);
>
>
> Again odp_cos_drop should return an odp_cos_drop_t.  If the return type were
> odp_cls_drop_t then the function should be odp_cls_drop() for consistency,
> but odp_cos_drop() seems correct here.

Agreed.

Regards,
Bala
>>
>>
>>  /**
>>   * Request to override per-port class of service
>> --
>> 1.9.1
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>



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

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[HePeng]

Hi, Maxim

I will present a quick patch that will not pass the kernel style 
check as this one is just for evaluation. 


> 在 2015年12月16日，下午8:22，Maxim Uvarov  写道：
> 
> From meeting we decided that we want solution based on pool. Can you post that
> patches? We will try to help how to improve performance.
> 
> Maxim.
> 
> On 12/14/2015 22:30, Mike Holmes wrote:
>> Added to Tuesday agenda
>> 
>> On 12 December 2015 at 22:18, HePeng > > wrote:
>> 
>>Ping.
>> 
>>So what is your decision on this.
>> 
>>>在 2015年12月10日，下午1:06，HePeng >>> 写道：
>>> 
 
在 2015年12月9日，下午6:49，Ola Liljedahl
> 写道：
 
On 9 December 2015 at 06:31, HePeng>wrote:
 
 
>在 2015年12月8日，下午9:34，Ola Liljedahl
>> 写道：
> 
>On 8 December 2015 at 12:42, Bill
>Fischofer>wrote:
> 
>This is an interesting topic.  I'd like to discuss this
>a bit during today's ODP public call.
> 
>I think the issue is that while a ring is a very useful
>implementation construct its semantics are very SW centric.
> 
>But isn't the use case here SW centric?
> 
>Perhaps there's opportunity here for a new Queue type
>that would permit an implementation to implement the
>queue API as a ring for additional performance?
> 
>I think it is a bad idea to overload the ODP queue with
>another type of usage and implied implementation. Better to
>define a new ODP object.
> 
>What are the real requirements of the "ring" as used by the
>cuckoo hash design? Enqueue/dequeue operations. Fixed size
>is OK? Storing arbitrary objects (not just ODP events)?
 
The real requirement is use the ring as a sort of container.
Fixed Size is OK. And the ring should be used to
store any ODP events, since it is used as a container,
like vector in C++ STL.
 
What if I would like to store objects that are not ODP events in
the cuckoo hash table? E.g. arbitrary pointers (to memory that
is managed in some other way).
 
>>>Yes, that is currently ring’s implementation.
>>> 
>>> 
 
 
> 
>  The scheduler itself could use this since its use of
>queues is subject to the same issues.
> 
>On Mon, Dec 7, 2015 at 11:39 PM,
>HePeng>wrote:
> 
>Hi Maxim,
>I implement a new version of cuckoo hash
>based on the ODP buffer/pool.
> 
>As I’ve mentioned earlier, the use of ring
>in cuckoo hash is like to the use of
>a container, e.g. a queue in C++ STL. In current
>ODP implementation, I found that
>the ODP queue is implemented more likely a facility
>for transmitting objects, not
>a container to store objects. Look at the ODP queue
>enqueue interface:
> 
>int odp_queue_enq(odp_queue_t queue,
>odp_event_t ev);
> 
>the *odp_event_t* is related to the events, but I
>only want to use odp_queue to
>storing and retrieving objects, any objects.
> 
> 
>So I use ODP buffer/pool interfaces instead
>of ODP queue
>for the new cuckoo hash implementation.
> 
>However, compared to the previous implementation
>based on ring, this version
>suffers a serious performance degradation. The
>evaluation is carried out on a Intel
>servers. I test lookup time for 1000 lookups on a
>table storing 1 million items.
>The ODP buffer/pool version suffers at least a 2x
>performance degradation.
> 
>This is the buffer/pool version, for 1M insert, and
>1000 lookup time:
> 
>Average insert time = 2.383836, lookup time = 0.000353,
> 
>This is the ring version.
> 
>Average insert time = 1.629115, lookup time = 0.98
> 
>  

Re: [lng-odp] [PATCH v2] test: performance: add crypto test

[Alexandru Badicioiu]

On 17 December 2015 at 00:50, Mike Holmes  wrote:

> with apply and build
>
> Using patch: lng-odp_PATCH_v2_test_performance_add_crypto_test.mbox
>   Trying to apply patch
>   Patch applied
>
> WARNING: 'Imediately' may be misspelled - perhaps 'Immediately'?
> #645: FILE: test/performance/odp_crypto.c:582:
> + print_mem("Imediately encrypted packet", mem,
>
> total: 0 errors, 1 warnings, 0 checks, 958 lines checked
>
> And compiling
>
> odp_crypto.c: In function ‘create_session_from_config’:
> odp_crypto.c:428:33: error: storage size of ‘ses_create_rc’ isn’t known
>   enum odp_crypto_ses_create_err ses_create_rc;
>  ^
> odp_crypto.c:428:33: error: unused variable ‘ses_create_rc’
> [-Werror=unused-variable]
> odp_crypto.c: In function ‘main’:
> odp_crypto.c:777:17: error: implicit declaration of function
> ‘odp_cpumask_def_worker’ [-Werror=implicit-function-declaration]
>num_workers = odp_cpumask_def_worker(,
>  ^
> odp_crypto.c:777:3: error: nested extern declaration of
> ‘odp_cpumask_def_worker’ [-Werror=nested-externs]
>num_workers = odp_cpumask_def_worker(,
>^
> odp_crypto.c:795:4: error: too few arguments to function
> ‘odph_linux_pthread_create’
> odph_linux_pthread_create(, ,
> ^
> In file included from odp_crypto.c:20:0:
> ../../helper/include/odp/helper/linux.h:67:5: note: declared here
>  int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
>  ^
> cc1: all warnings being treated as errors
>
> So it looks like it needs a rebase.
>
[Alex] Patch is a bit old, I'll rebase to latest ODP master.

>
> On 4 November 2015 at 10:07, Nicolas Morey-Chaisemartin 
> wrote:
>
>>
>> On 11/04/2015 09:12 AM, alexandru.badici...@linaro.org wrote:
>> > From: Alexandru Badicioiu 
>> >
>> > Test program to measure crypto operation performance.
>> > Measures the time required to launch and get the result
>> > of ODP crypto operations in async and sync API mode with
>> > configurable payload size, crypto algorithms and iteration
>> > number.
>> > Both asynchronous scheduled and polled are supported.
>> > In scheduled mode a separate worker thread is used to
>> > get the crypto completion events.
>> > Output packet can be reused as the input of the next
>> > operation or a new packet can be allocated for each
>> > operation.
>> > Based on a previous work :
>> > https://lists.linaro.org/pipermail/lng-odp/2014-September/003251.html.
>> >
>> > Signed-off-by: Alexandru Badicioiu 
>> > v1
>> > ---
>> > - replaced cspeed with crypto
>> > - removed unused parameter core_count
>> > v2
>> > --
>> > - alphabetical order in Makefile.am
>> > - replaced pool params memset with init call
>> >
>> > ---
>> >  test/performance/Makefile.am  |   5 +-
>> >  test/performance/odp_crypto.c | 935
>> ++
>> >  2 files changed, 939 insertions(+), 1 deletion(-)
>> >  create mode 100644 test/performance/odp_crypto.c
>>
>> > +/**
>> > + * Snap current time values and put them into 'rec'.
>> > + */
>> > +static void
>> > +fill_time_record(time_record_t *rec)
>> > +{
>> > + gettimeofday(>tv, NULL);
>> > + getrusage(RUSAGE_SELF, >ru_self);
>> > + getrusage(RUSAGE_THREAD, >ru_thread);
>> This is *very* linux oriented and not platform agnostic.
>> getrusage is POSIX 2001 (though we don't support it) but RUSAGE_THREAD is
>> _GNU_SOURCE and kernel > 2.6.26
>>
>> Couldn't we use ODP API to keep track of time ?
>>
>
> Nicolas, in the call today we put out the idea that it would be better to
> use an odp time api, but that maybe it was ok to use linux for now.
> Re reading the patch I think this is problem since it will break on your
> platform and not just be less clean, is that correct ?
>
>
>> > +int main(int argc, char *argv[])
>> > +{
>> > + crypto_args_t cargs;
>> > + odp_pool_t pool;
>> > + odp_queue_param_t qparam;
>> > + odp_pool_param_t params;
>> > + odph_linux_pthread_t thr;
>> > + odp_queue_t out_queue = ODP_QUEUE_INVALID;
>> > + thr_arg_t thr_arg;
>> > + int num_workers = 1;
>> > + odp_cpumask_t cpumask;
>> > + char cpumaskstr[ODP_CPUMASK_STR_SIZE];
>> > +
>> > + /* Parse and store the application arguments */
>> > + parse_args(argc, argv, );
>> > +
>> > + /* Init ODP before calling anything else */
>> > + if (odp_init_global(NULL, NULL)) {
>> > + app_err("ODP global init failed.\n");
>> > + exit(EXIT_FAILURE);
>> > + }
>> > +
>> > + /* Init this thread */
>> > + odp_init_local(ODP_THREAD_WORKER);
>> > +
>> > + /* Create packet pool */
>> > + odp_pool_param_init();
>> > + params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
>> > + params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
>> > + params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
>> > + params.type= ODP_POOL_PACKET;
>> > + pool = 

Re: [lng-odp] [API-NEXT/PATCHv2 1/6] api: classification: add class of serivce create api

[Bala Manoharan]

The reason for having odp_cls_xxx is that class of service module
contains class of service and packet matching rule and we need a
common syntax to identify the module hence odp_cls_xxx is used as
common prefix.

I agree all the functions in classifier module needs to be changed to
add the prefix odp_cls_xxx.I will add the rename as a separate patch
for the remaining functions.

Regards,
Bala

On 17 December 2015 at 08:51, Bill Fischofer  wrote:
>
>
> On Wed, Dec 16, 2015 at 3:28 AM, Balasubramanian Manoharan
>  wrote:
>>
>> class of service create function now takes pool, queue, drop policy and
>> name as input parameters.
>> Adds class of service parameter structure odp_cls_cos_param_t and
>> initialization function odp_cls_cos_param_init()
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>> v2: additional documentation and review comments from Petri
>>
>>  include/odp/api/classification.h | 37
>> +++--
>>  1 file changed, 31 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/odp/api/classification.h
>> b/include/odp/api/classification.h
>> index 725e1ab..4db5bf0 100644
>> --- a/include/odp/api/classification.h
>> +++ b/include/odp/api/classification.h
>> @@ -37,7 +37,7 @@ extern "C" {
>>
>>  /**
>>   * @def ODP_COS_INVALID
>> - * This value is returned from odp_cos_create() on failure,
>> + * This value is returned from odp_cls_cos_create() on failure,
>>   * May also be used as a sink class of service that
>>   * results in packets being discarded.
>>   */
>> @@ -60,9 +60,9 @@ extern "C" {
>>   */
>>
>>  /**
>> - * Class-of-service packet drop policies
>> + * class of service packet drop policies
>>   */
>> -typedef enum odp_cos_drop {
>> +typedef enum odp_cls_drop {
>> ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
>> ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool
>> policy */
>>  } odp_drop_e;
>> @@ -89,14 +89,39 @@ typedef enum odp_cos_hdr_flow_fields {
>>  } odp_cos_hdr_flow_fields_e;
>>
>>  /**
>> + * Class of service parameters
>> + * Used to communicate class of service creation options
>> + */
>> +typedef struct odp_cls_cos_param {
>> +   odp_queue_t queue;  /**< Queue associated with CoS */
>> +   odp_pool_t pool;/**< Pool associated with CoS */
>> +   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
>> +} odp_cls_cos_param_t;
>
>
> Why odp_cls_cos_param_t and not just odp_cos_param_t ?  See remarks under
> odp_cls_cos_create().  If that's changed then it would be consistent to
> change this as well.
>
>>
>> +
>> +/**
>> + * Initialize class of service parameters
>> + *
>> + * Initialize an odp_cls_cos_param_t to its default value for all fields
>> + *
>> + * @param param   Address of the odp_cls_cos_param_t to be initialized
>> + */
>> +void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
>> +
>> +/**
>>   * Create a class-of-service
>>   *
>> - * @param[in]  nameString intended for debugging purposes.
>> + * @param  nameString intended for debugging purposes.
>>   *
>> - * @return Class of service instance identifier
>> + * @param  param   class of service parameters
>> + *
>> + * @retval class of service handle
>>   * @retval ODP_COS_INVALID on failure.
>> + *
>> + * @note ODP_QUEUE_INVALID and ODP_POOL_INVALID are valid values for
>> queue
>> + * and pool associated with a class of service and when any one of these
>> values
>> + * are configured as INVALID then the packets assigned to the CoS gets
>> dropped.
>>   */
>> -odp_cos_t odp_cos_create(const char *name);
>> +odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t
>> *param);
>
>
> The additional parameter seems reasonable, but it's not clear why the
> function needs to be renamed cos already stands for Class of Service so
> odp_cls_cos_create() expands to ODP Classifier Class of Service Create which
> seems somewhat redundant.  It's also inconsistent in that the created object
> is of type odp_cos_t, not odp_cls_cos_t and is non-symmetric with the
> existing odp_cos_destroy() function.  I'd leave this as just
> odp_cos_create() with the additional parameter.
>>
>>
>>  /**
>>   * Discard a class-of-service along with all its associated resources
>> --
>> 1.9.1
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>



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

Re: [lng-odp] odp_cpumask_default_worker() calls from worker threads

[Bill Fischofer]

On Tue, Dec 15, 2015 at 6:58 PM, Zoltan Kiss  wrote:

> Hi,
>
> I have a question: is it allowed to call these functions from worker
> threads? The current linux-generic implementation doesn't seem to support
> that, because it checks for the affinity of the current thread. In case of
> a worker it is probably restricted for one CPU.
>

I'm not sure how you conclude that.  The documentation calls
pthread_getaffinity_np() and according to its documentation:

After a call to *pthread_setaffinity_np*(), the set of CPUs on which the
thread will actually run is the intersection of the set specified in the
*cpuset* argument and the set of CPUs actually present on the system. The
system may further restrict the set of CPUs on which the thread runs if the
"cpuset" mechanism described in *cpuset
(7)* is being used. These restrictions
on the actual set of CPUs on which the thread will run are silently imposed
by the kernel.

So the call is simply inquring as to the current affinity of the thread  so
that it can count them.


> It seems to me that "how to create a thread and what affinity it should
> have" is not part of the API, so probably implementation shouldn't rely on
> the calling thread's affinity when working out how many workers should
> there be.
>
> Regards,
>
> Zoltan
> ___
> 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] [API-NEXT/PATCHv2 1/6] api: classification: add class of serivce create api

[Bill Fischofer]

On Wed, Dec 16, 2015 at 3:28 AM, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:

> class of service create function now takes pool, queue, drop policy and
> name as input parameters.
> Adds class of service parameter structure odp_cls_cos_param_t and
> initialization function odp_cls_cos_param_init()
>
> Signed-off-by: Balasubramanian Manoharan 
> ---
> v2: additional documentation and review comments from Petri
>
>  include/odp/api/classification.h | 37
> +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/include/odp/api/classification.h
> b/include/odp/api/classification.h
> index 725e1ab..4db5bf0 100644
> --- a/include/odp/api/classification.h
> +++ b/include/odp/api/classification.h
> @@ -37,7 +37,7 @@ extern "C" {
>
>  /**
>   * @def ODP_COS_INVALID
> - * This value is returned from odp_cos_create() on failure,
> + * This value is returned from odp_cls_cos_create() on failure,
>   * May also be used as a sink class of service that
>   * results in packets being discarded.
>   */
> @@ -60,9 +60,9 @@ extern "C" {
>   */
>
>  /**
> - * Class-of-service packet drop policies
> + * class of service packet drop policies
>   */
> -typedef enum odp_cos_drop {
> +typedef enum odp_cls_drop {
> ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
> ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool
> policy */
>  } odp_drop_e;
> @@ -89,14 +89,39 @@ typedef enum odp_cos_hdr_flow_fields {
>  } odp_cos_hdr_flow_fields_e;
>
>  /**
> + * Class of service parameters
> + * Used to communicate class of service creation options
> + */
> +typedef struct odp_cls_cos_param {
> +   odp_queue_t queue;  /**< Queue associated with CoS */
> +   odp_pool_t pool;/**< Pool associated with CoS */
> +   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
> +} odp_cls_cos_param_t;
>

Why odp_cls_cos_param_t and not just odp_cos_param_t ?  See remarks under
odp_cls_cos_create().  If that's changed then it would be consistent to
change this as well.


> +
> +/**
> + * Initialize class of service parameters
> + *
> + * Initialize an odp_cls_cos_param_t to its default value for all fields
> + *
> + * @param param   Address of the odp_cls_cos_param_t to be initialized
> + */
> +void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
> +
> +/**
>   * Create a class-of-service
>   *
> - * @param[in]  nameString intended for debugging purposes.
> + * @param  nameString intended for debugging purposes.
>   *
> - * @return Class of service instance identifier
> + * @param  param   class of service parameters
> + *
> + * @retval class of service handle
>   * @retval ODP_COS_INVALID on failure.
> + *
> + * @note ODP_QUEUE_INVALID and ODP_POOL_INVALID are valid values for queue
> + * and pool associated with a class of service and when any one of these
> values
> + * are configured as INVALID then the packets assigned to the CoS gets
> dropped.
>   */
> -odp_cos_t odp_cos_create(const char *name);
> +odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t
> *param);
>

The additional parameter seems reasonable, but it's not clear why the
function needs to be renamed cos already stands for Class of Service so
odp_cls_cos_create() expands to ODP Classifier Class of Service Create
which seems somewhat redundant.  It's also inconsistent in that the created
object is of type odp_cos_t, not odp_cls_cos_t and is non-symmetric with
the existing odp_cos_destroy() function.  I'd leave this as just
odp_cos_create() with the additional parameter.

>
>  /**
>   * Discard a class-of-service along with all its associated resources
> --
> 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 v1] doc/users-guide: add cryptographic services section

[Bill Fischofer]

This needs significant expansion, but it's a worthwhile start.

On Tue, Dec 15, 2015 at 6:01 AM,  wrote:

> From: Alexandru Badicioiu 


> Signed-off-by: Alexandru Badicioiu 
>

Reviewed-by: Bill Fischofer 


> ---
>  doc/users-guide/users-guide.adoc | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 2e30f3a..7ec7957 100644
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -738,6 +738,27 @@ NOTE: Both ordered and parallel queues improve
> throughput over atomic queues
>  due to parallel event processing, but require that the application take
>  steps to ensure context data synchronization if needed.
>
> +=== Cryptographic services
> +
> +ODP provides support for cryptographic operations required by various
> security
> +protocols (e.g. IPSec). To apply a cryptographic operation to a packet a
> session
> +must be created first. Packets processed by a session share the same
> cryptographic
> +parameters like algorithms, keys, initialization vectors. A session is
> created with
> +odp_crypto_session_create() call. After session creation a cryptographic
> operation
> +can be applied to a packet using odp_crypto_operation() call.
> +Depending on the session type - synchronous or asynchronous the operation
> returns
> +when the operation completed or after the request has been submitted. In
> the
> +asynchronous case an operation completion event will be enqueued on the
> session
> +completion queue. The completion event conveys the status of the
> operation and
> +the result. The application has the responsibility to free the completion
> event.
> +The operation arguments specify for each packet the areas which are to be
> encrypted
> +or decrypted and authenticated. Also, in asynchronous case a context can
> be
> +associated with a given operation and when the operation completion event
> is
> +retrieved the associated context can be retrieved. An operation can be
> executed
> +in-place, when the output packet is the same as the input packet or the
> output
> +packet can be a new packet provided by the application or allocated by the
> +implementation from the session output pool.
> +
>  == Glossary
>  [glossary]
>  worker thread::
> --
> 1.9.3
>
> ___
> 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] api: packet: add detailed packet error api

[Bill Fischofer]

This should be marked API-NEXT, but assuming that can be fixed during
merge...

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

> Adds api to get packet error flags for L2, L3 and L4 errors.
>
> Signed-off-by: Balasubramanian Manoharan 
>

Reviewed-and-Tested-by: Bill Fischofer 


> ---
>  include/odp/api/packet_flags.h| 33
> +++
>  platform/linux-generic/odp_packet_flags.c | 32
> ++
>  2 files changed, 65 insertions(+)
>
> diff --git a/include/odp/api/packet_flags.h
> b/include/odp/api/packet_flags.h
> index 7c3b247..c4a6832 100644
> --- a/include/odp/api/packet_flags.h
> +++ b/include/odp/api/packet_flags.h
> @@ -38,6 +38,17 @@ extern "C" {
>  int odp_packet_has_error(odp_packet_t pkt);
>
>  /**
> + * check for packet L2 error
> + *
> + * checks for all L2 errors
> + *
> + * @param pkt Packet handle
> + * @retval non-zero packet has L2 errors
> + * @retval 0 packet has no L2 error
> + */
> +int odp_packet_has_l2_error(odp_packet_t pkt);
> +
> +/**
>   * Check for L2 header, e.g. ethernet
>   *
>   * @param pkt Packet handle
> @@ -47,6 +58,17 @@ int odp_packet_has_error(odp_packet_t pkt);
>  int odp_packet_has_l2(odp_packet_t pkt);
>
>  /**
> + * check for packet L3 error
> + *
> + * checks for all L3 errors
> + *
> + * @param pkt Packet handle
> + * @retval non-zero packet has L3 errors
> + * @retval 0 packet has no L3 error
> + */
> +int odp_packet_has_l3_error(odp_packet_t pkt);
> +
> +/**
>   * Check for L3 header, e.g. IPv4, IPv6
>   *
>   * @param pkt Packet handle
> @@ -56,6 +78,17 @@ int odp_packet_has_l2(odp_packet_t pkt);
>  int odp_packet_has_l3(odp_packet_t pkt);
>
>  /**
> + * check for packet L4 error
> + *
> + * checks for all L4 errors
> + *
> + * @param pkt Packet handle
> + * @retval non-zero packet has L4 errors
> + * @retval 0 packet has no L2 error
> + */
> +int odp_packet_has_l4_error(odp_packet_t pkt);
> +
> +/**
>   * Check for L4 header, e.g. UDP, TCP, SCTP (also ICMP)
>   *
>   * @param pkt Packet handle
> diff --git a/platform/linux-generic/odp_packet_flags.c
> b/platform/linux-generic/odp_packet_flags.c
> index dbc3137..68a79bc 100644
> --- a/platform/linux-generic/odp_packet_flags.c
> +++ b/platform/linux-generic/odp_packet_flags.c
> @@ -38,16 +38,48 @@ int odp_packet_has_l2(odp_packet_t pkt)
> return pkt_hdr->input_flags.l2;
>  }
>
> +int odp_packet_has_l2_error(odp_packet_t pkt)
> +{
> +   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
> +
> +   if (packet_parse_not_complete(pkt_hdr))
> +   packet_parse_full(pkt_hdr);
> +
> +   return pkt_hdr->error_flags.frame_len
> +   | pkt_hdr->error_flags.snap_len
> +   | pkt_hdr->error_flags.l2_chksum;
> +}
> +
>  int odp_packet_has_l3(odp_packet_t pkt)
>  {
> retflag(pkt, input_flags.l3);
>  }
>
> +int odp_packet_has_l3_error(odp_packet_t pkt)
> +{
> +   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
> +
> +   if (packet_parse_not_complete(pkt_hdr))
> +   packet_parse_full(pkt_hdr);
> +
> +   return pkt_hdr->error_flags.ip_err;
> +}
> +
>  int odp_packet_has_l4(odp_packet_t pkt)
>  {
> retflag(pkt, input_flags.l4);
>  }
>
> +int odp_packet_has_l4_error(odp_packet_t pkt)
> +{
> +   odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
> +
> +   if (packet_parse_not_complete(pkt_hdr))
> +   packet_parse_full(pkt_hdr);
> +
> +   return pkt_hdr->error_flags.tcp_err | pkt_hdr->error_flags.udp_err;
> +}
> +
>  int odp_packet_has_eth(odp_packet_t pkt)
>  {
> odp_packet_hdr_t *pkt_hdr = odp_packet_hdr(pkt);
> --
> 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 v2] test: performance: add crypto test

[Nicolas Morey-Chaisemartin]

On 12/16/2015 11:50 PM, Mike Holmes wrote:
> with apply and build
>
> Using patch: lng-odp_PATCH_v2_test_performance_add_crypto_test.mbox
>   Trying to apply patch
>   Patch applied
>
> WARNING: 'Imediately' may be misspelled - perhaps 'Immediately'?
> #645: FILE: test/performance/odp_crypto.c:582:
> + print_mem("Imediately encrypted packet", mem,
>
> total: 0 errors, 1 warnings, 0 checks, 958 lines checked
>
> And compiling
>
> odp_crypto.c: In function ‘create_session_from_config’:
> odp_crypto.c:428:33: error: storage size of ‘ses_create_rc’ isn’t known
>   enum odp_crypto_ses_create_err ses_create_rc;
>  ^
> odp_crypto.c:428:33: error: unused variable ‘ses_create_rc’ 
> [-Werror=unused-variable]
> odp_crypto.c: In function ‘main’:
> odp_crypto.c:777:17: error: implicit declaration of function 
> ‘odp_cpumask_def_worker’ [-Werror=implicit-function-declaration]
>num_workers = odp_cpumask_def_worker(,
>  ^
> odp_crypto.c:777:3: error: nested extern declaration of 
> ‘odp_cpumask_def_worker’ [-Werror=nested-externs]
>num_workers = odp_cpumask_def_worker(,
>^
> odp_crypto.c:795:4: error: too few arguments to function 
> ‘odph_linux_pthread_create’
> odph_linux_pthread_create(, ,
> ^
> In file included from odp_crypto.c:20:0:
> ../../helper/include/odp/helper/linux.h:67:5: note: declared here
>  int odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
>  ^
> cc1: all warnings being treated as errors
>
> So it looks like it needs a rebase.
>
> On 4 November 2015 at 10:07, Nicolas Morey-Chaisemartin  > wrote:
>
>
> On 11/04/2015 09:12 AM, alexandru.badici...@linaro.org 
>  wrote:
> > From: Alexandru Badicioiu  >
> >
> > Test program to measure crypto operation performance.
> > Measures the time required to launch and get the result
> > of ODP crypto operations in async and sync API mode with
> > configurable payload size, crypto algorithms and iteration
> > number.
> > Both asynchronous scheduled and polled are supported.
> > In scheduled mode a separate worker thread is used to
> > get the crypto completion events.
> > Output packet can be reused as the input of the next
> > operation or a new packet can be allocated for each
> > operation.
> > Based on a previous work :
> > https://lists.linaro.org/pipermail/lng-odp/2014-September/003251.html.
> >
> > Signed-off-by: Alexandru Badicioiu  >
> > v1
> > ---
> > - replaced cspeed with crypto
> > - removed unused parameter core_count
> > v2
> > --
> > - alphabetical order in Makefile.am
> > - replaced pool params memset with init call
> >
> > ---
> >  test/performance/Makefile.am  |   5 +-
> >  test/performance/odp_crypto.c | 935 
> ++
> >  2 files changed, 939 insertions(+), 1 deletion(-)
> >  create mode 100644 test/performance/odp_crypto.c
>
> > +/**
> > + * Snap current time values and put them into 'rec'.
> > + */
> > +static void
> > +fill_time_record(time_record_t *rec)
> > +{
> > + gettimeofday(>tv, NULL);
> > + getrusage(RUSAGE_SELF, >ru_self);
> > + getrusage(RUSAGE_THREAD, >ru_thread);
> This is *very* linux oriented and not platform agnostic.
> getrusage is POSIX 2001 (though we don't support it) but RUSAGE_THREAD is 
> _GNU_SOURCE and kernel > 2.6.26
>
> Couldn't we use ODP API to keep track of time ?
>
>
> Nicolas, in the call today we put out the idea that it would be better to use 
> an odp time api, but that maybe it was ok to use linux for now.
> Re reading the patch I think this is problem since it will break on your 
> platform and not just be less clean, is that correct ?
>
Yes it will. I can get it to compile by removing the getrusage but a perf test 
without perf isn't very useful.

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

[lng-odp] [API-NEXT PATCH 13/19] linux-generic: netmap: disable debug prints

[Petri Savolainen]

From: Matias Elo 

Disable printing of tens of lines of unnecessary debug info
per netmap port.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/netmap.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 826050f..042e4e7 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -24,6 +24,13 @@
 #include 
 #include 
 
+/* Disable netmap debug prints */
+#ifndef ND
+#define ND(_fmt, ...) do {} while (0)
+#define D(_fmt, ...) do {} while (0)
+#define RD(lps, format, ...) do {} while (0)
+#endif
+
 #define NETMAP_WITH_LIBS
 #include 
 
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 04/19] linux-generic: netmap: add odp_pktio_capability()

[Petri Savolainen]

From: Matias Elo 

Implemented odp_pktio_capability() function in netmap.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  2 ++
 platform/linux-generic/pktio/netmap.c  | 17 -
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index 84bea65..a088d23 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -7,6 +7,7 @@
 #ifndef ODP_PACKET_NETMAP_H
 #define ODP_PACKET_NETMAP_H
 
+#include 
 #include 
 
 #include 
@@ -22,6 +23,7 @@ typedef struct {
int sockfd; /**< control socket */
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
+   odp_pktio_capability_t  capa;   /**< interface capabilities */
 } pkt_netmap_t;
 
 #endif
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index e7f4af5..38cdd1f 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -130,6 +130,14 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
ODP_ERR("nm_open(%s) failed\n", pkt_nm->nm_name);
goto error;
}
+   pkt_nm->capa.max_input_queues = PKTIO_MAX_QUEUES;
+   if (desc->nifp->ni_rx_rings < PKTIO_MAX_QUEUES)
+   pkt_nm->capa.max_input_queues = desc->nifp->ni_rx_rings;
+
+   pkt_nm->capa.max_output_queues = PKTIO_MAX_QUEUES;
+   if (desc->nifp->ni_tx_rings < PKTIO_MAX_QUEUES)
+   pkt_nm->capa.max_output_queues = desc->nifp->ni_tx_rings;
+
nm_close(desc);
 
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
@@ -355,6 +363,13 @@ static int netmap_promisc_mode_get(pktio_entry_t 
*pktio_entry)
   pktio_entry->s.name);
 }
 
+static int netmap_capability(pktio_entry_t *pktio_entry,
+odp_pktio_capability_t *capa)
+{
+   *capa = pktio_entry->s.pkt_nm.capa;
+   return 0;
+}
+
 const pktio_if_ops_t netmap_pktio_ops = {
.name = "netmap",
.init = NULL,
@@ -369,7 +384,7 @@ const pktio_if_ops_t netmap_pktio_ops = {
.promisc_mode_set = netmap_promisc_mode_set,
.promisc_mode_get = netmap_promisc_mode_get,
.mac_get = netmap_mac_addr_get,
-   .capability = NULL,
+   .capability = netmap_capability,
.input_queues_config = NULL,
.output_queues_config = NULL,
.in_queues = NULL,
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 07/19] linux-generic: netmap: odp_pktio_recv() from all pktin queues

[Petri Savolainen]

From: Matias Elo 

Receive packets from all pktin queues. Improves backward
compatibility.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  1 +
 platform/linux-generic/pktio/netmap.c  | 22 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index bede176..88661aa 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -46,6 +46,7 @@ typedef struct {
odp_pktio_capability_t  capa;   /**< interface capabilities */
unsigned num_rx_queues; /**< number of pktin queues */
unsigned num_tx_queues; /**< number of pktout queues */
+   unsigned cur_rx_queue;  /**< current pktin queue */
uint32_t num_rx_rings;  /**< number of nm rx rings */
uint32_t num_tx_rings;  /**< number of nm tx rings */
odp_bool_t lockless_rx; /**< no locking for rx */
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 97d0382..29474c1 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -577,7 +577,27 @@ static int netmap_recv_queue(pktio_entry_t *pktio_entry, 
int index,
 static int netmap_recv(pktio_entry_t *pktio_entry, odp_packet_t pkt_table[],
   unsigned num)
 {
-   return netmap_recv_queue(pktio_entry, 0, pkt_table, num);
+   unsigned i;
+   unsigned num_rx = 0;
+   unsigned queue_id = pktio_entry->s.pkt_nm.cur_rx_queue;
+   unsigned num_queues = pktio_entry->s.pkt_nm.num_rx_queues;
+   unsigned pkts_left = num;
+   odp_packet_t *pkt_table_cur = pkt_table;
+
+   for (i = 0; i < num_queues && num_rx != num; i++) {
+   if (queue_id >= num_queues)
+   queue_id = 0;
+
+   pkt_table_cur = _table[num_rx];
+   pkts_left = num - num_rx;
+
+   num_rx +=  netmap_recv_queue(pktio_entry, queue_id,
+pkt_table_cur, pkts_left);
+   queue_id++;
+   }
+   pktio_entry->s.pkt_nm.cur_rx_queue = queue_id;
+
+   return num_rx;
 }
 
 static int netmap_send_queue(pktio_entry_t *pktio_entry, int index,
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 05/19] linux-generic: netmap: add initial multi queue support

[Petri Savolainen]

From: Matias Elo 

Added multi queue support to netmap pktio.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  34 +-
 platform/linux-generic/pktio/netmap.c  | 422 ++---
 2 files changed, 403 insertions(+), 53 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index a088d23..bede176 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -7,23 +7,53 @@
 #ifndef ODP_PACKET_NETMAP_H
 #define ODP_PACKET_NETMAP_H
 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
 
+#define NM_MAX_DESC 32
+
+/** Ring for mapping pktin/pktout queues to netmap descriptors */
+struct netmap_ring_t {
+   unsigned first; /**< Index of first netmap descriptor */
+   unsigned last;  /**< Index of last netmap descriptor */
+   unsigned num;   /**< Number of netmap descriptors */
+   /** Netmap metadata for the device */
+   struct nm_desc *desc[NM_MAX_DESC];
+   unsigned cur;   /**< Index of current netmap descriptor */
+   odp_ticketlock_t lock;  /**< Queue lock */
+};
+
+typedef union {
+   struct netmap_ring_t s;
+   uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(struct netmap_ring_t))];
+} netmap_ring_t ODP_ALIGNED_CACHE;
+
 /** Packet socket using netmap mmaped rings for both Rx and Tx */
 typedef struct {
odp_pool_t pool;/**< pool to alloc packets from */
size_t max_frame_len;   /**< buf_size - sizeof(pkt_hdr) */
-   struct nm_desc *rx_desc;/**< netmap meta-data for the device */
-   struct nm_desc *tx_desc;/**< netmap meta-data for the device */
uint32_t if_flags;  /**< interface flags */
int sockfd; /**< control socket */
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
odp_pktio_capability_t  capa;   /**< interface capabilities */
+   unsigned num_rx_queues; /**< number of pktin queues */
+   unsigned num_tx_queues; /**< number of pktout queues */
+   uint32_t num_rx_rings;  /**< number of nm rx rings */
+   uint32_t num_tx_rings;  /**< number of nm tx rings */
+   odp_bool_t lockless_rx; /**< no locking for rx */
+   odp_bool_t lockless_tx; /**< no locking for tx */
+   /** mapping of pktin queues to netmap rx descriptors */
+   netmap_ring_t rx_desc_ring[PKTIO_MAX_QUEUES];
+   /** mapping of pktout queues to netmap tx descriptors */
+   netmap_ring_t tx_desc_ring[PKTIO_MAX_QUEUES];
 } pkt_netmap_t;
 
 #endif
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 38cdd1f..38a7d46 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -10,9 +10,9 @@
 #define _GNU_SOURCE
 #endif
 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -78,14 +78,178 @@ done:
return err;
 }
 
+/**
+ * Map netmap rings to pktin/pktout queues
+ *
+ * @param rings  Array of netmap descriptor rings
+ * @param num_queues Number of pktin/pktout queues
+ * @param num_rings  Number of matching netmap rings
+ */
+static inline void map_netmap_rings(netmap_ring_t *rings,
+   unsigned num_queues, unsigned num_rings)
+{
+   struct netmap_ring_t *desc_ring;
+   unsigned rings_per_queue;
+   unsigned remainder;
+   unsigned mapped_rings;
+   unsigned i;
+   unsigned desc_id = 0;
+
+   rings_per_queue = num_rings / num_queues;
+   remainder = num_rings % num_queues;
+
+   if (remainder)
+   ODP_DBG("WARNING: Netmap rings mapped unevenly to queues\n");
+
+   for (i = 0; i < num_queues; i++) {
+   desc_ring = [i].s;
+   if (i < remainder)
+   mapped_rings = rings_per_queue + 1;
+   else
+   mapped_rings = rings_per_queue;
+
+   desc_ring->first = desc_id;
+   desc_ring->cur = desc_id;
+   desc_ring->last = desc_ring->first + mapped_rings - 1;
+   desc_ring->num = mapped_rings;
+
+   desc_id = desc_ring->last + 1;
+   }
+}
+
+/**
+ * Close pktio queues
+ *
+ * @param pktio_entryPacket IO handle
+ */
+static inline void netmap_close_queues(pktio_entry_t *pktio_entry)
+{
+   int i;
+   struct pktio_entry *pktio = _entry->s;
+   odp_pktio_input_mode_t mode = pktio_entry->s.param.in_mode;
+
+   for (i = 0; i < PKTIO_MAX_QUEUES; i++) {
+   if (mode != ODP_PKTIN_MODE_POLL && mode != ODP_PKTIN_MODE_SCHED)
+   continue;
+
+   if 

[lng-odp] [API-NEXT PATCH 09/19] linux-generic: netmap: add netmap_link_status() function

[Petri Savolainen]

From: Matias Elo 

Added a separate function for determining if the netmap link
is up.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/netmap.c | 48 +--
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index e3aa7f1..544afaa 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -66,7 +66,7 @@ static int netmap_do_ioctl(pktio_entry_t *pktio_entry, 
unsigned long cmd,
break;
case SIOCETHTOOL:
if (subcmd == ETHTOOL_GLINK)
-   return !eval.data;
+   return eval.data;
break;
default:
break;
@@ -259,6 +259,38 @@ static int netmap_close(pktio_entry_t *pktio_entry)
return 0;
 }
 
+/**
+ * Determine netmap link status
+ *
+ * @param pktio_entryPacket IO handle
+ *
+ * @retval  1 link is up
+ * @retval  0 link is down
+ * @retval <0 on failure
+ */
+static inline int netmap_link_status(pktio_entry_t *pktio_entry)
+{
+   int i;
+   int ret;
+
+   /* Wait for the link to come up */
+   for (i = 0; i < NM_OPEN_RETRIES; i++) {
+   ret = netmap_do_ioctl(pktio_entry, SIOCETHTOOL, ETHTOOL_GLINK);
+   if (ret == -1)
+   return -1;
+   /* nm_open() causes the physical link to reset. When using a
+* direct attached loopback cable there may be a small delay
+* until the opposing end's interface comes back up again. In
+* this case without the additional sleep pktio validation
+* tests fail. */
+   sleep(1);
+   if (ret == 1)
+   return 1;
+   }
+   ODP_DBG("%s link is down\n", pktio_entry->s.name);
+   return 0;
+}
+
 static int netmap_open(odp_pktio_t id ODP_UNUSED, pktio_entry_t *pktio_entry,
   const char *netdev, odp_pool_t pool)
 {
@@ -359,7 +391,6 @@ static int netmap_start(pktio_entry_t *pktio_entry)
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
netmap_ring_t *desc_ring;
struct nm_desc base_desc;
-   int err;
unsigned i;
unsigned j;
uint64_t flags;
@@ -434,18 +465,7 @@ static int netmap_start(pktio_entry_t *pktio_entry)
}
}
/* Wait for the link to come up */
-   for (i = 0; i < NM_OPEN_RETRIES; i++) {
-   err = netmap_do_ioctl(pktio_entry, SIOCETHTOOL, ETHTOOL_GLINK);
-   /* nm_open() causes the physical link to reset. When using a
-* direct attached loopback cable there may be a small delay
-* until the opposing end's interface comes back up again. In
-* this case without the additional sleep pktio validation
-* tests fail. */
-   sleep(1);
-   if (err == 0)
-   return 0;
-   }
-   ODP_ERR("%s didn't come up\n", pktio_entry->s.name);
+   return (netmap_link_status(pktio_entry) == 1) ? 0 : -1;
 
 error:
netmap_close(pktio_entry);
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 11/19] linux-generic: netmap: add start()/stop() functionality

[Petri Savolainen]

From: Matias Elo 

Add support for starting/stopping netmap interfaces. Netmap
interfaces can only be configured while in stopped state.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  5 
 platform/linux-generic/pktio/netmap.c  | 30 ++
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index 88661aa..468a9ec 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -51,6 +51,11 @@ typedef struct {
uint32_t num_tx_rings;  /**< number of nm tx rings */
odp_bool_t lockless_rx; /**< no locking for rx */
odp_bool_t lockless_tx; /**< no locking for tx */
+   /** State of netmap descriptors */
+   enum {
+   NM_DESC_INVALID = 0,
+   NM_DESC_VALID
+   } desc_state;
/** mapping of pktin queues to netmap rx descriptors */
netmap_ring_t rx_desc_ring[PKTIO_MAX_QUEUES];
/** mapping of pktout queues to netmap tx descriptors */
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index cf4793b..afee15f 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -149,7 +149,7 @@ static int netmap_input_queues_config(pktio_entry_t 
*pktio_entry,
unsigned num_queues = p->num_queues;
unsigned i;
 
-   if (mode == ODP_PKTIN_MODE_DISABLED)
+   if (mode == ODP_PKTIN_MODE_DISABLED || pktio->state != STATE_STOP)
return -1;
 
if (num_queues <= 0 || num_queues > pkt_nm->capa.max_input_queues) {
@@ -196,6 +196,10 @@ static int netmap_input_queues_config(pktio_entry_t 
*pktio_entry,
 pkt_nm->num_rx_rings);
 
pkt_nm->lockless_rx = p->single_user;
+
+   if (pkt_nm->num_rx_queues != num_queues)
+   pkt_nm->desc_state = NM_DESC_INVALID;
+
pkt_nm->num_rx_queues = num_queues;
return 0;
 }
@@ -209,13 +213,17 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
unsigned num_queues = p->num_queues;
unsigned i;
 
-   if (mode == ODP_PKTOUT_MODE_DISABLED)
+   if (mode == ODP_PKTOUT_MODE_DISABLED || pktio->state != STATE_STOP)
return -1;
 
if (num_queues <= 0 || num_queues > pkt_nm->capa.max_output_queues) {
ODP_ERR("Invalid output queue count: %u\n", num_queues);
return -1;
}
+   pkt_nm->lockless_tx = p->single_user;
+
+   if (num_queues == pkt_nm->num_tx_queues) /* Already configured */
+   return 0;
 
/* Enough to map only one netmap tx ring per pktout queue */
map_netmap_rings(pkt_nm->tx_desc_ring, num_queues, num_queues);
@@ -224,7 +232,7 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
pktio->out_queue[i].pktout.index = i;
pktio->out_queue[i].pktout.pktio = pktio_entry->s.handle;
}
-   pkt_nm->lockless_tx = p->single_user;
+   pkt_nm->desc_state = NM_DESC_INVALID;
pkt_nm->num_tx_queues = num_queues;
return 0;
 }
@@ -255,6 +263,7 @@ static inline void netmap_close_descriptors(pktio_entry_t 
*pktio_entry)
}
}
}
+   pkt_nm->desc_state = NM_DESC_INVALID;
 }
 
 static int netmap_close(pktio_entry_t *pktio_entry)
@@ -430,6 +439,11 @@ static int netmap_start(pktio_entry_t *pktio_entry)
return -1;
}
 
+   if (pkt_nm->desc_state == NM_DESC_VALID)
+   return (netmap_link_status(pktio_entry) == 1) ? 0 : -1;
+
+   netmap_close_descriptors(pktio_entry);
+
base_desc.self = _desc;
base_desc.mem = NULL;
memcpy(base_desc.req.nr_name, pktio_entry->s.name,
@@ -478,14 +492,20 @@ static int netmap_start(pktio_entry_t *pktio_entry)
}
}
}
+   pkt_nm->desc_state = NM_DESC_VALID;
/* Wait for the link to come up */
return (netmap_link_status(pktio_entry) == 1) ? 0 : -1;
 
 error:
-   netmap_close(pktio_entry);
+   netmap_close_descriptors(pktio_entry);
return -1;
 }
 
+static int netmap_stop(pktio_entry_t *pktio_entry ODP_UNUSED)
+{
+   return 0;
+}
+
 /**
  * Create ODP packet from netmap packet
  *
@@ -801,7 +821,7 @@ const pktio_if_ops_t netmap_pktio_ops = {
.open = netmap_open,
.close = netmap_close,
.start = netmap_start,
-   .stop = NULL,
+   .stop = netmap_stop,
.recv = netmap_recv,
.send = netmap_send,
.mtu_get = netmap_mtu_get,
-- 
2.6.3

___
lng-odp mailing list
lng-odp@lists.linaro.org

[lng-odp] [API-NEXT PATCH 16/19] test: l2fwd: use multi-queue API for scheduled queues

[Petri Savolainen]

Updates scheduled queue mode to use the new multi-queue pktio
API.

Signed-off-by: Petri Savolainen 
---
 test/performance/odp_l2fwd.c | 52 ++--
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/test/performance/odp_l2fwd.c b/test/performance/odp_l2fwd.c
index 67a23ed..06eb29f 100644
--- a/test/performance/odp_l2fwd.c
+++ b/test/performance/odp_l2fwd.c
@@ -384,11 +384,7 @@ static void *pktio_direct_recv_thread(void *arg)
 static int create_pktio(const char *dev, int index, int num_rx, int num_tx,
odp_pool_t pool)
 {
-   char inq_name[ODP_QUEUE_NAME_LEN];
-   odp_queue_param_t qparam;
-   odp_queue_t inq_def;
odp_pktio_t pktio;
-   int ret;
odp_pktio_param_t pktio_param;
odp_schedule_sync_t  sync_mode;
odp_pktio_capability_t capa;
@@ -404,6 +400,7 @@ static int create_pktio(const char *dev, int index, int 
num_rx, int num_tx,
pktio_param.out_mode = ODP_PKTOUT_MODE_SEND;
} else {
pktio_param.in_mode = ODP_PKTIN_MODE_SCHED;
+   pktio_param.out_mode = ODP_PKTOUT_MODE_SEND;
}
 
pktio = odp_pktio_open(dev, pool, _param);
@@ -420,6 +417,9 @@ static int create_pktio(const char *dev, int index, int 
num_rx, int num_tx,
return -1;
}
 
+   odp_pktio_input_queue_param_init(_queue_param);
+   odp_pktio_output_queue_param_init(_queue_param);
+
if (gbl_args->appl.mode == DIRECT_RECV) {
if (num_rx > (int)capa.max_input_queues) {
printf("Sharing %i input queues between %i workers\n",
@@ -435,9 +435,6 @@ static int create_pktio(const char *dev, int index, int 
num_rx, int num_tx,
single_tx = 0;
}
 
-   odp_pktio_input_queue_param_init(_queue_param);
-   odp_pktio_output_queue_param_init(_queue_param);
-
in_queue_param.single_user = single_rx;
in_queue_param.hash_enable = 1;
in_queue_param.hash_proto.proto.ipv4_udp = 1;
@@ -487,27 +484,40 @@ static int create_pktio(const char *dev, int index, int 
num_rx, int num_tx,
else
sync_mode = ODP_SCHED_SYNC_NONE;
 
-   odp_queue_param_init();
-   qparam.sched.prio  = ODP_SCHED_PRIO_DEFAULT;
-   qparam.sched.sync  = sync_mode;
-   qparam.sched.group = ODP_SCHED_GROUP_ALL;
-   snprintf(inq_name, sizeof(inq_name), "%" PRIu64 "-pktio_inq_def",
-odp_pktio_to_u64(pktio));
-   inq_name[ODP_QUEUE_NAME_LEN - 1] = '\0';
+   /* Using scheduler for input. Single_user param not relevant. */
+   in_queue_param.hash_enable = 1;
+   in_queue_param.hash_proto.proto.ipv4_udp = 1;
+   in_queue_param.num_queues  = num_rx;
+   in_queue_param.queue_param.sched.prio  = ODP_SCHED_PRIO_DEFAULT;
+   in_queue_param.queue_param.sched.sync  = sync_mode;
+   in_queue_param.queue_param.sched.group = ODP_SCHED_GROUP_ALL;
 
-   inq_def = odp_queue_create(inq_name, ODP_QUEUE_TYPE_PKTIN, );
-   if (inq_def == ODP_QUEUE_INVALID) {
-   LOG_ERR("Error: pktio queue creation failed\n");
+   if (odp_pktio_input_queues_config(pktio, _queue_param)) {
+   LOG_ERR("Error: input queue config failed %s\n", dev);
return -1;
}
 
-   ret = odp_pktio_inq_setdef(pktio, inq_def);
-   if (ret != 0) {
-   LOG_ERR("Error: default input-Q setup\n");
+   out_queue_param.single_user = 0;
+   out_queue_param.num_queues  = num_tx;
+
+   if (odp_pktio_output_queues_config(pktio, _queue_param)) {
+   LOG_ERR("Error: output queue config failed %s\n", dev);
return -1;
}
 
-   gbl_args->pktios[index].pktio = pktio;
+   if (odp_pktio_pktout_queues(pktio,
+   gbl_args->pktios[index].pktout,
+   num_tx) != num_tx) {
+   LOG_ERR("Error: pktout queue query failed %s\n", dev);
+   return -1;
+   }
+
+   printf("created %i input and %i output queues on (%s)\n",
+  num_rx, num_tx, dev);
+
+   gbl_args->pktios[index].num_rx_queue = num_rx;
+   gbl_args->pktios[index].num_tx_queue = num_tx;
+   gbl_args->pktios[index].pktio= pktio;
 
return 0;
 }
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 14/19] linux-generic: pktio: added scheduler multi-queue support

[Petri Savolainen]

Added support for new multi-queue pktio API for scheduled
queues.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_packet_io_internal.h |   8 +-
 .../linux-generic/include/odp_schedule_internal.h  |   3 +-
 platform/linux-generic/odp_packet_io.c | 136 +
 platform/linux-generic/odp_schedule.c  |  26 ++--
 4 files changed, 110 insertions(+), 63 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index fdea65e..61bedc9 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -35,6 +35,8 @@ extern "C" {
 
 #define PKTIO_NAME_LEN 256
 
+#define PKTIN_INVALID  ((odp_pktin_queue_t) {ODP_PKTIO_INVALID, 0})
+#define PKTOUT_INVALID ((odp_pktout_queue_t) {ODP_PKTIO_INVALID, 0})
 
 /** Determine if a socket read/write error should be reported. Transient errors
  *  that simply require the caller to retry are ignored, the _send/_recv APIs
@@ -71,7 +73,6 @@ struct pktio_entry {
int taken;  /**< is entry taken(1) or free(0) */
int cls_enabled;/**< is classifier enabled */
odp_pktio_t handle; /**< pktio handle */
-   odp_queue_t inq_default;/**< default input queue, if set */
odp_queue_t outq_default;   /**< default out queue */
union {
pkt_loop_t pkt_loop;/**< Using loopback for IO */
@@ -96,6 +97,9 @@ struct pktio_entry {
 
/* Storage for queue handles
 * Multi-queue support is pktio driver specific */
+   unsigned num_in_queue;
+   unsigned num_out_queue;
+
struct {
odp_queue_tqueue;
odp_pktin_queue_t  pktin;
@@ -184,7 +188,7 @@ static inline void pktio_cls_enabled_set(pktio_entry_t 
*entry, int ena)
entry->s.cls_enabled = ena;
 }
 
-int pktin_poll(pktio_entry_t *entry);
+int pktin_poll(pktio_entry_t *entry, int num_queue, int index[]);
 
 /*
  * Dummy single queue implementations of multi-queue API
diff --git a/platform/linux-generic/include/odp_schedule_internal.h 
b/platform/linux-generic/include/odp_schedule_internal.h
index 6b301cd..78e16c4 100644
--- a/platform/linux-generic/include/odp_schedule_internal.h
+++ b/platform/linux-generic/include/odp_schedule_internal.h
@@ -23,7 +23,8 @@ extern "C" {
 int schedule_queue_init(queue_entry_t *qe);
 void schedule_queue_destroy(queue_entry_t *qe);
 int schedule_queue(const queue_entry_t *qe);
-int schedule_pktio_start(odp_pktio_t pktio, int prio);
+void schedule_pktio_start(odp_pktio_t pktio, int num_in_queue,
+ int in_queue_idx[], int prio);
 void odp_schedule_release_context(void);
 
 #ifdef __cplusplus
diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index c8c262b..d625db2 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -128,9 +128,16 @@ static void unlock_entry_classifier(pktio_entry_t *entry)
 
 static void init_pktio_entry(pktio_entry_t *entry)
 {
+   int i;
+
set_taken(entry);
pktio_cls_enabled_set(entry, 0);
-   entry->s.inq_default = ODP_QUEUE_INVALID;
+
+   for (i = 0; i < PKTIO_MAX_QUEUES; i++) {
+   entry->s.in_queue[i].queue   = ODP_QUEUE_INVALID;
+   entry->s.in_queue[i].pktin   = PKTIN_INVALID;
+   entry->s.out_queue[i].pktout = PKTOUT_INVALID;
+   }
 
pktio_classifier_init(entry);
 }
@@ -295,6 +302,7 @@ int odp_pktio_close(odp_pktio_t id)
 int odp_pktio_start(odp_pktio_t id)
 {
pktio_entry_t *entry;
+   odp_pktio_input_mode_t mode;
int res = 0;
 
entry = get_pktio_entry(id);
@@ -310,8 +318,27 @@ int odp_pktio_start(odp_pktio_t id)
res = entry->s.ops->start(entry);
if (!res)
entry->s.state = STATE_START;
+
unlock_entry(entry);
 
+   mode = entry->s.param.in_mode;
+
+   if (mode == ODP_PKTIN_MODE_SCHED) {
+   unsigned i;
+
+   for (i = 0; i < entry->s.num_in_queue; i++) {
+   int index = i;
+
+   if (entry->s.in_queue[i].queue == ODP_QUEUE_INVALID) {
+   ODP_ERR("No input queue\n");
+   return -1;
+   }
+
+   schedule_pktio_start(id, 1, ,
+ODP_SCHED_PRIO_LOWEST);
+   }
+   }
+
return res;
 }
 
@@ -445,30 +472,18 @@ int odp_pktio_inq_setdef(odp_pktio_t id, odp_queue_t 
queue)
unlock_entry(pktio_entry);
return -1;
}
-   pktio_entry->s.inq_default = queue;
+
+   /* Temporary support for default input queue */
+   pktio_entry->s.in_queue[0].queue = 

Re: [lng-odp] [PATCH v4] helper: linux: add thread type in pthread_create

[Maxim Uvarov]

Merged,
Maxim.

On 12/16/2015 12:44, Hemant Agrawal wrote:

The exisiting helper routine only create the worker threads.
However there is a need to use the same for creating the control
thread as well. e.g. CLI thread.

Signed-off-by: Hemant Agrawal 
---
  example/classifier/odp_classifier.c   | 2 +-
  example/generator/odp_generator.c | 9 ++---
  example/ipsec/odp_ipsec.c | 2 +-
  example/packet/odp_pktio.c| 3 ++-
  example/timer/odp_timer_test.c| 2 +-
  helper/include/odp/helper/linux.h | 5 -
  helper/linux.c| 6 --
  helper/test/odp_thread.c  | 3 ++-
  test/api_test/odp_common.c| 2 +-
  test/performance/odp_atomic.c | 2 +-
  test/performance/odp_l2fwd.c  | 3 ++-
  test/performance/odp_pktio_perf.c | 4 ++--
  test/performance/odp_scheduling.c | 2 +-
  test/validation/common/odp_cunit_common.c | 2 +-
  14 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 0da07e7..00da68a 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -593,7 +593,7 @@ int main(int argc, char *argv[])
odp_cpumask_set(_mask, cpu);
odph_linux_pthread_create(_tbl[i], _mask,
  pktio_receive_thread,
- args);
+ args, ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
}
  
diff --git a/example/generator/odp_generator.c b/example/generator/odp_generator.c

index 2de530d..93eefe9 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -784,7 +784,8 @@ int main(int argc, char *argv[])
abort();
args->thread[1].mode = args->appl.mode;
odph_linux_pthread_create(_tbl[1], _mask,
- gen_recv_thread, >thread[1]);
+ gen_recv_thread, >thread[1],
+ ODP_THREAD_WORKER);
  
  		tq = odp_queue_create("", ODP_QUEUE_TYPE_POLL, NULL);

if (tq == ODP_QUEUE_INVALID)
@@ -804,7 +805,8 @@ int main(int argc, char *argv[])
odp_cpumask_zero(_mask);
odp_cpumask_set(_mask, cpu_next);
odph_linux_pthread_create(_tbl[0], _mask,
- gen_send_thread, >thread[0]);
+ gen_send_thread, >thread[0],
+ ODP_THREAD_WORKER);
  
  	} else {

int cpu = odp_cpumask_first();
@@ -849,7 +851,8 @@ int main(int argc, char *argv[])
odph_linux_pthread_create(_tbl[i],
  _mask,
  thr_run_func,
- >thread[i]);
+ >thread[i],
+ ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
  
  		}

diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index d784c31..88e73ff 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -1333,7 +1333,7 @@ main(int argc, char *argv[])
 * Create and init worker threads
 */
odph_linux_pthread_create(thread_tbl, ,
- pktio_thread, NULL);
+ pktio_thread, NULL, ODP_THREAD_WORKER);
  
  	/*

 * If there are streams attempt to verify them else
diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
index 93c38f5..75e92ac 100644
--- a/example/packet/odp_pktio.c
+++ b/example/packet/odp_pktio.c
@@ -442,7 +442,8 @@ int main(int argc, char *argv[])
odp_cpumask_set(_mask, cpu);
odph_linux_pthread_create(_tbl[i], _mask,
  thr_run_func,
- >thread[i]);
+ >thread[i],
+ ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
}
  
diff --git a/example/timer/odp_timer_test.c b/example/timer/odp_timer_test.c

index 0ec73b1..bd05ce4 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -479,7 +479,7 @@ int main(int argc, char *argv[])
  
  	/* Create and launch worker threads */

odph_linux_pthread_create(thread_tbl, ,
- run_thread, gbls);
+ run_thread, gbls, ODP_THREAD_WORKER);
  
  	/* Wait for worker threads to exit */

odph_linux_pthread_join(thread_tbl, 

[lng-odp] [API-NEXT PATCH 01/19] linux-generic: pktio: enable using PKTIO_MAX_QUEUES in pktio implementations

[Petri Savolainen]

From: Matias Elo 

Change include order to enable using PKTIO_MAX_QUEUES in
pktio implementations.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_io_internal.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
b/platform/linux-generic/include/odp_packet_io_internal.h
index 96fb667..fdea65e 100644
--- a/platform/linux-generic/include/odp_packet_io_internal.h
+++ b/platform/linux-generic/include/odp_packet_io_internal.h
@@ -20,9 +20,6 @@ extern "C" {
 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,9 +28,13 @@ extern "C" {
 #include 
 #include 
 
-#define PKTIO_NAME_LEN 256
-
 #define PKTIO_MAX_QUEUES 64
+#include 
+#include 
+#include 
+
+#define PKTIO_NAME_LEN 256
+
 
 /** Determine if a socket read/write error should be reported. Transient errors
  *  that simply require the caller to retry are ignored, the _send/_recv APIs
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 00/19] Multi-queue pktio scheduler support

[Petri Savolainen]

This patch set includes netmap implementation of the new pktio multi-queue API 
and scheduler integration.

Netmap code is based on "netmap pktio multi queue support v2" patch series. 
Modifications include mainly bug fixes and performance optimizations, 
functionality is more or less the same (with previous patch set).

Scheduler modifications enable multi-queue API usage with odp_queue_t queues 
(scheduled and poll type). L2fwd test application has been ported to use 
multi-queue API also with scheduled queues.

Old pktio (single queue) interface is still functional. Next steps include 
removal of the old API.


Matias Elo (13):
  linux-generic: pktio: enable using PKTIO_MAX_QUEUES in pktio
implementations
  linux-generic: pktio: add RSS helper functions
  linux-generic: netmap: add odp_pktio_start()
  linux-generic: netmap: add odp_pktio_capability()
  linux-generic: netmap: add initial multi queue support
  linux-generic: netmap: add functions for fetching pktio queues
  linux-generic: netmap: odp_pktio_recv() from all pktin queues
  linux-generic: netmap: use select() instead of poll() in recv
  linux-generic: netmap: add netmap_link_status() function
  linux-generic: netmap: add netmap_close_descriptors() function
  linux-generic: netmap: add start()/stop() functionality
  linux-generic: netmap: fix netmap_mtu_get()
  linux-generic: netmap: disable debug prints

Petri Savolainen (6):
  linux-generic: pktio: added scheduler multi-queue support
  linux-generic: netmap: add scheduler multi-queue support
  test: l2fwd: use multi-queue API for scheduled queues
  test: l2fwd: use multiple queues in sched mode
  linux-generic: scheduler: improve pktio polling
  api: pktio: refine multiqueue API spec

 include/odp/api/packet_io.h|  14 +-
 .../linux-generic/include/odp_packet_io_internal.h |  19 +-
 platform/linux-generic/include/odp_packet_netmap.h |  43 +-
 platform/linux-generic/include/odp_packet_socket.h |  47 ++
 .../linux-generic/include/odp_schedule_internal.h  |   3 +-
 platform/linux-generic/odp_packet_io.c | 135 +++--
 platform/linux-generic/odp_schedule.c  | 226 ---
 platform/linux-generic/pktio/netmap.c  | 669 ++---
 platform/linux-generic/pktio/socket.c  | 234 +++
 test/performance/odp_l2fwd.c   | 103 ++--
 10 files changed, 1234 insertions(+), 259 deletions(-)

-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 03/19] linux-generic: netmap: add odp_pktio_start()

[Petri Savolainen]

From: Matias Elo 

Added initial version of odp_pktio_start() to netmap.
Removed unnecessary global mmap_desc variable.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  2 +
 platform/linux-generic/pktio/netmap.c  | 59 --
 2 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index 0577dfe..84bea65 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -10,6 +10,7 @@
 #include 
 
 #include 
+#include 
 
 /** Packet socket using netmap mmaped rings for both Rx and Tx */
 typedef struct {
@@ -20,6 +21,7 @@ typedef struct {
uint32_t if_flags;  /**< interface flags */
int sockfd; /**< control socket */
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
+   char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
 } pkt_netmap_t;
 
 #endif
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 91cf99f..e7f4af5 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -27,10 +27,6 @@
 #define NETMAP_WITH_LIBS
 #include 
 
-static struct nm_desc mmap_desc;   /** Used to store the mmap address;
- filled in first time, used for
- subsequent calls to nm_open */
-
 #define NM_OPEN_RETRIES 5
 #define NM_INJECT_RETRIES 10
 
@@ -86,10 +82,8 @@ static int netmap_close(pktio_entry_t *pktio_entry)
 {
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
 
-   if (pkt_nm->rx_desc != NULL) {
+   if (pkt_nm->rx_desc != NULL)
nm_close(pkt_nm->rx_desc);
-   mmap_desc.mem = NULL;
-   }
if (pkt_nm->tx_desc != NULL)
nm_close(pkt_nm->tx_desc);
 
@@ -104,11 +98,10 @@ static int netmap_close(pktio_entry_t *pktio_entry)
 static int netmap_open(odp_pktio_t id ODP_UNUSED, pktio_entry_t *pktio_entry,
   const char *netdev, odp_pool_t pool)
 {
-   char ifname[IFNAMSIZ + 7]; /* netmap: */
int err;
int sockfd;
-   int i;
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
+   struct nm_desc *desc;
 
if (getenv("ODP_PKTIO_DISABLE_NETMAP"))
return -1;
@@ -128,25 +121,16 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
 
snprintf(pktio_entry->s.name, sizeof(pktio_entry->s.name), "%s",
 netdev);
-   snprintf(ifname, sizeof(ifname), "netmap:%s", netdev);
+   snprintf(pkt_nm->nm_name, sizeof(pkt_nm->nm_name), "netmap:%s",
+netdev);
 
-   if (mmap_desc.mem == NULL)
-   pkt_nm->rx_desc = nm_open(ifname, NULL, NETMAP_NO_TX_POLL,
- NULL);
-   else
-   pkt_nm->rx_desc = nm_open(ifname, NULL, NETMAP_NO_TX_POLL |
- NM_OPEN_NO_MMAP, _desc);
-   pkt_nm->tx_desc = nm_open(ifname, NULL, NM_OPEN_NO_MMAP, _desc);
-
-   if (pkt_nm->rx_desc == NULL || pkt_nm->tx_desc == NULL) {
-   ODP_ERR("nm_open(%s) failed\n", ifname);
+   /* Dummy open here to check if netmap module is available */
+   desc = nm_open(pkt_nm->nm_name, NULL, 0, NULL);
+   if (desc == NULL) {
+   ODP_ERR("nm_open(%s) failed\n", pkt_nm->nm_name);
goto error;
}
-
-   if (mmap_desc.mem == NULL) {
-   mmap_desc.mem = pkt_nm->rx_desc->mem;
-   mmap_desc.memsize = pkt_nm->rx_desc->memsize;
-   }
+   nm_close(desc);
 
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
if (sockfd == -1) {
@@ -165,6 +149,29 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
if (err)
goto error;
 
+   return 0;
+
+error:
+   netmap_close(pktio_entry);
+   return -1;
+}
+
+static int netmap_start(pktio_entry_t *pktio_entry)
+{
+   pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
+   int err;
+   unsigned i;
+   const char *ifname = pkt_nm->nm_name;
+
+   pkt_nm->rx_desc = nm_open(ifname, NULL, NETMAP_NO_TX_POLL, NULL);
+   pkt_nm->tx_desc = nm_open(ifname, NULL, NM_OPEN_NO_MMAP,
+ pkt_nm->rx_desc);
+
+   if (pkt_nm->rx_desc == NULL || pkt_nm->tx_desc == NULL) {
+   ODP_ERR("nm_open(%s) failed\n", ifname);
+   goto error;
+   }
+
/* Wait for the link to come up */
for (i = 0; i < NM_OPEN_RETRIES; i++) {
err = netmap_do_ioctl(pktio_entry, SIOCETHTOOL, ETHTOOL_GLINK);
@@ -354,7 +361,7 @@ const pktio_if_ops_t netmap_pktio_ops = {
.term = NULL,
.open = netmap_open,
.close = netmap_close,
-

[lng-odp] [API-NEXT PATCH 08/19] linux-generic: netmap: use select() instead of poll() in recv

[Petri Savolainen]

From: Matias Elo 

Use select() instead of poll() in recv to reduce the number
of system calls.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/netmap.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 29474c1..e3aa7f1 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -519,7 +519,6 @@ static int netmap_recv_queue(pktio_entry_t *pktio_entry, 
int index,
char *buf;
struct netmap_ring *ring;
struct nm_desc *desc;
-   struct pollfd polld;
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
unsigned first_desc_id = pkt_nm->rx_desc_ring[index].s.first;
unsigned last_desc_id = pkt_nm->rx_desc_ring[index].s.last;
@@ -527,11 +526,15 @@ static int netmap_recv_queue(pktio_entry_t *pktio_entry, 
int index,
int num_desc = pkt_nm->rx_desc_ring[index].s.num;
int i;
int num_rx = 0;
+   int max_fd = 0;
uint32_t slot_id;
+   fd_set empty_rings;
 
if (odp_unlikely(pktio_entry->s.state == STATE_STOP))
return 0;
 
+   FD_ZERO(_rings);
+
if (!pkt_nm->lockless_rx)
odp_ticketlock_lock(_nm->rx_desc_ring[index].s.lock);
 
@@ -544,7 +547,13 @@ static int netmap_recv_queue(pktio_entry_t *pktio_entry, 
int index,
desc = pkt_nm->rx_desc_ring[index].s.desc[desc_id];
ring = NETMAP_RXRING(desc->nifp, desc->cur_rx_ring);
 
-   while (!nm_ring_empty(ring) && num_rx != num) {
+   while (num_rx != num) {
+   if (nm_ring_empty(ring)) {
+   FD_SET(desc->fd, _rings);
+   if (desc->fd > max_fd)
+   max_fd = desc->fd;
+   break;
+   }
slot_id = ring->cur;
buf = NETMAP_BUF(ring, ring->slot[slot_id].buf_idx);
 
@@ -557,17 +566,16 @@ static int netmap_recv_queue(pktio_entry_t *pktio_entry, 
int index,
ring->cur = nm_ring_next(ring, slot_id);
ring->head = ring->cur;
}
-
-   if (num_rx != num) {
-   polld.fd = desc->fd;
-   polld.events = POLLIN;
-   if (odp_unlikely(poll(, 1, 0) < 0))
-   ODP_ERR("RX: poll error\n");
-   }
desc_id++;
}
pkt_nm->rx_desc_ring[index].s.cur = desc_id;
 
+   if (num_rx != num) {
+   struct timeval tout = {.tv_sec = 0, .tv_usec = 0};
+
+   if (select(max_fd + 1, _rings, NULL, NULL, ) == -1)
+   ODP_ERR("RX: select error\n");
+   }
if (!pkt_nm->lockless_rx)
odp_ticketlock_unlock(_nm->rx_desc_ring[index].s.lock);
 
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 12/19] linux-generic: netmap: fix netmap_mtu_get()

[Petri Savolainen]

From: Matias Elo 

Use correct MTU value for netmap. Either configured
interface MTU or netmap buffer size. Whichever is smaller.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/include/odp_packet_netmap.h |  1 +
 platform/linux-generic/pktio/netmap.c  | 18 --
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index 468a9ec..f26b0cb 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -40,6 +40,7 @@ typedef struct {
odp_pool_t pool;/**< pool to alloc packets from */
size_t max_frame_len;   /**< buf_size - sizeof(pkt_hdr) */
uint32_t if_flags;  /**< interface flags */
+   uint32_t mtu;   /**< maximum transmission unit */
int sockfd; /**< control socket */
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index afee15f..826050f 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -320,8 +320,11 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
int i;
int err;
int sockfd;
+   int mtu;
+   uint32_t buf_size;
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
struct nm_desc *desc;
+   struct netmap_ring *ring;
odp_pktin_hash_proto_t hash_proto;
 
if (getenv("ODP_PKTIO_DISABLE_NETMAP"))
@@ -372,6 +375,8 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
if (desc->nifp->ni_tx_rings < PKTIO_MAX_QUEUES)
pkt_nm->capa.max_output_queues = desc->nifp->ni_tx_rings;
 
+   ring = NETMAP_RXRING(desc->nifp, desc->cur_rx_ring);
+   buf_size = ring->nr_buf_size;
nm_close(desc);
 
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
@@ -381,6 +386,15 @@ static int netmap_open(odp_pktio_t id ODP_UNUSED, 
pktio_entry_t *pktio_entry,
}
pkt_nm->sockfd = sockfd;
 
+   /* Use either interface MTU or netmap buffer size as MTU, whichever is
+* smaller. */
+   mtu = mtu_get_fd(pktio_entry->s.pkt_nm.sockfd, pktio_entry->s.name);
+   if (mtu < 0) {
+   ODP_ERR("Unable to read interface MTU\n");
+   goto error;
+   }
+   pkt_nm->mtu = ((uint32_t)mtu < buf_size) ? (uint32_t)mtu : buf_size;
+
/* Check if RSS is supported. If not, set 'max_input_queues' to 1. */
if (rss_conf_get_supported_fd(sockfd, netdev, _proto) == 0) {
ODP_DBG("RSS not supported\n");
@@ -695,7 +709,7 @@ static int netmap_send_queue(pktio_entry_t *pktio_entry, 
int index,
pkt = pkt_table[nb_tx];
pkt_len = odp_packet_len(pkt);
 
-   if (pkt_len > ring->nr_buf_size) {
+   if (pkt_len > pkt_nm->mtu) {
if (nb_tx == 0)
__odp_errno = EMSGSIZE;
break;
@@ -749,7 +763,7 @@ static int netmap_mac_addr_get(pktio_entry_t *pktio_entry, 
void *mac_addr)
 
 static int netmap_mtu_get(pktio_entry_t *pktio_entry)
 {
-   return mtu_get_fd(pktio_entry->s.pkt_nm.sockfd, pktio_entry->s.name);
+   return pktio_entry->s.pkt_nm.mtu;
 }
 
 static int netmap_promisc_mode_set(pktio_entry_t *pktio_entry,
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 10/19] linux-generic: netmap: add netmap_close_descriptors() function

[Petri Savolainen]

From: Matias Elo 

Added a separate function for closing netmap descriptors,
which can be reopened using netmap_start() call.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/netmap.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 544afaa..cf4793b 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -229,7 +229,14 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
return 0;
 }
 
-static int netmap_close(pktio_entry_t *pktio_entry)
+/**
+ * Close netmap descriptors
+ *
+ * Can be reopened using netmap_start() function.
+ *
+ * @param pktio_entryPacket IO handle
+ */
+static inline void netmap_close_descriptors(pktio_entry_t *pktio_entry)
 {
int i, j;
pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
@@ -248,6 +255,13 @@ static int netmap_close(pktio_entry_t *pktio_entry)
}
}
}
+}
+
+static int netmap_close(pktio_entry_t *pktio_entry)
+{
+   pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
+
+   netmap_close_descriptors(pktio_entry);
 
netmap_close_queues(pktio_entry);
 
-- 
2.6.3

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

[lng-odp] [API-NEXT PATCH 15/19] linux-generic: netmap: add scheduler multi-queue support

[Petri Savolainen]

Modified netmap pktio to support the new multi-queue pktio
API with scheduled queues.

Signed-off-by: Petri Savolainen 
---
 platform/linux-generic/include/odp_packet_netmap.h |  2 -
 platform/linux-generic/pktio/netmap.c  | 52 +-
 2 files changed, 31 insertions(+), 23 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index f26b0cb..dae770d 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -45,8 +45,6 @@ typedef struct {
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
odp_pktio_capability_t  capa;   /**< interface capabilities */
-   unsigned num_rx_queues; /**< number of pktin queues */
-   unsigned num_tx_queues; /**< number of pktout queues */
unsigned cur_rx_queue;  /**< current pktin queue */
uint32_t num_rx_rings;  /**< number of nm rx rings */
uint32_t num_tx_rings;  /**< number of nm tx rings */
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 042e4e7..d2a4626 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -155,10 +155,18 @@ static int netmap_input_queues_config(pktio_entry_t 
*pktio_entry,
odp_queue_t queue;
unsigned num_queues = p->num_queues;
unsigned i;
+   odp_bool_t single_user;
 
if (mode == ODP_PKTIN_MODE_DISABLED || pktio->state != STATE_STOP)
return -1;
 
+   /* Scheduler synchronizes input queue polls. Only single thread
+* at a time polls a queue */
+   if (mode == ODP_PKTIN_MODE_SCHED)
+   single_user = 1;
+   else
+   single_user = p->single_user;
+
if (num_queues <= 0 || num_queues > pkt_nm->capa.max_input_queues) {
ODP_ERR("Invalid input queue count: %u\n", num_queues);
return -1;
@@ -194,20 +202,21 @@ static int netmap_input_queues_config(pktio_entry_t 
*pktio_entry,
pktio->in_queue[i].queue = queue;
} else {
pktio->in_queue[i].queue = ODP_QUEUE_INVALID;
-   pktio->in_queue[i].pktin.index = i;
-   pktio->in_queue[i].pktin.pktio = pktio_entry->s.handle;
}
+
+   pktio->in_queue[i].pktin.index = i;
+   pktio->in_queue[i].pktin.pktio = pktio_entry->s.handle;
}
/* Map pktin queues to netmap rings */
map_netmap_rings(pkt_nm->rx_desc_ring, num_queues,
 pkt_nm->num_rx_rings);
 
-   pkt_nm->lockless_rx = p->single_user;
+   pkt_nm->lockless_rx = single_user;
 
-   if (pkt_nm->num_rx_queues != num_queues)
+   if (pktio_entry->s.num_in_queue != num_queues)
pkt_nm->desc_state = NM_DESC_INVALID;
 
-   pkt_nm->num_rx_queues = num_queues;
+   pktio_entry->s.num_in_queue = num_queues;
return 0;
 }
 
@@ -229,7 +238,7 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
}
pkt_nm->lockless_tx = p->single_user;
 
-   if (num_queues == pkt_nm->num_tx_queues) /* Already configured */
+   if (num_queues == pktio_entry->s.num_out_queue) /* Already configured */
return 0;
 
/* Enough to map only one netmap tx ring per pktout queue */
@@ -240,7 +249,7 @@ static int netmap_output_queues_config(pktio_entry_t 
*pktio_entry,
pktio->out_queue[i].pktout.pktio = pktio_entry->s.handle;
}
pkt_nm->desc_state = NM_DESC_INVALID;
-   pkt_nm->num_tx_queues = num_queues;
+   pktio_entry->s.num_out_queue = num_queues;
return 0;
 }
 
@@ -443,7 +452,8 @@ static int netmap_start(pktio_entry_t *pktio_entry)
 
/* If no pktin/pktout queues have been configured. Configure one
 * for each direction. */
-   if (!pkt_nm->num_rx_queues && in_mode != ODP_PKTIN_MODE_DISABLED) {
+   if (!pktio_entry->s.num_in_queue &&
+   in_mode != ODP_PKTIN_MODE_DISABLED) {
odp_pktio_input_queue_param_t param;
 
memset(, 0, sizeof(odp_pktio_input_queue_param_t));
@@ -451,7 +461,7 @@ static int netmap_start(pktio_entry_t *pktio_entry)
if (netmap_input_queues_config(pktio_entry, ))
return -1;
}
-   if (!pkt_nm->num_tx_queues && out_mode == ODP_PKTOUT_MODE_SEND) {
+   if (!pktio_entry->s.num_out_queue && out_mode == ODP_PKTOUT_MODE_SEND) {
odp_pktio_output_queue_param_t param;
 
memset(, 0, sizeof(odp_pktio_output_queue_param_t));
@@ -484,7 +494,7 @@ static int netmap_start(pktio_entry_t *pktio_entry)
}
/* Open rest of the rx descriptors (one per 

[lng-odp] [API-NEXT PATCH 19/19] api: pktio: refine multiqueue API spec

[Petri Savolainen]

Specify explicitly that new config calls invalidate old
handles and outputted queue handles are stored in 0 ... N-1.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/packet_io.h | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 443841e..2825dce 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -254,6 +254,8 @@ int odp_pktio_capability(odp_pktio_t pktio, 
odp_pktio_capability_t *capa);
  * odp_pktio_capability(). Queue handles for input queues can be requested with
  * odp_pktio_in_queues() or odp_pktio_pktin_queues() after this call. All
  * requested queues are setup on success, no queues are setup on failure.
+ * Each call reconfigures input queues and may invalidate all previous queue
+ * handles.
  *
  * @param pktioPacket IO handle
  * @param paramPacket input queue configuration parameters
@@ -272,7 +274,8 @@ int odp_pktio_input_queues_config(odp_pktio_t pktio,
  * Setup a number of packet output queues and configure those. The maximum
  * number of queues is platform dependent and can be queried with
  * odp_pktio_capability(). All requested queues are setup on success, no
- * queues are setup on failure.
+ * queues are setup on failure.  Each call reconfigures output queues and may
+ * invalidate all previous queue handles.
  *
  * @param pktioPacket IO handle
  * @param paramPacket output queue configuration parameters
@@ -292,7 +295,8 @@ int odp_pktio_output_queues_config(odp_pktio_t pktio,
  * ODP_PKTIN_MODE_POLL and ODP_PKTIN_MODE_SCHED modes. Outputs up to 'num' 
queue
  * handles when the 'queues' array pointer is not NULL. If return value is
  * larger than 'num', there are more queues than the function was allowed to
- * output.
+ * output. If return value (N) is less than 'num', only queues[0 ... N-1] have
+ * been written.
  *
  * Packets (and other events) from these queues are received with
  * odp_queue_deq(), odp_schedule(), etc calls.
@@ -312,7 +316,8 @@ int odp_pktio_in_queues(odp_pktio_t pktio, odp_queue_t 
queues[], int num);
  * Returns the number of input queues configured for the interface in
  * ODP_PKTIN_MODE_RECV mode. Outputs up to 'num' queue handles when the
  * 'queues' array pointer is not NULL. If return value is larger than 'num',
- * there are more queues than the function was allowed to output.
+ * there are more queues than the function was allowed to output. If return
+ * value (N) is less than 'num', only queues[0 ... N-1] have been written.
  *
  * Packets from these queues are received with odp_pktio_recv_queue().
  *
@@ -332,7 +337,8 @@ int odp_pktio_pktin_queues(odp_pktio_t pktio, 
odp_pktin_queue_t queues[],
  * Returns the number of output queues configured for the interface in
  * ODP_PKTOUT_MODE_SEND mode. Outputs up to 'num' queue handles when the
  * 'queues' array pointer is not NULL. If return value is larger than 'num',
- * there are more queues than the function was allowed to output.
+ * there are more queues than the function was allowed to output. If return
+ * value (N) is less than 'num', only queues[0 ... N-1] have been written.
  *
  * Packets are sent to these queues with odp_pktio_send_queue().
  *
-- 
2.6.3

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

Re: [lng-odp] [PATCH] example: timer: free resources while termination

[Ivan Khoronzhuk]

On 16.12.15 16:26, Bill Fischofer wrote:

This patch doesn't appear to apply to the current master.  Needs a rebase?

Probably yes, I'll rebase.



bill@Ubuntu15:~/linaro/ivanpatch$ git am --reject ~/Mail/Incoming/Ivan/1
Applying: example: timer: free resources while termination
Checking patch example/timer/odp_timer_test.c...
Hunk #1 succeeded at 334 (offset 3 lines).
Hunk #2 succeeded at 366 (offset 3 lines).
error: while searching for:
gbls->pool = odp_pool_create("msg_pool", );

if (gbls->pool == ODP_POOL_INVALID) {
EXAMPLE_ERR("Pool create failed.\n");
return -1;
}

tparams.res_ns = gbls->args.resolution_us*ODP_TIME_USEC;

error: patch failed: example/timer/odp_timer_test.c:404
Hunk #4 succeeded at 424 (offset 2 lines).
Hunk #5 succeeded at 451 (offset 2 lines).
Hunk #6 succeeded at 491 (offset 2 lines).
Applying patch example/timer/odp_timer_test.c with 1 reject...
Hunk #1 applied cleanly.
Hunk #2 applied cleanly.
Rejected hunk #3.
Hunk #4 applied cleanly.
Hunk #5 applied cleanly.
Hunk #6 applied cleanly.
Patch failed at 0001 example: timer: free resources while termination


On Mon, Dec 14, 2015 at 9:29 AM, Ivan Khoronzhuk > wrote:

ping

On 19.11.15 12:54, Ivan Khoronzhuk wrote:

Example should free resources in right order when terminates.
Also it should have correct error path.

Signed-off-by: Ivan Khoronzhuk >
---
   example/timer/odp_timer_test.c | 46 
++
   1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/example/timer/odp_timer_test.c 
b/example/timer/odp_timer_test.c
index 94619e4..2d74e4c 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -331,18 +331,21 @@ int main(int argc, char *argv[])
 char cpumaskstr[ODP_CPUMASK_STR_SIZE];
 odp_shm_t shm;
 test_globals_t  *gbls;
+   int err = 0;

 printf("\nODP timer example starts\n");

 if (odp_init_global(NULL, NULL)) {
+   err = 1;
 printf("ODP global init failed.\n");
-   return -1;
+   goto err;
 }

 /* Init this thread. */
 if (odp_init_local(ODP_THREAD_CONTROL)) {
+   err = 1;
 printf("ODP local init failed.\n");
-   return -1;
+   goto err_global;
 }

 printf("\n");
@@ -360,14 +363,16 @@ int main(int argc, char *argv[])
 shm = odp_shm_reserve("shm_test_globals", 
sizeof(test_globals_t),
   ODP_CACHE_LINE_SIZE, 0);
 if (ODP_SHM_INVALID == shm) {
+   err = 1;
 EXAMPLE_ERR("Error: shared mem reserve failed.\n");
-   return -1;
+   goto err_local;
 }

 gbls = odp_shm_addr(shm);
 if (NULL == gbls) {
+   err = 1;
 EXAMPLE_ERR("Error: shared mem alloc failed.\n");
-   return -1;
+   goto err_shm;
 }
 memset(gbls, 0, sizeof(test_globals_t));

@@ -404,8 +409,9 @@ int main(int argc, char *argv[])
 gbls->pool = odp_pool_create("msg_pool", );

 if (gbls->pool == ODP_POOL_INVALID) {
+   err = 1;
 EXAMPLE_ERR("Pool create failed.\n");
-   return -1;
+   goto err_shm;
 }

 tparams.res_ns = gbls->args.resolution_us*ODP_TIME_USEC;
@@ -416,8 +422,9 @@ int main(int argc, char *argv[])
 tparams.clk_src = ODP_CLOCK_CPU;
 gbls->tp = odp_timer_pool_create("timer_pool", );
 if (gbls->tp == ODP_TIMER_POOL_INVALID) {
+   err = 1;
 EXAMPLE_ERR("Timer pool create failed.\n");
-   return -1;
+   goto err_msg_pool;
 }
 odp_timer_pool_start();

@@ -442,8 +449,9 @@ int main(int argc, char *argv[])
 queue = odp_queue_create("timer_queue", ODP_QUEUE_TYPE_SCHED, 
);

 if (queue == ODP_QUEUE_INVALID) {
+   err = 1;
 EXAMPLE_ERR("Timer queue create failed.\n");
-   return -1;
+   goto err_timer_pool;
 }

 printf("CPU freq %"PRIu64" Hz\n", odp_sys_cpu_hz());
@@ -481,7 +489,29 @@ int main(int argc, char *argv[])
 /* Wait 

Re: [lng-odp] [API-NEXT PATCH 19/19] api: pktio: refine multiqueue API spec

[Zoltan Kiss]

Reviewed-by: Zoltan Kiss 

On 16/12/15 13:45, Petri Savolainen wrote:

Specify explicitly that new config calls invalidate old
handles and outputted queue handles are stored in 0 ... N-1.

Signed-off-by: Petri Savolainen 
---
  include/odp/api/packet_io.h | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 443841e..2825dce 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -254,6 +254,8 @@ int odp_pktio_capability(odp_pktio_t pktio, 
odp_pktio_capability_t *capa);
   * odp_pktio_capability(). Queue handles for input queues can be requested 
with
   * odp_pktio_in_queues() or odp_pktio_pktin_queues() after this call. All
   * requested queues are setup on success, no queues are setup on failure.
+ * Each call reconfigures input queues and may invalidate all previous queue
+ * handles.
   *
   * @param pktioPacket IO handle
   * @param paramPacket input queue configuration parameters
@@ -272,7 +274,8 @@ int odp_pktio_input_queues_config(odp_pktio_t pktio,
   * Setup a number of packet output queues and configure those. The maximum
   * number of queues is platform dependent and can be queried with
   * odp_pktio_capability(). All requested queues are setup on success, no
- * queues are setup on failure.
+ * queues are setup on failure.  Each call reconfigures output queues and may
+ * invalidate all previous queue handles.
   *
   * @param pktioPacket IO handle
   * @param paramPacket output queue configuration parameters
@@ -292,7 +295,8 @@ int odp_pktio_output_queues_config(odp_pktio_t pktio,
   * ODP_PKTIN_MODE_POLL and ODP_PKTIN_MODE_SCHED modes. Outputs up to 'num' 
queue
   * handles when the 'queues' array pointer is not NULL. If return value is
   * larger than 'num', there are more queues than the function was allowed to
- * output.
+ * output. If return value (N) is less than 'num', only queues[0 ... N-1] have
+ * been written.
   *
   * Packets (and other events) from these queues are received with
   * odp_queue_deq(), odp_schedule(), etc calls.
@@ -312,7 +316,8 @@ int odp_pktio_in_queues(odp_pktio_t pktio, odp_queue_t 
queues[], int num);
   * Returns the number of input queues configured for the interface in
   * ODP_PKTIN_MODE_RECV mode. Outputs up to 'num' queue handles when the
   * 'queues' array pointer is not NULL. If return value is larger than 'num',
- * there are more queues than the function was allowed to output.
+ * there are more queues than the function was allowed to output. If return
+ * value (N) is less than 'num', only queues[0 ... N-1] have been written.
   *
   * Packets from these queues are received with odp_pktio_recv_queue().
   *
@@ -332,7 +337,8 @@ int odp_pktio_pktin_queues(odp_pktio_t pktio, 
odp_pktin_queue_t queues[],
   * Returns the number of output queues configured for the interface in
   * ODP_PKTOUT_MODE_SEND mode. Outputs up to 'num' queue handles when the
   * 'queues' array pointer is not NULL. If return value is larger than 'num',
- * there are more queues than the function was allowed to output.
+ * there are more queues than the function was allowed to output. If return
+ * value (N) is less than 'num', only queues[0 ... N-1] have been written.
   *
   * Packets are sent to these queues with odp_pktio_send_queue().
   *


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

[lng-odp] [HELP] Question about API Classification and Traffic Manager

[Kury Nicolas]

Hi!

I have some questions about Traffic Manager and Classifier.

Traffic Manager:
I see there is the possibility to send back the packets. Do you have any 
example where this would be used ? I don't really see how we can combine the 
different algorithms, example Strict Priority scheduling with Bandwidth 
Shaping, etc.
http://img11.hostingpics.net/pics/882875tarfficmanager.png

Classifiers
It is possible to have such a loopback ? 
http://img11.hostingpics.net/pics/729760loop.png
For example, a packet is classified in flow #1 with processing #1, and then is 
classified in flow #2 with processing #2, etc. ?

Thank you very much!
Nicolas
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [API-NEXT PATCH 1/2] api: barrier: added memory barriers

[Savolainen, Petri (Nokia - FI/Espoo)]

Ping. Waiting to be merged.

From: EXT Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Sunday, December 13, 2015 12:44 AM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [API-NEXT PATCH 1/2] api: barrier: added memory barriers



On Fri, Dec 11, 2015 at 5:30 AM, Petri Savolainen 
> wrote:
Added new memory barriers. These follow C11 release /
acquire specification and replaces odp_sync_stores().
Used GCC __atomic_thread_fence to implement all three
barriers.

Signed-off-by: Petri Savolainen 
>

Reviewed-by: Bill Fischofer 
>

---
 include/odp/api/barrier.h | 11 -
 include/odp/api/sync.h| 82 ---
 platform/linux-generic/include/odp/sync.h | 28 +++
 3 files changed, 90 insertions(+), 31 deletions(-)

diff --git a/include/odp/api/barrier.h b/include/odp/api/barrier.h
index 8ca2647..823eae6 100644
--- a/include/odp/api/barrier.h
+++ b/include/odp/api/barrier.h
@@ -18,8 +18,15 @@
 extern "C" {
 #endif

-/** @defgroup odp_barrier ODP BARRIER
- *  Thread excution and memory ordering barriers.
+/**
+ * @defgroup odp_barrier ODP BARRIER
+ * Thread excution and memory ordering barriers.
+ *
+ * @details
+ *  Thread execution barrier (odp_barrier_t) 
+ *
+ * Thread execution barrier synchronizes a group of threads to wait on the
+ * barrier until the entire group has reached the barrier.
  *  @{
  */

diff --git a/include/odp/api/sync.h b/include/odp/api/sync.h
index 6477e74..c6f790c 100644
--- a/include/odp/api/sync.h
+++ b/include/odp/api/sync.h
@@ -8,7 +8,7 @@
 /**
  * @file
  *
- * ODP synchronisation
+ * ODP memory barriers
  */

 #ifndef ODP_API_SYNC_H_
@@ -18,42 +18,66 @@
 extern "C" {
 #endif

-/** @addtogroup odp_barrier
+/**
+ * @addtogroup odp_barrier
+ * @details
+ *  Memory barriers 
+ *
+ * Memory barriers enforce ordering of memory load and store operations
+ * specified before and after the barrier. These barriers may affect both
+ * compiler optimizations and CPU out-of-order execution. All ODP
+ * synchronization mechanisms (e.g. execution barriers, locks, queues, etc )
+ * include all necessary memory barriers, so these calls are not needed when
+ * using those. Also ODP atomic operations have memory ordered versions. These
+ * explicit barriers may be needed when thread synchronization is based on
+ * a non-ODP defined mechanism. Depending on the HW platform, heavy usage of
+ * memory barriers may cause significant performance degradation.
+ *
  *  @{
  */

 /**
- * Synchronise stores
+ * Memory barrier for release operations
  *
- * Ensures that all CPU store operations that precede the odp_sync_stores()
- * call are globally visible before any store operation that follows it.
+ * This memory barrier has release semantics. It synchronizes with a pairing
+ * barrier for acquire operations. The releasing and acquiring threads
+ * synchronize through shared memory. The releasing thread must call this
+ * barrier before signaling the acquiring thread. After the acquiring thread
+ * receives the signal, it must call odp_mb_acquire() before it reads the
+ * memory written by the releasing thread.
+ *
+ * This call is not needed when using ODP defined synchronization mechanisms.
+ *
+ * @see odp_mb_acquire()
  */
-static inline void odp_sync_stores(void)
-{
-#if defined __x86_64__ || defined __i386__
-
-   __asm__  __volatile__ ("sfence\n" : : : "memory");
-
-#elif defined(__arm__)
-#if __ARM_ARCH == 6
-   __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
-   : : "r" (0) : "memory");
-#elif __ARM_ARCH >= 7 || defined __aarch64__
-
-   __asm__ __volatile__ ("dmb st" : : : "memory");
-#else
-   __asm__ __volatile__ ("" : : : "memory");
-#endif
-
-#elif defined __OCTEON__
-
-   __asm__  __volatile__ ("syncws\n" : : : "memory");
+void odp_mb_release(void);

-#else
-   __sync_synchronize();
-#endif
-}
+/**
+ * Memory barrier for acquire operations
+ *
+ * This memory barrier has acquire semantics. It synchronizes with a pairing
+ * barrier for release operations. The releasing and acquiring threads
+ * synchronize through shared memory. The releasing thread must call
+ * odp_mb_release() before signaling the acquiring thread. After the acquiring
+ * thread receives the signal, it must call this barrier before it reads the
+ * memory written by the releasing thread.
+ *
+ * This call is not needed when using ODP defined synchronization mechanisms.
+ *
+ * @see odp_mb_release()
+ */
+void odp_mb_acquire(void);

+/**
+ * Full memory barrier
+ *
+ * This is a full memory barrier. It guarantees that all load and store
+ * operations specified before it are visible to other threads before
+ * all load and store operations specified after it.
+ *
+ * This call is not 

[lng-odp] [API-NEXT PATCH 18/19] linux-generic: scheduler: improve pktio polling

[Petri Savolainen]

Separate packet input polling from event scheduling. A thread polls
packet input only when there are no events. Packet input queue index
is included into poll command queue selection.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_schedule_internal.h  |   2 +-
 platform/linux-generic/odp_packet_io.c |   3 +-
 platform/linux-generic/odp_schedule.c  | 216 ++---
 3 files changed, 145 insertions(+), 76 deletions(-)

diff --git a/platform/linux-generic/include/odp_schedule_internal.h 
b/platform/linux-generic/include/odp_schedule_internal.h
index 78e16c4..0868394 100644
--- a/platform/linux-generic/include/odp_schedule_internal.h
+++ b/platform/linux-generic/include/odp_schedule_internal.h
@@ -24,7 +24,7 @@ int schedule_queue_init(queue_entry_t *qe);
 void schedule_queue_destroy(queue_entry_t *qe);
 int schedule_queue(const queue_entry_t *qe);
 void schedule_pktio_start(odp_pktio_t pktio, int num_in_queue,
- int in_queue_idx[], int prio);
+ int in_queue_idx[]);
 void odp_schedule_release_context(void);
 
 #ifdef __cplusplus
diff --git a/platform/linux-generic/odp_packet_io.c 
b/platform/linux-generic/odp_packet_io.c
index d625db2..a235798 100644
--- a/platform/linux-generic/odp_packet_io.c
+++ b/platform/linux-generic/odp_packet_io.c
@@ -334,8 +334,7 @@ int odp_pktio_start(odp_pktio_t id)
return -1;
}
 
-   schedule_pktio_start(id, 1, ,
-ODP_SCHED_PRIO_LOWEST);
+   schedule_pktio_start(id, 1, );
}
}
 
diff --git a/platform/linux-generic/odp_schedule.c 
b/platform/linux-generic/odp_schedule.c
index 22af755..e0fadfa 100644
--- a/platform/linux-generic/odp_schedule.c
+++ b/platform/linux-generic/odp_schedule.c
@@ -30,9 +30,12 @@ odp_thrmask_t sched_mask_all;
  * One per scheduled queue and packet interface */
 #define NUM_SCHED_CMD (ODP_CONFIG_QUEUES + ODP_CONFIG_PKTIO_ENTRIES)
 
-/* Scheduler sub queues */
+/* Priority queues per priority */
 #define QUEUES_PER_PRIO  4
 
+/* Packet input poll cmd queues */
+#define POLL_CMD_QUEUES  4
+
 /* Maximum number of dequeues */
 #define MAX_DEQ 4
 
@@ -52,6 +55,13 @@ typedef struct {
odp_queue_tpri_queue[ODP_CONFIG_SCHED_PRIOS][QUEUES_PER_PRIO];
pri_mask_t pri_mask[ODP_CONFIG_SCHED_PRIOS];
odp_spinlock_t mask_lock;
+
+   odp_spinlock_t poll_cmd_lock;
+   struct {
+   odp_queue_t queue;
+   uint16_tnum;
+   } poll_cmd[POLL_CMD_QUEUES];
+
odp_pool_t pool;
odp_shm_t  shm;
uint32_t   pri_count[ODP_CONFIG_SCHED_PRIOS][QUEUES_PER_PRIO];
@@ -74,7 +84,6 @@ typedef struct {
int   num;
int   index[MAX_PKTIN];
pktio_entry_t *pe;
-   int   prio;
};
};
 } sched_cmd_t;
@@ -84,19 +93,20 @@ typedef struct {
 
 
 typedef struct {
+   int thr;
+   int num;
+   int index;
+   int pause;
+   uint32_t pktin_polls;
odp_queue_t pri_queue;
odp_event_t cmd_ev;
-
-   odp_buffer_hdr_t *buf_hdr[MAX_DEQ];
queue_entry_t *qe;
queue_entry_t *origin_qe;
+   odp_buffer_hdr_t *buf_hdr[MAX_DEQ];
uint64_t order;
uint64_t sync[ODP_CONFIG_MAX_ORDERED_LOCKS_PER_QUEUE];
odp_pool_t pool;
int enq_called;
-   int num;
-   int index;
-   int pause;
int ignore_ordered_context;
 } sched_local_t;
 
@@ -113,6 +123,7 @@ static void sched_local_init(void)
 {
memset(_local, 0, sizeof(sched_local_t));
 
+   sched_local.thr   = odp_thread_id();
sched_local.pri_queue = ODP_QUEUE_INVALID;
sched_local.cmd_ev= ODP_EVENT_INVALID;
 }
@@ -180,6 +191,24 @@ int odp_schedule_init_global(void)
}
}
 
+   odp_spinlock_init(>poll_cmd_lock);
+   for (i = 0; i < POLL_CMD_QUEUES; i++) {
+   odp_queue_t queue;
+   char name[] = "odp_poll_cmd_YY";
+
+   name[13] = '0' + i / 10;
+   name[14] = '0' + i - 10 * (i / 10);
+
+   queue = odp_queue_create(name, ODP_QUEUE_TYPE_POLL, NULL);
+
+   if (queue == ODP_QUEUE_INVALID) {
+   ODP_ERR("Sched init: Queue create failed.\n");
+   return -1;
+   }
+
+   sched->poll_cmd[i].queue = queue;
+   }
+
odp_spinlock_init(>grp_lock);
 
for (i = 0; i < ODP_CONFIG_SCHED_GRPS; i++) {
@@ -199,11 +228,11 @@ int odp_schedule_term_global(void)
int ret = 0;
int rc = 0;
int i, j;
+   odp_event_t  ev;
 
for (i = 0; i < ODP_CONFIG_SCHED_PRIOS; i++) {
for (j = 0; j < QUEUES_PER_PRIO; j++) {
   

Re: [lng-odp] [PATCH] api: pktio link status

[Maxim Uvarov]

Merged,

with requested change.

Maxim.

On 12/11/2015 15:52, Savolainen, Petri (Nokia - FI/Espoo) wrote:

Mail subject should be: [API-NEXT PATCH] api: pktio: added link status

Otherwise OK. Could you update the git log entry before merging: "api: pktio: added 
link status"

Reviewed-by: Petri Savolainen 



-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Maxim Uvarov
Sent: Friday, December 11, 2015 2:45 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCH] api: pktio link status

Signed-off-by: Maxim Uvarov 
---
  v1 was link_state(), now it's link_status().

  include/odp/api/packet_io.h | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 443841e..8999b2c 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -673,6 +673,17 @@ void
odp_pktio_output_queue_param_init(odp_pktio_output_queue_param_t *param);
  void odp_pktio_print(odp_pktio_t pktio);

  /**
+ * Determine pktio link is up or down for a packet IO interface.
+ *
+ * @param pktio Packet IO handle.
+ *
+ * @retval  1 link is up
+ * @retval  0 link is down
+ * @retval <0 on failure
+*/
+int odp_pktio_link_status(odp_pktio_t pktio);
+
+/**
   * @}
   */

--
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

[lng-odp] Pool DMA mapping

[Christophe Milard]

Hi,

Following the discussion at the ARCH call, today, would it be reasonable to
require that all packet pools that can be used by a NIC have to be created
before the related nic pktio is opened? -This is implicitly required in RX,
as the pool handle from which buffer should be allocated in RX is a
parameter to the  pktio_open() function. Is the fact that an application
will not be able to transmit packets from a pool created AFTER pktio open()
was called acceptable?

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

Re: [lng-odp] [HELP] Question about API Classification and Traffic Manager

[Bala Manoharan]

Hi,

On 16 December 2015 at 20:22, Kury Nicolas
 wrote:
> Hi!
>
> I have some questions about Traffic Manager and Classifier.
>
> Traffic Manager:
> I see there is the possibility to send back the packets. Do you have any 
> example where this would be used ? I don't really see how we can combine the 
> different algorithms, example Strict Priority scheduling with Bandwidth 
> Shaping, etc.
> http://img11.hostingpics.net/pics/882875tarfficmanager.png

One use-case where you could use loopback is for crypto coz before
decrypting the packet you will not be able to access the packet fields
and hence you could receive the encrypted packets in a single flow
through a PMR rule decrypt the packet on the flow and send the clear
packet back through loopback interface to be classified to a specific
flow.
>
> Classifiers
> It is possible to have such a loopback ? 
> http://img11.hostingpics.net/pics/729760loop.png
> For example, a packet is classified in flow #1 with processing #1, and then 
> is classified in flow #2 with processing #2, etc. ?

Yes. This scenario is possible through loop back interface.
Since classifier is enabled on the interface level the packets coming
back through the loopback interface will be classified into their
respective flow in your example it will be flow #2

Hopefully the processing on the initial packet changes the packet
header fields or the fields which are configured as part of PMR rule.
Another example could be that the incoming packet is encrypted and the
initial processing decrypts the packets and sends it to the loopback
interface to be classified into a different flow.

Regards,
Bala
>
> Thank you very much!
> Nicolas
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp



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

Re: [lng-odp] [PATCH 2/2] doc: release-guide: add deprecated api section

[Maxim Uvarov]

On 12/15/2015 21:06, Mike Holmes wrote:

Describe how changes to the public api are handled from release to release.

Signed-off-by: Mike Holmes 
---
  doc/process-guide/release-guide.adoc | 38 
  1 file changed, 38 insertions(+)

diff --git a/doc/process-guide/release-guide.adoc 
b/doc/process-guide/release-guide.adoc
index f5d29d2..d932118 100644
--- a/doc/process-guide/release-guide.adoc
+++ b/doc/process-guide/release-guide.adoc
@@ -134,3 +134,41 @@ made every month if sufficient change has accumulated.
  
  === Implementation (Impl) ===

  Platform specific free form text relating to the version.
+
+== Deprecated APIs
+
+Whenever an API is changed as part of an api-next patch the following rules
+apply to provide a warning to implementers and users.
+
+* A patch will be applied to api-next that adds the deprecated indication to
+the old public API in odp/include

That sentence should never be in product documentation. Plans can be in
Jira cards, bugs, mailing list, but published docs should relay only on work
which is already done.


+* A patch will be applied to api-next that adds the new API and removes the
+old, in these cases the implementation and tests must also change at the same
+time to ensure that CI shows no regressions in the api-next branch.

same here.


+* When the Release Manager has scheduled the api change to be released in a
+future version, the initial deprecated patch will be moved to next branch and
+released in the next release cycle.
+* When at a minim of one release cycle has passed, and possibly longer as
+specified by the Release Manager the complete change will be merged to next and
+then released in the next cycle.

Release Manager scheduled in next release cycle ... It's it too complex
to read and understand when and what will be done. How about be more
community friendly in sentences? Something like:

""
ODP API provides special API to mark function and data types as deprecated.
Marking function as deprecated means that ODP Community will support all
functionality for that function, validation tests and test execution in 
CI system.

Because of support of both new API and deprecated adds additional load and
increase complexity marking functions as deprecated will happen only for
specific reason. That reason should be valuable, discussed in ODP 
community meetings,
recorded in mailing list and corresponding bug entry should be open. 
Also some transition

period for supporting old API should be defined.



+
+NOTE: Any given release never supports two versions of an API
+


That is not what deprecated means. I.e. deprecated means absolutely 
opposite - support old version

and new at the same time.


+.Marking a deprecated API element
+[source,c]
+
+/**
+ * Get buffer handle from event
+ *
+ * Converts an ODP_EVENT_BUFFER type event to a buffer.
+ *
+ * @deprecated  This api will be removed for some good reason defined here
doxygen is not enough I think. Also here might be some short description 
and link to bug.


+odp_buffer_t odp_buffer_from_event(odp_event_t ev) ODP_DEPRECATED;
and compile with: -Wno-deprecated-declarations

Maxim.


+ *
+ * @param ev   Event handle
+ *
+ * @return Buffer handle
+ *
+ * @see odp_event_type()
+ */
+odp_buffer_t odp_buffer_from_event(odp_event_t ev);
+
\ No newline at end of file


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

Re: [lng-odp] [API-NEXT PATCH v2] helper: add cuckoo hash implementation

[Maxim Uvarov]

From meeting we decided that we want solution based on pool. Can you 
post that

patches? We will try to help how to improve performance.

Maxim.

On 12/14/2015 22:30, Mike Holmes wrote:

Added to Tuesday agenda

On 12 December 2015 at 22:18, HePeng > wrote:


Ping.

So what is your decision on this.


在 2015年12月10日，下午1:06，HePeng > 写道：



在 2015年12月9日，下午6:49，Ola Liljedahl
> 写道：

On 9 December 2015 at 06:31, HePeng>wrote:



在 2015年12月8日，下午9:34，Ola Liljedahl
> 写道：

On 8 December 2015 at 12:42, Bill
Fischofer>wrote:

This is an interesting topic.  I'd like to discuss this
a bit during today's ODP public call.

I think the issue is that while a ring is a very useful
implementation construct its semantics are very SW centric.

But isn't the use case here SW centric?

Perhaps there's opportunity here for a new Queue type
that would permit an implementation to implement the
queue API as a ring for additional performance?

I think it is a bad idea to overload the ODP queue with
another type of usage and implied implementation. Better to
define a new ODP object.

What are the real requirements of the "ring" as used by the
cuckoo hash design? Enqueue/dequeue operations. Fixed size
is OK? Storing arbitrary objects (not just ODP events)?


The real requirement is use the ring as a sort of container.
Fixed Size is OK. And the ring should be used to
store any ODP events, since it is used as a container,
like vector in C++ STL.

What if I would like to store objects that are not ODP events in
the cuckoo hash table? E.g. arbitrary pointers (to memory that
is managed in some other way).


Yes, that is currently ring’s implementation.







  The scheduler itself could use this since its use of
queues is subject to the same issues.

On Mon, Dec 7, 2015 at 11:39 PM,
HePeng>wrote:

Hi Maxim,
I implement a new version of cuckoo hash
based on the ODP buffer/pool.

As I’ve mentioned earlier, the use of ring
in cuckoo hash is like to the use of
a container, e.g. a queue in C++ STL. In current
ODP implementation, I found that
the ODP queue is implemented more likely a facility
for transmitting objects, not
a container to store objects. Look at the ODP queue
enqueue interface:

int odp_queue_enq(odp_queue_t queue,
odp_event_t ev);

the *odp_event_t* is related to the events, but I
only want to use odp_queue to
storing and retrieving objects, any objects.


So I use ODP buffer/pool interfaces instead
of ODP queue
for the new cuckoo hash implementation.

However, compared to the previous implementation
based on ring, this version
suffers a serious performance degradation. The
evaluation is carried out on a Intel
servers. I test lookup time for 1000 lookups on a
table storing 1 million items.
The ODP buffer/pool version suffers at least a 2x
performance degradation.

This is the buffer/pool version, for 1M insert, and
1000 lookup time:

Average insert time = 2.383836, lookup time = 0.000353,

This is the ring version.

Average insert time = 1.629115, lookup time = 0.98

This performance degradation stems from the
heavy implementation of
 ODP buffer/pool. In the ring based one, all the
key is stored in a big array, and
the ring only stores the array indexes of each key.
Keys are retrieved using array indexes.
In the new one, I use ODP buffer to store the key
content. Keys are retrieved by
dereferencing a *odp_buffer_t* handle.

With this high performance degradation, I
suggest moving ring into the odp/api
as a container implementation, and use the previous
implementation of cuckoo 

Re: [lng-odp] [API-NEXT PATCH v5 2/7] api: pktio: added multiple pktio input queues

[Savolainen, Petri (Nokia - FI/Espoo)]

> -Original Message-
> From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> Sent: Tuesday, December 15, 2015 9:07 PM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v5 2/7] api: pktio: added multiple
> pktio input queues
> 
> 
> 
> On 15/12/15 08:24, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > Actually, this patch set was just merged, but we consider these for the
> next set following shortly (today/tomorrow). See replies below.
> >
> >
> >> -Original Message-
> >> From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> >> Sent: Monday, December 14, 2015 8:26 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [API-NEXT PATCH v5 2/7] api: pktio: added
> multiple
> >> pktio input queues
> >>
> >> Hi,
> >>
> >> I wanted to raise some questions about this, unfortunately it fell off
> >> the radar for a while.
> >>
> >> On 26/11/15 08:35, Petri Savolainen wrote:
> >>> Added input queue configuration parameters and functions
> >>> to setup multiple input queue and hashing. Added also
> >>> functions to query the number of queues and queue handles.
> >>> Direct receive does use new odp_pktin_queue_t handle type.
> >>>
> >>> Signed-off-by: Petri Savolainen 
> >>> ---
> >>>include/odp/api/packet_io.h| 136
> >> +
> >>>.../include/odp/plat/packet_io_types.h |   2 +
> >>>2 files changed, 138 insertions(+)
> >>>
> >>> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> >>> index 264fa75..26c9be5 100644
> >>> --- a/include/odp/api/packet_io.h
> >>> +++ b/include/odp/api/packet_io.h
> >>> @@ -19,6 +19,7 @@ extern "C" {
> >>>#endif
> >>>
> >>>#include 
> >>> +#include 
> >>>
> >>>/** @defgroup odp_packet_io ODP PACKET IO
> >>> *  Operations on a packet Input/Output interface.
> >>> @@ -42,6 +43,11 @@ extern "C" {
> >>> */
> >>>
> >>>/**
> >>> + * @typedef odp_pktin_queue_t
> >>> + * Direct packet input queue handle
> >>
> >> What's the difference between a ODP_PKTIN_MODE_RECV and a
> >> ODP_PKTIN_MODE_POLL queue? Apart from using different functions for
> >> receive?
> >
> > _RECV means that application uses only odp_pktio_recv() / _recv_queue()
> to directly fetch packet from the interface. _POLL means that application
> uses only poll type queues (odp_queue_t) to receive packets ==
> odp_queue_deq() / _deq_multi(). The third type is for scheduled queues
> (use only odp_schedule() / schedule_multi()).
> 
> I don't think that's a real difference between _RECV and _POLL type of
> input mode. You just call a different function to do exactly the same.
> E.g. ODP-OVS calls odp_pktio_recv() at the moment to _poll_ on the
> (only) queue of the NIC, and it opens it as ODP_PKTIN_MODE_RECV. With
> this patch applied, it can call odp_pktio_recv_queue() to do the same
> (but with several queues), or open the pktio as ODP_PKTIN_MODE_POLL, and
> then odp_queue_deq[_multi]() on a ODP_PKTIN_MODE_POLL. I don't see any
> difference, but it's very confusing.

The difference is that application (or other blocks in the system) can enqueue 
and event to an odp_queue_t. Direct packet input queues (odp_pktin_queue_t) do 
not accept packets (or events) from application. Application can only receive 
from those.



> Also, based on the current API definition you should be able to call
> odp_queue_enq() on a queue associated with an interface created with
> ODP_PKTIN_MODE_POLL or ODP_PKTIN_MODE_SCHED. odp_pktio_in_queues() will
> return an array of odp_queue_t type queues with ODP_QUEUE_TYPE_POLL or
> ODP_QUEUE_TYPE_SCHED. That operation doesn't make any sense.


odp_pktin_queue_t are lower level where you cannot enqueuer anything and 
odp_queue_t is upper level where you can. Upper level queues are useful when 
application need to synchronize other (e.g. control or timeout) events with 
incoming packets.


> 
> 
> >
> > The plan is to delete ODP_QUEUE_TYPE_PKTIN, after which all odp_queue_t
> for packet input are either _POLL or _SCHED type.
> 
> I think the main problem is the disconnection between pktio input/output
> modes and queue types.
> Instead of odp_pktio_[input|output]_mode_t we should just store
> - whether input and output are enabled or disabled
> - if input enabled, the odp_queue_type_t (poll or sched), so we can
> avoid duplicating poll and sched in ODP_PKTIN_MODE_*
> - if output enabled, whether it's normal or TM queue
> 


ODP_PKTIN_MODE_RECV  => user receives packets directly from the interface
ODP_PKTIN_MODE_POLL  => user polls events from queues directly
ODP_PKTIN_MODE_SCHED => user uses scheduler to receive events from queues

From output side ODP_PKTIN_MODE_POLL is missing, but I think it needs to be 
still added. That enables using odp_queue_t for output and write application in 
modules so that a does not need to know if it's the last in pipeline 

Re: [lng-odp] [API-NEXT PATCH v5 2/7] api: pktio: added multiple pktio input queues

[Zoltan Kiss]

Hi,

On 16/12/15 12:56, Savolainen, Petri (Nokia - FI/Espoo) wrote:

> >>>+typedef struct odp_pktio_input_queue_param_t {
> >>>+  /** Single thread per queue. Enable performance optimization when

> >>each

> >>>+* queue has only single user.
> >>>+* 0: Queue is multi-thread safe
> >>>+* 1: Queue is used by single thread only */
> >>>+  odp_bool_t single_user;
> >>>+
> >>>+  /** Enable flow hashing
> >>>+* 0: Do not hash flows
> >>>+* 1: Hash flows to input queues */
> >>>+  odp_bool_t hash_enable;
> >>>+
> >>>+  /** Protocol field selection for hashing. Multiple protocols can be
> >>>+* selected. */
> >>>+  odp_pktin_hash_proto_t hash_proto;
> >>>+
> >>>+  /** Number of input queues to be created. More than one input queue
> >>>+* require input hashing or classifier setup. Hash_proto is ignored
> >>>+* when hash_enable is zero or num_queues is one. This value must

> >>be
> >>
> >>OVS use the hashes even with one queue, it's useful for fast lookup in
> >>flow tables. Is there any reason to automatically disable it?

> >
> >
> >This describes input queue hashing (hashing of flows into queues).

>
>Let me reword my concerns:
>- What happens if num_queues > 1 and hash_enable = 0? What do we know
>about the distribution of packets between queues?

Not specified yet. But in practice, need to use classifier, or accept that ODP 
does not maintain packet order.




>- If num_queues = 1, hash_proto is ignored (no matter what hashe_enable
>is), so how do we set up hashing? As I said, we still need it.

As said this controls hashing between N queues. No hashing needed with single 
queue.
It is needed. I think the base of our misunderstanding is that your use 
of "hashing" also includes "distributing it between queues", while mine 
only includes "generate the hash". DPDK also separate these things, 
especially because "hashing" is not the only way of deciding where the 
packet goes, the recently discussed Flow Director (which extends RSS) is 
also a valid way.



> It does not control or comment about flow hash value stored in the 
packet. We don't have an API to control is yet.


I think it would be very confusing to have separate setting for "flow 
hash" and "the hash which decides which queue is chosen", and quite 
unlikely to implement in hardware when the two differs, as usually the 
card computes only one kind of hash.






>
>

> >It does not control the hash value stored into the packet.

>It sounds like it does.

It's part of odp_pktio_input_queue_param_t == input queue parameter.



>

> >It may very well be present also when using a single input queue.

>We would need certainty about that.
>
>In DPDK RSS enablement is not tied to have more than 1 RX queue.


Application does not see difference if you "hash" packets into single queue. 
All packets will be stored into the same queue anyway.


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

Re: [lng-odp] [API-NEXT PATCH 1/2] api: barrier: added memory barriers

[Maxim Uvarov]

Merged,
Maxim.

On 12/16/2015 16:51, Savolainen, Petri (Nokia - FI/Espoo) wrote:


Ping. Waiting to be merged.

*From:*EXT Bill Fischofer [mailto:bill.fischo...@linaro.org]
*Sent:* Sunday, December 13, 2015 12:44 AM
*To:* Savolainen, Petri (Nokia - FI/Espoo)
*Cc:* LNG ODP Mailman List
*Subject:* Re: [lng-odp] [API-NEXT PATCH 1/2] api: barrier: added 
memory barriers


On Fri, Dec 11, 2015 at 5:30 AM, Petri Savolainen 
> wrote:


Added new memory barriers. These follow C11 release /
acquire specification and replaces odp_sync_stores().
Used GCC __atomic_thread_fence to implement all three
barriers.

Signed-off-by: Petri Savolainen >

Reviewed-by: Bill Fischofer >


---
 include/odp/api/barrier.h | 11 -
 include/odp/api/sync.h| 82
---
 platform/linux-generic/include/odp/sync.h | 28 +++
 3 files changed, 90 insertions(+), 31 deletions(-)

diff --git a/include/odp/api/barrier.h b/include/odp/api/barrier.h
index 8ca2647..823eae6 100644
--- a/include/odp/api/barrier.h
+++ b/include/odp/api/barrier.h
@@ -18,8 +18,15 @@
 extern "C" {
 #endif

-/** @defgroup odp_barrier ODP BARRIER
- *  Thread excution and memory ordering barriers.
+/**
+ * @defgroup odp_barrier ODP BARRIER
+ * Thread excution and memory ordering barriers.
+ *
+ * @details
+ *  Thread execution barrier (odp_barrier_t) 
+ *
+ * Thread execution barrier synchronizes a group of threads to
wait on the
+ * barrier until the entire group has reached the barrier.
  *  @{
  */

diff --git a/include/odp/api/sync.h b/include/odp/api/sync.h
index 6477e74..c6f790c 100644
--- a/include/odp/api/sync.h
+++ b/include/odp/api/sync.h
@@ -8,7 +8,7 @@
 /**
  * @file
  *
- * ODP synchronisation
+ * ODP memory barriers
  */

 #ifndef ODP_API_SYNC_H_
@@ -18,42 +18,66 @@
 extern "C" {
 #endif

-/** @addtogroup odp_barrier
+/**
+ * @addtogroup odp_barrier
+ * @details
+ *  Memory barriers 
+ *
+ * Memory barriers enforce ordering of memory load and store
operations
+ * specified before and after the barrier. These barriers may
affect both
+ * compiler optimizations and CPU out-of-order execution. All ODP
+ * synchronization mechanisms (e.g. execution barriers, locks,
queues, etc )
+ * include all necessary memory barriers, so these calls are not
needed when
+ * using those. Also ODP atomic operations have memory ordered
versions. These
+ * explicit barriers may be needed when thread synchronization is
based on
+ * a non-ODP defined mechanism. Depending on the HW platform,
heavy usage of
+ * memory barriers may cause significant performance degradation.
+ *
  *  @{
  */

 /**
- * Synchronise stores
+ * Memory barrier for release operations
  *
- * Ensures that all CPU store operations that precede the
odp_sync_stores()
- * call are globally visible before any store operation that
follows it.
+ * This memory barrier has release semantics. It synchronizes
with a pairing
+ * barrier for acquire operations. The releasing and acquiring
threads
+ * synchronize through shared memory. The releasing thread must
call this
+ * barrier before signaling the acquiring thread. After the
acquiring thread
+ * receives the signal, it must call odp_mb_acquire() before it
reads the
+ * memory written by the releasing thread.
+ *
+ * This call is not needed when using ODP defined synchronization
mechanisms.
+ *
+ * @see odp_mb_acquire()
  */
-static inline void odp_sync_stores(void)
-{
-#if defined __x86_64__ || defined __i386__
-
-   __asm__  __volatile__ ("sfence\n" : : : "memory");
-
-#elif defined(__arm__)
-#if __ARM_ARCH == 6
-   __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
-   : : "r" (0) : "memory");
-#elif __ARM_ARCH >= 7 || defined __aarch64__
-
-   __asm__ __volatile__ ("dmb st" : : : "memory");
-#else
-   __asm__ __volatile__ ("" : : : "memory");
-#endif
-
-#elif defined __OCTEON__
-
-   __asm__  __volatile__ ("syncws\n" : : : "memory");
+void odp_mb_release(void);

-#else
-   __sync_synchronize();
-#endif
-}
+/**
+ * Memory barrier for acquire operations
+ *
+ * This memory barrier has acquire semantics. It synchronizes
with a pairing
+ * barrier for release operations. The releasing and acquiring
threads
+ * synchronize through shared memory. The releasing 

Re: [lng-odp] [API-NEXT PATCH 05/19] linux-generic: netmap: add initial multi queue support

[Zoltan Kiss]

On 16/12/15 13:45, Petri Savolainen wrote:

From: Matias Elo 

Added multi queue support to netmap pktio.

Signed-off-by: Matias Elo 
---
  platform/linux-generic/include/odp_packet_netmap.h |  34 +-
  platform/linux-generic/pktio/netmap.c  | 422 ++---
  2 files changed, 403 insertions(+), 53 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_netmap.h 
b/platform/linux-generic/include/odp_packet_netmap.h
index a088d23..bede176 100644
--- a/platform/linux-generic/include/odp_packet_netmap.h
+++ b/platform/linux-generic/include/odp_packet_netmap.h
@@ -7,23 +7,53 @@
  #ifndef ODP_PACKET_NETMAP_H
  #define ODP_PACKET_NETMAP_H

+#include 
+#include 
  #include 
  #include 
+#include 
+#include 

  #include 
  #include 

+#define NM_MAX_DESC 32
+
+/** Ring for mapping pktin/pktout queues to netmap descriptors */
+struct netmap_ring_t {
+   unsigned first; /**< Index of first netmap descriptor */
+   unsigned last;  /**< Index of last netmap descriptor */
+   unsigned num;   /**< Number of netmap descriptors */
+   /** Netmap metadata for the device */
+   struct nm_desc *desc[NM_MAX_DESC];
+   unsigned cur;   /**< Index of current netmap descriptor */
+   odp_ticketlock_t lock;  /**< Queue lock */
+};
+
+typedef union {
+   struct netmap_ring_t s;
+   uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(struct netmap_ring_t))];
+} netmap_ring_t ODP_ALIGNED_CACHE;
+
  /** Packet socket using netmap mmaped rings for both Rx and Tx */
  typedef struct {
odp_pool_t pool;/**< pool to alloc packets from */
size_t max_frame_len;   /**< buf_size - sizeof(pkt_hdr) */
-   struct nm_desc *rx_desc;/**< netmap meta-data for the device */
-   struct nm_desc *tx_desc;/**< netmap meta-data for the device */
uint32_t if_flags;  /**< interface flags */
int sockfd; /**< control socket */
unsigned char if_mac[ETH_ALEN]; /**< eth mac address */
char nm_name[IF_NAMESIZE + 7];  /**< netmap: */
odp_pktio_capability_t  capa;   /**< interface capabilities */
+   unsigned num_rx_queues; /**< number of pktin queues */
+   unsigned num_tx_queues; /**< number of pktout queues */
+   uint32_t num_rx_rings;  /**< number of nm rx rings */
+   uint32_t num_tx_rings;  /**< number of nm tx rings */
+   odp_bool_t lockless_rx; /**< no locking for rx */
+   odp_bool_t lockless_tx; /**< no locking for tx */
+   /** mapping of pktin queues to netmap rx descriptors */
+   netmap_ring_t rx_desc_ring[PKTIO_MAX_QUEUES];
+   /** mapping of pktout queues to netmap tx descriptors */
+   netmap_ring_t tx_desc_ring[PKTIO_MAX_QUEUES];
  } pkt_netmap_t;

  #endif
diff --git a/platform/linux-generic/pktio/netmap.c 
b/platform/linux-generic/pktio/netmap.c
index 38cdd1f..38a7d46 100644
--- a/platform/linux-generic/pktio/netmap.c
+++ b/platform/linux-generic/pktio/netmap.c
@@ -10,9 +10,9 @@
  #define _GNU_SOURCE
  #endif

+#include 
  #include 
  #include 
-#include 
  #include 
  #include 

@@ -78,14 +78,178 @@ done:
return err;
  }

+/**
+ * Map netmap rings to pktin/pktout queues
+ *
+ * @param rings  Array of netmap descriptor rings
+ * @param num_queues Number of pktin/pktout queues
+ * @param num_rings  Number of matching netmap rings
+ */
+static inline void map_netmap_rings(netmap_ring_t *rings,
+   unsigned num_queues, unsigned num_rings)
+{
+   struct netmap_ring_t *desc_ring;
+   unsigned rings_per_queue;
+   unsigned remainder;
+   unsigned mapped_rings;
+   unsigned i;
+   unsigned desc_id = 0;
+
+   rings_per_queue = num_rings / num_queues;
+   remainder = num_rings % num_queues;
+
+   if (remainder)
+   ODP_DBG("WARNING: Netmap rings mapped unevenly to queues\n");
+
+   for (i = 0; i < num_queues; i++) {
+   desc_ring = [i].s;
+   if (i < remainder)
+   mapped_rings = rings_per_queue + 1;
+   else
+   mapped_rings = rings_per_queue;
+
+   desc_ring->first = desc_id;
+   desc_ring->cur = desc_id;
+   desc_ring->last = desc_ring->first + mapped_rings - 1;
+   desc_ring->num = mapped_rings;
+
+   desc_id = desc_ring->last + 1;
+   }
+}
+
+/**
+ * Close pktio queues
+ *
+ * @param pktio_entryPacket IO handle
+ */
+static inline void netmap_close_queues(pktio_entry_t *pktio_entry)
+{
+   int i;
+   struct pktio_entry *pktio = _entry->s;
+   odp_pktio_input_mode_t mode = pktio_entry->s.param.in_mode;
+
+   for (i = 0; i < PKTIO_MAX_QUEUES; i++) {
+   if (mode != ODP_PKTIN_MODE_POLL && mode != ODP_PKTIN_MODE_SCHED)
+   

Re: [lng-odp] Pool DMA mapping

[Zoltan Kiss]

On 16/12/15 15:39, Christophe Milard wrote:

Hi,

Following the discussion at the ARCH call, today, would it be reasonable
to require that all packet pools that can be used by a NIC have to be
created before the related nic pktio is opened? -This is implicitly
required in RX, as the pool handle from which buffer should be allocated
in RX is a parameter to the  pktio_open() function.


Yes, for me it's quite obvious.

? Is the fact that an

application will not be able to transmit packets from a pool created
AFTER pktio open() was called acceptable?


I think TX is different from that point of view. The packet should 
obviously exist at the time of TX, but whether it came from the pool 
supplied to odp_pktio_open() or not shouldn't really matter.




/Christophe.


___
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] Pool DMA mapping

[Zoltan Kiss]

On 16/12/15 16:47, Zoltan Kiss wrote:



On 16/12/15 15:39, Christophe Milard wrote:

Hi,

Following the discussion at the ARCH call, today, would it be reasonable
to require that all packet pools that can be used by a NIC have to be
created before the related nic pktio is opened? -This is implicitly
required in RX, as the pool handle from which buffer should be allocated
in RX is a parameter to the  pktio_open() function.


Yes, for me it's quite obvious.

? Is the fact that an

application will not be able to transmit packets from a pool created
AFTER pktio open() was called acceptable?


I think TX is different from that point of view. The packet should
obviously exist at the time of TX, but whether it came from the pool
supplied to odp_pktio_open() or not shouldn't really matter.


Or is there a particular reason you need this? I think I've missed 
during the arch call why is this important.






/Christophe.


___
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

[lng-odp] [API-NEXT/PATCHv2 1/6] api: classification: add class of serivce create api

[Balasubramanian Manoharan]

class of service create function now takes pool, queue, drop policy and
name as input parameters.
Adds class of service parameter structure odp_cls_cos_param_t and
initialization function odp_cls_cos_param_init()

Signed-off-by: Balasubramanian Manoharan 
---
v2: additional documentation and review comments from Petri

 include/odp/api/classification.h | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/include/odp/api/classification.h b/include/odp/api/classification.h
index 725e1ab..4db5bf0 100644
--- a/include/odp/api/classification.h
+++ b/include/odp/api/classification.h
@@ -37,7 +37,7 @@ extern "C" {
 
 /**
  * @def ODP_COS_INVALID
- * This value is returned from odp_cos_create() on failure,
+ * This value is returned from odp_cls_cos_create() on failure,
  * May also be used as a sink class of service that
  * results in packets being discarded.
  */
@@ -60,9 +60,9 @@ extern "C" {
  */
 
 /**
- * Class-of-service packet drop policies
+ * class of service packet drop policies
  */
-typedef enum odp_cos_drop {
+typedef enum odp_cls_drop {
ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool policy */
 } odp_drop_e;
@@ -89,14 +89,39 @@ typedef enum odp_cos_hdr_flow_fields {
 } odp_cos_hdr_flow_fields_e;
 
 /**
+ * Class of service parameters
+ * Used to communicate class of service creation options
+ */
+typedef struct odp_cls_cos_param {
+   odp_queue_t queue;  /**< Queue associated with CoS */
+   odp_pool_t pool;/**< Pool associated with CoS */
+   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
+} odp_cls_cos_param_t;
+
+/**
+ * Initialize class of service parameters
+ *
+ * Initialize an odp_cls_cos_param_t to its default value for all fields
+ *
+ * @param param   Address of the odp_cls_cos_param_t to be initialized
+ */
+void odp_cls_cos_param_init(odp_cls_cos_param_t *param);
+
+/**
  * Create a class-of-service
  *
- * @param[in]  nameString intended for debugging purposes.
+ * @param  nameString intended for debugging purposes.
  *
- * @return Class of service instance identifier
+ * @param  param   class of service parameters
+ *
+ * @retval class of service handle
  * @retval ODP_COS_INVALID on failure.
+ *
+ * @note ODP_QUEUE_INVALID and ODP_POOL_INVALID are valid values for queue
+ * and pool associated with a class of service and when any one of these values
+ * are configured as INVALID then the packets assigned to the CoS gets dropped.
  */
-odp_cos_t odp_cos_create(const char *name);
+odp_cos_t odp_cls_cos_create(const char *name, odp_cls_cos_param_t *param);
 
 /**
  * Discard a class-of-service along with all its associated resources
-- 
1.9.1

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

[lng-odp] [API-NEXT/PATCHv2 4/6] example: classifier: add class of service create api

[Balasubramanian Manoharan]

Replaces odp_cos_create() function with odp_cls_cos_create() function

Signed-off-by: Balasubramanian Manoharan 
---
 example/classifier/odp_classifier.c | 42 +
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 0da07e7..8daddd5 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -356,16 +356,16 @@ static void *pktio_receive_thread(void *arg)
 static void configure_default_cos(odp_pktio_t pktio, appl_args_t *args)
 {
odp_queue_param_t qparam;
-   odp_cos_t cos_default;
const char *queue_name = "DefaultQueue";
const char *pool_name = "DefaultPool";
const char *cos_name = "DefaultCos";
odp_queue_t queue_default;
odp_pool_t pool_default;
+   odp_cos_t cos_default;
odp_pool_param_t pool_params;
+   odp_cls_cos_param_t cls_param;
global_statistics *stats = args->stats;
 
-   cos_default = odp_cos_create(cos_name);
 
odp_queue_param_init();
qparam.sched.prio = ODP_SCHED_PRIO_DEFAULT;
@@ -373,9 +373,8 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
qparam.sched.group = ODP_SCHED_GROUP_ALL;
queue_default = odp_queue_create(queue_name,
 ODP_QUEUE_TYPE_SCHED, );
-
-   if (0 > odp_cos_queue_set(cos_default, queue_default)) {
-   EXAMPLE_ERR("odp_cos_queue_set failed");
+   if (queue_default == ODP_QUEUE_INVALID) {
+   EXAMPLE_ERR("Error: default queue create failed.\n");
exit(EXIT_FAILURE);
}
 
@@ -384,7 +383,6 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
pool_params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
pool_params.pkt.num = SHM_PKT_POOL_SIZE / SHM_PKT_POOL_BUF_SIZE;
pool_params.type= ODP_POOL_PACKET;
-
pool_default = odp_pool_create(pool_name, _params);
 
if (pool_default == ODP_POOL_INVALID) {
@@ -392,8 +390,14 @@ static void configure_default_cos(odp_pktio_t pktio, 
appl_args_t *args)
exit(EXIT_FAILURE);
}
 
-   if (0 > odp_cls_cos_pool_set(cos_default, pool_default)) {
-   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = pool_default;
+   cls_param.queue = queue_default;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+   cos_default = odp_cls_cos_create(cos_name, _param);
+
+   if (cos_default == ODP_COS_INVALID) {
+   EXAMPLE_ERR("Error: default cos create failed.\n");
exit(EXIT_FAILURE);
}
 
@@ -419,15 +423,13 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
char queue_name[ODP_QUEUE_NAME_LEN];
char pool_name[ODP_POOL_NAME_LEN];
odp_pool_param_t pool_params;
+   odp_cls_cos_param_t cls_param;
int i;
global_statistics *stats;
odp_queue_param_t qparam;
 
for (i = 0; i < args->policy_count; i++) {
stats = >stats[i];
-   snprintf(cos_name, sizeof(cos_name), "CoS%s",
-stats->cos_name);
-   stats->cos = odp_cos_create(cos_name);
 
const odp_pmr_match_t match = {
.term = stats->rule.term,
@@ -453,11 +455,6 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
exit(EXIT_FAILURE);
}
 
-   if (0 > odp_cos_queue_set(stats->cos, stats->queue)) {
-   EXAMPLE_ERR("odp_cos_queue_set failed");
-   exit(EXIT_FAILURE);
-   }
-
odp_pool_param_init(_params);
pool_params.pkt.seg_len = SHM_PKT_POOL_BUF_SIZE;
pool_params.pkt.len = SHM_PKT_POOL_BUF_SIZE;
@@ -469,11 +466,19 @@ static void configure_cos(odp_pktio_t pktio, appl_args_t 
*args)
 args->stats[i].cos_name, i);
stats->pool = odp_pool_create(pool_name, _params);
 
-   if (0 > odp_cls_cos_pool_set(stats->cos, stats->pool)) {
-   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   if (stats->pool == ODP_POOL_INVALID) {
+   EXAMPLE_ERR("Error: default pool create failed.\n");
exit(EXIT_FAILURE);
}
 
+   snprintf(cos_name, sizeof(cos_name), "CoS%s",
+stats->cos_name);
+   odp_cls_cos_param_init(_param);
+   cls_param.pool = stats->pool;
+   cls_param.queue = stats->queue;
+   cls_param.drop_policy = ODP_COS_DROP_POOL;
+   stats->cos = odp_cls_cos_create(cos_name, _param);
+
if (0 > odp_pktio_pmr_cos(stats->pmr, pktio, 

[lng-odp] [API-NEXT/PATCHv2 6/6] linux-generic: classification: rename odp_drop_e to odp_cls_drop_t

[Balasubramanian Manoharan]

changes drop policy enum name from odp_drop_e to odp_cls_drop_t

Signed-off-by: Balasubramanian Manoharan 
---
 platform/linux-generic/include/odp_classification_datamodel.h | 2 +-
 platform/linux-generic/odp_classification.c   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index 7784ea8..5b65202 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -70,7 +70,7 @@ struct cos_s {
union pmr_u *pmr;   /* Chained PMR */
union cos_u *linked_cos;/* CoS linked with the PMR */
uint32_t valid; /* validity Flag */
-   odp_drop_e drop_policy; /* Associated Drop Policy */
+   odp_cls_drop_t drop_policy; /* Associated Drop Policy */
odp_queue_group_t queue_group;  /* Associated Queue Group */
odp_cos_flow_set_t flow_set;/* Assigned Flow Set */
char name[ODP_COS_NAME_LEN];/* name */
diff --git a/platform/linux-generic/odp_classification.c 
b/platform/linux-generic/odp_classification.c
index da6123e..7a8b239 100644
--- a/platform/linux-generic/odp_classification.c
+++ b/platform/linux-generic/odp_classification.c
@@ -166,7 +166,7 @@ odp_cos_t odp_cls_cos_create(const char *name, 
odp_cls_cos_param_t *param)
int i;
queue_entry_t *queue;
pool_entry_t *pool;
-   odp_drop_e drop_policy;
+   odp_cls_drop_t drop_policy;
 
/* Packets are dropped if Queue or Pool is invalid*/
if (param->queue == ODP_QUEUE_INVALID)
@@ -321,7 +321,7 @@ odp_queue_t odp_cos_queue(odp_cos_t cos_id)
return cos->s.queue->s.handle;
 }
 
-int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e drop_policy)
+int odp_cos_drop_set(odp_cos_t cos_id, odp_cls_drop_t drop_policy)
 {
cos_t *cos = get_cos_entry(cos_id);
 
@@ -335,7 +335,7 @@ int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e 
drop_policy)
return 0;
 }
 
-odp_drop_e odp_cos_drop(odp_cos_t cos_id)
+odp_cls_drop_t odp_cos_drop(odp_cos_t cos_id)
 {
cos_t *cos = get_cos_entry(cos_id);
 
-- 
1.9.1

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

[lng-odp] [API-NEXT/PATCHv2 5/6] api: classification: rename odp_drop_e to odp_cls_drop_t

[Balasubramanian Manoharan]

Changes drop policy enum name from odp_drop_e to odp_cls_drop_t

Signed-off-by: Balasubramanian Manoharan 
---
 include/odp/api/classification.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/odp/api/classification.h b/include/odp/api/classification.h
index 4db5bf0..c9493c2 100644
--- a/include/odp/api/classification.h
+++ b/include/odp/api/classification.h
@@ -65,7 +65,7 @@ extern "C" {
 typedef enum odp_cls_drop {
ODP_COS_DROP_POOL,/**< Follow buffer pool drop policy */
ODP_COS_DROP_NEVER,/**< Never drop, ignoring buffer pool policy */
-} odp_drop_e;
+} odp_cls_drop_t;
 
 /**
  * Packet header field enumeration
@@ -95,7 +95,7 @@ typedef enum odp_cos_hdr_flow_fields {
 typedef struct odp_cls_cos_param {
odp_queue_t queue;  /**< Queue associated with CoS */
odp_pool_t pool;/**< Pool associated with CoS */
-   odp_drop_e drop_policy; /**< Drop policy associated with CoS */
+   odp_cls_drop_t drop_policy; /**< Drop policy associated with CoS */
 } odp_cls_cos_param_t;
 
 /**
@@ -170,7 +170,7 @@ odp_queue_t odp_cos_queue(odp_cos_t cos_id);
  *
  * @note Optional.
  */
-int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e drop_policy);
+int odp_cos_drop_set(odp_cos_t cos_id, odp_cls_drop_t drop_policy);
 
 /**
 * Get the drop policy configured for a specific class-of-service instance.
@@ -180,7 +180,7 @@ int odp_cos_drop_set(odp_cos_t cos_id, odp_drop_e 
drop_policy);
 * @retval  Drop policy configured with the given
 *  class-of-service
 */
-odp_drop_e odp_cos_drop(odp_cos_t cos_id);
+odp_cls_drop_t odp_cos_drop(odp_cos_t cos_id);
 
 /**
  * Request to override per-port class of service
-- 
1.9.1

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

[lng-odp] [PATCH v4] helper: linux: add thread type in pthread_create

[Hemant Agrawal]

The exisiting helper routine only create the worker threads.
However there is a need to use the same for creating the control
thread as well. e.g. CLI thread.

Signed-off-by: Hemant Agrawal 
---
 example/classifier/odp_classifier.c   | 2 +-
 example/generator/odp_generator.c | 9 ++---
 example/ipsec/odp_ipsec.c | 2 +-
 example/packet/odp_pktio.c| 3 ++-
 example/timer/odp_timer_test.c| 2 +-
 helper/include/odp/helper/linux.h | 5 -
 helper/linux.c| 6 --
 helper/test/odp_thread.c  | 3 ++-
 test/api_test/odp_common.c| 2 +-
 test/performance/odp_atomic.c | 2 +-
 test/performance/odp_l2fwd.c  | 3 ++-
 test/performance/odp_pktio_perf.c | 4 ++--
 test/performance/odp_scheduling.c | 2 +-
 test/validation/common/odp_cunit_common.c | 2 +-
 14 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 0da07e7..00da68a 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -593,7 +593,7 @@ int main(int argc, char *argv[])
odp_cpumask_set(_mask, cpu);
odph_linux_pthread_create(_tbl[i], _mask,
  pktio_receive_thread,
- args);
+ args, ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
}
 
diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 2de530d..93eefe9 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -784,7 +784,8 @@ int main(int argc, char *argv[])
abort();
args->thread[1].mode = args->appl.mode;
odph_linux_pthread_create(_tbl[1], _mask,
- gen_recv_thread, >thread[1]);
+ gen_recv_thread, >thread[1],
+ ODP_THREAD_WORKER);
 
tq = odp_queue_create("", ODP_QUEUE_TYPE_POLL, NULL);
if (tq == ODP_QUEUE_INVALID)
@@ -804,7 +805,8 @@ int main(int argc, char *argv[])
odp_cpumask_zero(_mask);
odp_cpumask_set(_mask, cpu_next);
odph_linux_pthread_create(_tbl[0], _mask,
- gen_send_thread, >thread[0]);
+ gen_send_thread, >thread[0],
+ ODP_THREAD_WORKER);
 
} else {
int cpu = odp_cpumask_first();
@@ -849,7 +851,8 @@ int main(int argc, char *argv[])
odph_linux_pthread_create(_tbl[i],
  _mask,
  thr_run_func,
- >thread[i]);
+ >thread[i],
+ ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
 
}
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index d784c31..88e73ff 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -1333,7 +1333,7 @@ main(int argc, char *argv[])
 * Create and init worker threads
 */
odph_linux_pthread_create(thread_tbl, ,
- pktio_thread, NULL);
+ pktio_thread, NULL, ODP_THREAD_WORKER);
 
/*
 * If there are streams attempt to verify them else
diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
index 93c38f5..75e92ac 100644
--- a/example/packet/odp_pktio.c
+++ b/example/packet/odp_pktio.c
@@ -442,7 +442,8 @@ int main(int argc, char *argv[])
odp_cpumask_set(_mask, cpu);
odph_linux_pthread_create(_tbl[i], _mask,
  thr_run_func,
- >thread[i]);
+ >thread[i],
+ ODP_THREAD_WORKER);
cpu = odp_cpumask_next(, cpu);
}
 
diff --git a/example/timer/odp_timer_test.c b/example/timer/odp_timer_test.c
index 0ec73b1..bd05ce4 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -479,7 +479,7 @@ int main(int argc, char *argv[])
 
/* Create and launch worker threads */
odph_linux_pthread_create(thread_tbl, ,
- run_thread, gbls);
+ run_thread, gbls, ODP_THREAD_WORKER);
 
/* Wait for worker threads to exit */
odph_linux_pthread_join(thread_tbl, num_workers);
diff --git 

Re: [lng-odp] [API-NEXT PATCH v2 0/6] api: time: add rate and delay APIs

[Ivan Khoronzhuk]

On 16.12.15 05:30, Mike Holmes wrote:


On 15 December 2015 at 07:29, Ivan Khoronzhuk > wrote:

This series adds odp_time_local_res() and odp_time_wait() calls to
time API and it's validation tests and usage.


When do we start requiring that new api work comes with a corresponding update to the 
user-guide 
 ?
I think we should just start now so that the doc get builts up and not eroded 
by new API work.
This would be a new requirement just as adding validation tests already is, and 
it would become a blocker on api work moving to master.

Time API after this series requires only global time API that is not very 
different from local time API.
Only functions with "local" word will be duplicated with "global" word and it 
can be used between threads.
The validation test for global time API will be slightly different. I think we 
can start but whole picture will be visible after
adding global time API.




Based on:
[lng-odp] [API-NEXT PATCHv4] linux-generic: time: remove posix bleed 
through on odp_time_t
https://lists.linaro.org/pipermail/lng-odp/2015-December/018465.html

Since v1:
- used "wait" instead of "delay"
- used "res" instead of "rate"
- used inlined functions in odp_time_wait()
- corrected new API descriptions

Ivan Khoronzhuk (6):
   api: time: add resolution and wait API calls
   performance: pktio_perf: use odp_time_wait() function instead of
 looping
   validation: time: test time constants in ns
   validation: time: add test convertsion on 0
   validation: time: add test for odp_time_local_res() and use resolution
   validation: time: add test for odp_time_wait()

  include/odp/api/time.h| 17 
  platform/linux-generic/odp_time.c | 71 
  test/performance/odp_pktio_perf.c | 17 +---
  test/validation/time/time.c   | 86 
---
  test/validation/time/time.h   |  3 ++
  5 files changed, 148 insertions(+), 46 deletions(-)

--
1.9.1

___
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

__




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

Re: [lng-odp] [API-NEXT PATCH] api: remove ODP_DEPRECATED

[Maxim Uvarov]

To not break a build just add CFLAGS="-Wno-deprecated-declarations".
That will be good check that no more deprecated function exist in the code.

I.e. procedure is following functions will have ODP_DEPRECATED tag for some
tome and ./configure will support -Wno-deprecated-declarations as default.
And some option like --without-depricated to build clean build. That way 
we can easy

find that our code is free from deprecated things.

Even might be masted will not disable that warning in any time. But some 
stable branch

will disable deprecated warnings and have some deprecated functions.

Best regards,
Maxim.


On 12/15/2015 21:06, Mike Holmes wrote:

The deprecation mechanism should not break the build.
Remove this definition because the doxygen deprecated flag will be used
directly.

Signed-off-by: Mike Holmes 
---
  include/odp/api/hints.h | 5 -
  1 file changed, 5 deletions(-)

diff --git a/include/odp/api/hints.h b/include/odp/api/hints.h
index ea67fc4..b117ed3 100644
--- a/include/odp/api/hints.h
+++ b/include/odp/api/hints.h
@@ -51,11 +51,6 @@ extern "C" {
  #define ODP_PRINTF_FORMAT(x, y) __attribute__((format(printf, (x), (y
  
  /**

- * Indicate deprecated variables, functions or types
- */
-#define ODP_DEPRECATED __attribute__((__deprecated__))
-
-/**
   * Intentionally unused variables ot functions
   */
  #define ODP_UNUSED __attribute__((__unused__))


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

[lng-odp] odp_cpumask_default_worker() calls from worker threads

[Zoltan Kiss]

Hi,

I have a question: is it allowed to call these functions from worker 
threads? The current linux-generic implementation doesn't seem to 
support that, because it checks for the affinity of the current thread. 
In case of a worker it is probably restricted for one CPU.
It seems to me that "how to create a thread and what affinity it should 
have" is not part of the API, so probably implementation shouldn't rely 
on the calling thread's affinity when working out how many workers 
should there be.


Regards,

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