Re: [lng-odp] [PATCH 2/2] checkpatch: use codespell for odp

[Anders Roxell]

On 2015-05-18 15:49, Maxim Uvarov wrote:
> checkpatch: use codespell for odp

Remove.

> 
> By default configure is looking for codespell installed.
> That check can be optionally turned off. Code spell can be
> used directly from command line or be used for checkpatch.
> For now it finds bunch of spelling issues:
> 
> ./configure.ac:52: archetecture  ==> architecture
> ./m4/ax_prog_doxygen.m4:24: seperate  ==> separate
> ./m4/ax_prog_doxygen.m4:464: Seperate  ==> Separate
> ./m4/ax_prog_doxygen.m4:465: seperate  ==> separate
> ./doc/api_guide_lines.dox:93: addtion  ==> addition
> ./doc/api_guide_lines.dox:153: begining  ==> beginning
> ./scripts/checkpatch.pl:5262: preceeded  ==> preceded
> ./platform/linux-generic/odp_timer.c:601: occurence  ==> occurrence
> ./platform/linux-generic/odp_rwlock.c:52: aquired  ==> acquired
> ./platform/linux-generic/odp_pool.c:164: paramters  ==> parameters
> ./helper/ring.c:283: preceeded  ==> preceded
> ./helper/include/odp/helper/ip.h:157: extention  ==> extension
> ./example/ipsec/odp_ipsec_sa_db.h:17: Assocation  ==> Association
> ./example/ipsec/odp_ipsec_sa_db.h:32: Assocation  ==> Association
> ./example/generator/odp_generator.c:537: funtion  ==> function
> ./include/odp/api/queue.h:44: lenght  ==> length
> ./include/odp/api/queue.h:216: responsability  ==> responsibility
> ./include/odp/api/init.h:158: dependant  ==> dependent
> ./include/odp/api/crypto.h:113: paramters  ==> parameters
> ./include/odp/api/crypto.h:136: peformed  ==> performed
> ./include/odp/api/packet_io.h:67: becuase  ==> because
> ./include/odp/api/pool.h:40: lenght  ==> length
> ./test/validation/odp_cpumask.c:126: occured  ==> occurred
> ./test/performance/odp_atomic.c:47: excercise  ==> exercise

Maybe make the example list a bit shorter.

> 
> Signed-off-by: Maxim Uvarov 
> ---
>  .checkpatch.conf |  1 +
>  configure.ac | 20 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/.checkpatch.conf b/.checkpatch.conf
> index 9076410..17fcea6 100644
> --- a/.checkpatch.conf
> +++ b/.checkpatch.conf
> @@ -2,3 +2,4 @@
>  --strict
>  --ignore=NEW_TYPEDEFS
>  --ignore=DEPRECATED_VARIABLE
> +--codespell
> diff --git a/configure.ac b/configure.ac
> index d20bad2..73bb97f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -248,6 +248,26 @@ AC_CHECK_LIB([crypto], [EVP_EncryptInit], [],
>  AC_CHECK_HEADERS([openssl/des.h openssl/rand.h openssl/hmac.h 
> openssl/evp.h], [],
>   [AC_MSG_ERROR([OpenSSL headers required])])
>  
> +
> +##
> +# Check for Codespell tool
> +##
> +AC_CHECK_PROG([CODESPELL], [codespell], [codespell])
> +codespell_disabled=no
> +AC_ARG_ENABLE([codespell],
> +[AS_HELP_STRING([--disable-codespell], [Use codespell for checkpatch.])],
> +[case "$withval" in
> + no)  ;;
> + yes) codespell_disabled=yes ;;
> + *)   AC_MSG_ERROR([Bad value ${withval} for --disable-codespell.]) ;;
> + esac])
> +
> +if test $codespell_disabled == "no" && test -z $CODESPELL
> +then
> +AC_MSG_ERROR([Codespell not found. apt-get install codespell or
> +  use --disable-codespell])
> +fi
> +

I don't think it belongs in configure.ac at all.
Because configure is for configuring and building the code, whilst checkpatch is
for checking patches and has nothing to do with the software.

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

Re: [lng-odp] [PATCH 1/2] checkpatch: add spelling.txt

[Anders Roxell]

On 2015-05-18 15:49, Maxim Uvarov wrote:
> Add linux kernel spelling.txt file to detect common typos.
> Other alternative for ODP might be use lintian:
> /usr/share/lintian/data/spelling/corrections
> file. But check patch does not have option to override variable
> with that file name. So I think for now we can stay with
> kernels spelling.txt.

You only need to say that you add the Linux kernel spelling.txt file.

Cheers,
Anders

> 
> Signed-off-by: Maxim Uvarov 
> ---
>  scripts/spelling.txt | 1043 
> ++
>  1 file changed, 1043 insertions(+)
>  create mode 100644 scripts/spelling.txt
> 
> diff --git a/scripts/spelling.txt b/scripts/spelling.txt
> new file mode 100644
> index 000..bb8e4d0
> --- /dev/null
> +++ b/scripts/spelling.txt
> @@ -0,0 +1,1043 @@
> +# Originally from Debian's Lintian tool. Various false positives have been
> +# removed, and various additions have been made as they've been discovered
> +# in the kernel source.
> +#
> +# License: GPLv2
> +#
> +# The format of each line is:
> +# mistake||correction
> +#
> +abandonning||abandoning
> +abigious||ambiguous
> +abitrate||arbitrate
> +abov||above
> +abreviated||abbreviated
> +absense||absence
> +absolut||absolute
> +absoulte||absolute
> +acccess||access
> +acceleratoin||acceleration
> +accelleration||acceleration
> +accesing||accessing
> +accesnt||accent
> +accessable||accessible
> +accesss||access
> +accidentaly||accidentally
> +accidentually||accidentally
> +accoding||according
> +accomodate||accommodate
> +accomodates||accommodates
> +accordign||according
> +accoring||according
> +accout||account
> +accquire||acquire
> +accquired||acquired
> +acessable||accessible
> +acess||access
> +achitecture||architecture
> +acient||ancient
> +acitions||actions
> +acitve||active
> +acknowldegement||acknowldegement
> +acknowledgement||acknowledgment
> +ackowledge||acknowledge
> +ackowledged||acknowledged
> +acording||according
> +activete||activate
> +acumulating||accumulating
> +adapater||adapter
> +addional||additional
> +additionaly||additionally
> +addres||address
> +addreses||addresses
> +addresss||address
> +aditional||additional
> +aditionally||additionally
> +aditionaly||additionally
> +adminstrative||administrative
> +adress||address
> +adresses||addresses
> +adviced||advised
> +afecting||affecting
> +agaist||against
> +albumns||albums
> +alegorical||allegorical
> +algorith||algorithm
> +algorithmical||algorithmically
> +algoritm||algorithm
> +algoritms||algorithms
> +algorrithm||algorithm
> +algorritm||algorithm
> +allign||align
> +allocatrd||allocated
> +allocte||allocate
> +allpication||application
> +alocate||allocate
> +alogirhtms||algorithms
> +alogrithm||algorithm
> +alot||a lot
> +alow||allow
> +alows||allows
> +altough||although
> +alue||value
> +ambigious||ambiguous
> +amoung||among
> +amout||amount
> +analysator||analyzer
> +ang||and
> +anniversery||anniversary
> +annoucement||announcement
> +anomolies||anomalies
> +anomoly||anomaly
> +anway||anyway
> +aplication||application
> +appearence||appearance
> +applicaion||application
> +appliction||application
> +applictions||applications
> +appplications||applications
> +appropiate||appropriate
> +appropriatly||appropriately
> +approriate||appropriate
> +approriately||appropriately
> +aquainted||acquainted
> +aquired||acquired
> +arbitary||arbitrary
> +architechture||architecture
> +arguement||argument
> +arguements||arguments
> +aritmetic||arithmetic
> +arne't||aren't
> +arraival||arrival
> +artifical||artificial
> +artillary||artillery
> +assiged||assigned
> +assigment||assignment
> +assigments||assignments
> +assistent||assistant
> +assocation||association
> +associcated||associated
> +assotiated||associated
> +assum||assume
> +assumtpion||assumption
> +asuming||assuming
> +asycronous||asynchronous
> +asynchnous||asynchronous
> +atomatically||automatically
> +atomicly||atomically
> +attachement||attachment
> +attched||attached
> +attemps||attempts
> +attruibutes||attributes
> +authentification||authentication
> +automaticaly||automatically
> +automaticly||automatically
> +automatize||automate
> +automatized||automated
> +automatizes||automates
> +autonymous||autonomous
> +auxilliary||auxiliary
> +avaiable||available
> +avaible||available
> +availabe||available
> +availabled||available
> +availablity||availability
> +availale||available
> +availavility||availability
> +availble||available
> +availiable||available
> +avalable||available
> +avaliable||available
> +aysnc||async
> +backgroud||background
> +backword||backward
> +backwords||backwards
> +bahavior||behavior
> +bakup||backup
> +baloon||balloon
> +baloons||balloons
> +bandwith||bandwidth
> +batery||battery
> +beacuse||because
> +becasue||because
> +becomming||becoming
> +becuase||because
> +beeing||being
> +befor||before
> +begining||beginning
> +beter||better
> +betweeen||between
> +bianries||binaries
> +bitmast||bitmask
> +boardcast||broadcast
> +borad||board
> +boundry||bou

Re: [lng-odp] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Ola Liljedahl]

On 28 May 2015 at 17:23, Zoltan Kiss  wrote:

>
>
> On 28/05/15 16:00, Ola Liljedahl wrote:
>
>> I disprove of this solution. TX completion processing (cleaning TX
>> descriptor rings after transmission complete) is an implementation
>> (hardware) aspect and should be hidden from the application.
>>
>
> Unfortunately you can't, if you want your pktio application work with poll
> mode drivers. In that case TX completion interrupt (can be) disabled and
> the application has to control that as well. In case of DPDK you just call
> the send function (with 0 packets, if you don't have anything to send at
> the time)

Why do you have to retire transmitted packet if you are not transmitting
new packets (and need those descriptors in the TX ring)? Does the
application have too few packets in the pool so that reception will suffer?


>
>  There isn't
>
>> any corresponding call that refills the RX descriptor rings with fresh
>> buffers.
>>
> You can do that in the receive function, I think that's how the drivers
> are doing it generally.
>
>>
>> The completion processing can be performed from any ODP call, not
>> necessary odp_pktio_send().
>>
>
> I think "any" is not specific enough. Which one?
>
odp_pktio_recv, odp_schedule. Wherever the application blocks or busy waits
waiting for more packets.



> Can you provide a vague draft how would you fix the l2fwd example below?
>
I don't think anything needs fixing on the application level.


>
>> -- Ola
>>
>>
>> On 28 May 2015 at 16:38, Zoltan Kiss > > wrote:
>>
>> A pktio interface can be used with poll mode drivers, where TX
>> completion often
>> has to be done manually. This turned up as a problem with ODP-DPDK and
>> odp_l2fwd:
>>
>> while (!exit_threads) {
>>  pkts = odp_pktio_recv(pktio_src,...);
>>  if (pkts <= 0)
>>  continue;
>> ...
>>  if (pkts_ok > 0)
>>  odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
>> ...
>> }
>>
>> In this example we never call odp_pktio_send() on pktio_dst if there
>> wasn't
>> any new packets received on pktio_src. DPDK needs manual TX
>> completion. The
>> above example should have an odp_pktio_send_completion(pktio_dst)
>> right at the
>> beginning of the loop.
>>
>> Signed-off-by: Zoltan Kiss > >
>>
>> ---
>>   include/odp/api/packet_io.h | 16 
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
>> index b97b2b8..3a4054c 100644
>> --- a/include/odp/api/packet_io.h
>> +++ b/include/odp/api/packet_io.h
>> @@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio,
>> odp_packet_t pkt_table[], int len);
>>   int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
>> int len);
>>
>>   /**
>> + * Release sent packets
>> + *
>> + * This function should be called after sending on a pktio. If the
>> platform
>> + * doesn't implement send completion in other ways, this function
>> should call
>> + * odp_packet_free() on packets where transmission is already
>> completed. It can
>> + * be a no-op if the platform guarantees that the packets will be
>> released upon
>> + * completion, but the application must call it periodically after
>> send to make
>> + * sure packets are released.
>> + *
>> + * @param pktioODP packet IO handle
>> + *
>> + * @retval <0 on failure
>> + */
>> +int odp_pktio_send_complete(odp_pktio_t pktio);
>> +
>> +/**
>>* Set the default input queue to be associated with a pktio handle
>>*
>>* @param pktioODP packet IO handle
>> --
>> 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] [Bug 1513] CID 90143: CHECKED_RETURN: odp_pktio_perf.c

[bugzilla-daemon]

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

Mike Holmes  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mike Holmes  ---
commit b9d0dcb9bee6b8327b92e109faf4366f69899428

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

[lng-odp] [Bug 1534] CID 93517: Null pointer de-references: example/classifier/odp_classifier.c

[bugzilla-daemon]

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

Mike Holmes  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mike Holmes  ---
commit ee80069c2b8e518877a6fd118a66153113416f6f

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

Re: [lng-odp] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Zoltan Kiss]

On 28/05/15 16:00, Ola Liljedahl wrote:

I disprove of this solution. TX completion processing (cleaning TX
descriptor rings after transmission complete) is an implementation
(hardware) aspect and should be hidden from the application.


Unfortunately you can't, if you want your pktio application work with 
poll mode drivers. In that case TX completion interrupt (can be) 
disabled and the application has to control that as well. In case of 
DPDK you just call the send function (with 0 packets, if you don't have 
anything to send at the time)


 There isn't

any corresponding call that refills the RX descriptor rings with fresh
buffers.
You can do that in the receive function, I think that's how the drivers 
are doing it generally.


The completion processing can be performed from any ODP call, not
necessary odp_pktio_send().


I think "any" is not specific enough. Which one?

Can you provide a vague draft how would you fix the l2fwd example below?


-- Ola


On 28 May 2015 at 16:38, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:

A pktio interface can be used with poll mode drivers, where TX
completion often
has to be done manually. This turned up as a problem with ODP-DPDK and
odp_l2fwd:

while (!exit_threads) {
 pkts = odp_pktio_recv(pktio_src,...);
 if (pkts <= 0)
 continue;
...
 if (pkts_ok > 0)
 odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
...
}

In this example we never call odp_pktio_send() on pktio_dst if there
wasn't
any new packets received on pktio_src. DPDK needs manual TX
completion. The
above example should have an odp_pktio_send_completion(pktio_dst)
right at the
beginning of the loop.

Signed-off-by: Zoltan Kiss mailto:zoltan.k...@linaro.org>>
---
  include/odp/api/packet_io.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index b97b2b8..3a4054c 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio,
odp_packet_t pkt_table[], int len);
  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
int len);

  /**
+ * Release sent packets
+ *
+ * This function should be called after sending on a pktio. If the
platform
+ * doesn't implement send completion in other ways, this function
should call
+ * odp_packet_free() on packets where transmission is already
completed. It can
+ * be a no-op if the platform guarantees that the packets will be
released upon
+ * completion, but the application must call it periodically after
send to make
+ * sure packets are released.
+ *
+ * @param pktioODP packet IO handle
+ *
+ * @retval <0 on failure
+ */
+int odp_pktio_send_complete(odp_pktio_t pktio);
+
+/**
   * Set the default input queue to be associated with a pktio handle
   *
   * @param pktioODP packet IO handle
--
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] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Zoltan Kiss]

On 28/05/15 16:00, Mike Holmes wrote:



On 28 May 2015 at 10:38, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:

A pktio interface can be used with poll mode drivers, where TX
completion often
has to be done manually. This turned up as a problem with ODP-DPDK and
odp_l2fwd:

while (!exit_threads) {
 pkts = odp_pktio_recv(pktio_src,...);
 if (pkts <= 0)
 continue;
...
 if (pkts_ok > 0)
 odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
...
}

In this example we never call odp_pktio_send() on pktio_dst if there
wasn't
any new packets received on pktio_src. DPDK needs manual TX
completion. The
above example should have an odp_pktio_send_completion(pktio_dst)
right at the
beginning of the loop.

Signed-off-by: Zoltan Kiss mailto:zoltan.k...@linaro.org>>
---
  include/odp/api/packet_io.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index b97b2b8..3a4054c 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio,
odp_packet_t pkt_table[], int len);
  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
int len);

  /**
+ * Release sent packets
+ *
+ * This function should be called after sending on a pktio. If the
platform
+ * doesn't implement send completion in other ways, this function
should call
+ * odp_packet_free() on packets where transmission is already
completed. It can
+ * be a no-op if the platform guarantees that the packets will be
released upon
+ * completion,


You provide an example of usage above, can it be added between @code and
  @endcode in this documentation for others to see in the rendered docs?


Makes sense.




but the application must call it periodically after send to make
+ * sure packets are released.


This is an important requirement and should be highlighted in the final
doc with @note:-
@note The application must call  odp_pktio_send_complete periodically
after send to make sure packets are released.

Ok


Also is there any guild line on "periodically" is once ok, I assume not,
but I also assume that it is not as frequent as for every send.
The only guideline that it should happen periodically, the period length 
can be arbitrary, but finite. Otherwise it's the applications decision 
what's the most optimal.


The odp_pktio_send  documentation could also do with a reference to
  odp_pktio_send_complete to ensure that readers will know of the
requirement, they may miss it otherwise.

Yes, I want to add a description there later on


+ *
+ * @param pktioODP packet IO handle
+ *
+ * @retval <0 on failure


Are there any specific failures you can define, specifics are nice
things to test in the validation suite to ensure all platforms behave
the same way


I don't have anything in mind, I'm actually not sure if we should return 
anything here. I can't come up with a scenario where releasing a buffer 
should ever fail.




+ */
+int odp_pktio_send_complete(odp_pktio_t pktio);
+
+/**
   * Set the default input queue to be associated with a pktio handle
   *
   * @param pktioODP packet IO handle
--
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

__



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

[lng-odp] [Bug 1337] No means of knowing the size of the CPU mask (odp_cpumask_t)

[bugzilla-daemon]

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

--- Comment #3 from Mike Holmes  ---
Added again to ARCH meeting as agenda item

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

[lng-odp] [Bug 1440] Documentation: odp_pktio_open to mention the pool is only used by the default CoS

[bugzilla-daemon]

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

Mike Holmes  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

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

Re: [lng-odp] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Ola Liljedahl]

I disprove of this solution. TX completion processing (cleaning TX
descriptor rings after transmission complete) is an implementation
(hardware) aspect and should be hidden from the application. There isn't
any corresponding call that refills the RX descriptor rings with fresh
buffers.

The completion processing can be performed from any ODP call, not necessary
odp_pktio_send().

-- Ola


On 28 May 2015 at 16:38, Zoltan Kiss  wrote:

> A pktio interface can be used with poll mode drivers, where TX completion
> often
> has to be done manually. This turned up as a problem with ODP-DPDK and
> odp_l2fwd:
>
> while (!exit_threads) {
> pkts = odp_pktio_recv(pktio_src,...);
> if (pkts <= 0)
> continue;
> ...
> if (pkts_ok > 0)
> odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
> ...
> }
>
> In this example we never call odp_pktio_send() on pktio_dst if there wasn't
> any new packets received on pktio_src. DPDK needs manual TX completion. The
> above example should have an odp_pktio_send_completion(pktio_dst) right at
> the
> beginning of the loop.
>
> Signed-off-by: Zoltan Kiss 
> ---
>  include/odp/api/packet_io.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index b97b2b8..3a4054c 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
> pkt_table[], int len);
>  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int len);
>
>  /**
> + * Release sent packets
> + *
> + * This function should be called after sending on a pktio. If the
> platform
> + * doesn't implement send completion in other ways, this function should
> call
> + * odp_packet_free() on packets where transmission is already completed.
> It can
> + * be a no-op if the platform guarantees that the packets will be
> released upon
> + * completion, but the application must call it periodically after send
> to make
> + * sure packets are released.
> + *
> + * @param pktioODP packet IO handle
> + *
> + * @retval <0 on failure
> + */
> +int odp_pktio_send_complete(odp_pktio_t pktio);
> +
> +/**
>   * Set the default input queue to be associated with a pktio handle
>   *
>   * @param pktioODP packet IO handle
> --
> 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] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Mike Holmes]

On 28 May 2015 at 10:38, Zoltan Kiss  wrote:

> A pktio interface can be used with poll mode drivers, where TX completion
> often
> has to be done manually. This turned up as a problem with ODP-DPDK and
> odp_l2fwd:
>
> while (!exit_threads) {
> pkts = odp_pktio_recv(pktio_src,...);
> if (pkts <= 0)
> continue;
> ...
> if (pkts_ok > 0)
> odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
> ...
> }
>
> In this example we never call odp_pktio_send() on pktio_dst if there wasn't
> any new packets received on pktio_src. DPDK needs manual TX completion. The
> above example should have an odp_pktio_send_completion(pktio_dst) right at
> the
> beginning of the loop.
>
> Signed-off-by: Zoltan Kiss 
> ---
>  include/odp/api/packet_io.h | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index b97b2b8..3a4054c 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
> pkt_table[], int len);
>  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int len);
>
>  /**
> + * Release sent packets
> + *
> + * This function should be called after sending on a pktio. If the
> platform
> + * doesn't implement send completion in other ways, this function should
> call
> + * odp_packet_free() on packets where transmission is already completed.
> It can
> + * be a no-op if the platform guarantees that the packets will be
> released upon
> + * completion,


You provide an example of usage above, can it be added between @code and
 @endcode in this documentation for others to see in the rendered docs?


> but the application must call it periodically after send to make
> + * sure packets are released.
>

This is an important requirement and should be highlighted in the final doc
with @note:-
@note The application must call  odp_pktio_send_complete periodically after
send to make sure packets are released.
Also is there any guild line on "periodically" is once ok, I assume not,
but I also assume that it is not as frequent as for every send.

The odp_pktio_send  documentation could also do with a reference to
 odp_pktio_send_complete to ensure that readers will know of the
requirement, they may miss it otherwise.



> + *
> + * @param pktioODP packet IO handle
> + *
> + * @retval <0 on failure
>

Are there any specific failures you can define, specifics are nice things
to test in the validation suite to ensure all platforms behave the same way


> + */
> +int odp_pktio_send_complete(odp_pktio_t pktio);
> +
> +/**
>   * Set the default input queue to be associated with a pktio handle
>   *
>   * @param pktioODP packet IO handle
> --
> 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
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

[lng-odp] [PATCH] apply-and-build.sh: cosmetic fix

[Christophe Milard]

function apply_patch() now returns a status rather than directely breaking the
loop of its caller. (for loop in main, continue statment in apply_patch())

Signed-off-by: Christophe Milard 
---
 apply-and-build.sh | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/apply-and-build.sh b/apply-and-build.sh
index 683a0b6..bf0300f 100755
--- a/apply-and-build.sh
+++ b/apply-and-build.sh
@@ -170,7 +170,7 @@ apply_patch() {
 git checkout . || exit 1
 git clean -xdf || exit 1
 popd > /dev/null
-continue
+return 1
 else
 #3way apply worked
 echo "  Warning: git am --3way, applied"
@@ -182,7 +182,7 @@ apply_patch() {
 git checkout . || exit 1
 git clean -xdf || exit 1
 popd > /dev/null
-continue
+return 1
 fi
 else
 #patch successfully applied:
@@ -194,6 +194,7 @@ apply_patch() {
 fi
 
 popd > /dev/null
+return 0
 }
 
 format_patch() {
@@ -261,6 +262,10 @@ for patch in $(find $PATCH_DIR -type f -iregex 
"${FILE_EXT_REGEX}" |sort -h); do
 CURRENT_LOG="${ODP_LOGDIR}/$(echo $(basename ${patch}))"
 echo -e "\n\nUsing patch: $(basename ${patch})"
 apply_patch ${ODP_BUILDDIR} ${CURRENT_LOG}
+#if applying the patch failed, take next one:
+if [ $? -ne 0 ]; then
+continue
+fi
 
 format_patch ${ODP_BUILDDIR} ${CURRENT_LOG}
 
-- 
1.9.1

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

Re: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

[Zoltan Kiss]

On 28/05/15 15:32, Ola Liljedahl wrote:

On 28 May 2015 at 16:25, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:

Yes, I missed that prefix. Do you want me to resend the patch?
I'll send an another patch to implement this behaviour in the repo
wherever odp_pktio_send is called. But I think we can't create a
unit test for it, can we?

We can sort-of test that any packets not being consumed by
odp_pktio_send() still are ours and valid (although I think it is
implementation specific whether ODP will detect any violations, e.g.
whether it detects that an application uses a packet handle it does not
"own").

But can we force odp_pktio_send() not to consume all packets passed to
it? This seems less likely.


Yes, that's why I'm concerned if we can test that out somehow.

Zoli





On 28/05/15 14:56, Bill Fischofer wrote:

This needs to be API-NEXT as it is a change to an API file.

On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia -
FI/Espoo)
mailto:petri.savolai...@nokia.com>
>> wrote:

 Reviewed-by: Petri Savolainen mailto:petri.savolai...@nokia.com>
 >>


  > -Original Message-
  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org

 >] On Behalf Of ext
  > Zoltan Kiss
  > Sent: Thursday, May 28, 2015 3:19 PM
  > To: lng-odp@lists.linaro.org

>
  > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what
 happens when
  > not all packets are sent
  >
  > Currently our examples are not handling this situation
as well.
  >
  > Signed-off-by: Zoltan Kiss mailto:zoltan.k...@linaro.org>
 >>
  > ---
  >  include/odp/api/packet_io.h | 4 +++-
  >  1 file changed, 3 insertions(+), 1 deletion(-)
  >
  > diff --git a/include/odp/api/packet_io.h
 b/include/odp/api/packet_io.h
  > index 89356a6..b97b2b8 100644
  > --- a/include/odp/api/packet_io.h
  > +++ b/include/odp/api/packet_io.h
  > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio,
 odp_packet_t
  > pkt_table[], int len);
  >   * @param pkt_table[]  Array of packets to send
  >   * @param len  length of pkt_table[]
  >   *
  > - * @return Number of packets sent
  > + * @return Number of packets sent. If it is less than
'len', the
  > remaining
  > + * packets at the end of pkt_table[] are left intact,
and caller
 has to
  > take
  > + * care of them.
  >   * @retval <0 on failure
  >   */
  >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t
pkt_table[],
 int len);
  > --
  > 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 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] [PATCH] apply-and-build.sh: fixing cover-letter issue

[Christophe Milard]

When an empty patch (such as a cover letter) was given to
apply-and-build, the latter would fail applying the patch and all
following patches (saying OK when it could be wrong)

Signed-off-by: Christophe Milard 
---
 apply-and-build.sh | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/apply-and-build.sh b/apply-and-build.sh
index e41c297..683a0b6 100755
--- a/apply-and-build.sh
+++ b/apply-and-build.sh
@@ -152,26 +152,40 @@ apply_patch() {
 
 echo "  Trying to apply patch"
 git am ${patch} >> ${logfile_basename}-am.log 2>&1
-egrep "^Patch failed at" ${logfile_basename}-am.log > /dev/null
-if [ $? -eq 0 ]; then
+if [ $? -ne 0 ]; then
+#git am is unsuccessfull, because of a apply failure or empty patch
 cat ${logfile_basename}-am.log
-git am --abort || exit 1
-git checkout . || exit 1
-git clean -xdf || exit 1
-git am --3way ${patch} >> ${logfile_basename}-am-3way.log 2>&1
-egrep "^Patch failed at" ${logfile_basename}-am-3way.log > /dev/null
+egrep "^Patch failed at" ${logfile_basename}-am.log > /dev/null
 if [ $? -eq 0 ]; then
-cat ${logfile_basename}-am-3way.log
-echo "  Error: Patch failed to apply"
+#apply failure: clean up and try 3way apply:
 git am --abort || exit 1
 git checkout . || exit 1
 git clean -xdf || exit 1
+git am --3way ${patch} >> ${logfile_basename}-am-3way.log 2>&1
+if [ $? -ne 0 ]; then
+#even 3way apply failed: clean and give up
+cat ${logfile_basename}-am-3way.log
+echo "  Error: Patch failed to apply"
+git am --abort || exit 1
+git checkout . || exit 1
+git clean -xdf || exit 1
+popd > /dev/null
+continue
+else
+#3way apply worked
+echo "  Warning: git am --3way, applied"
+fi
+else
+#git am unsuccessful but no "Patch failed at" in output:
+echo "  Warning: Patch could not apply, but did not fail (empty 
patch? cover-letter?): skipping it..."
+git am --abort #to be on the safe side, but probably unsuccessful.
+git checkout . || exit 1
+git clean -xdf || exit 1
 popd > /dev/null
 continue
-else
-echo "  Warning: git am --3way, applied"
 fi
 else
+#patch successfully applied:
 echo "  Patch applied"
 egrep "^warning:" ${logfile_basename}-am.log > /dev/null
 if [ $? -eq 0 ]; then
-- 
1.9.1

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

[lng-odp] [API-NEXT PATCH] api-next: pktio: add odp_pktio_send_complete() definition

[Zoltan Kiss]

A pktio interface can be used with poll mode drivers, where TX completion often
has to be done manually. This turned up as a problem with ODP-DPDK and
odp_l2fwd:

while (!exit_threads) {
pkts = odp_pktio_recv(pktio_src,...);
if (pkts <= 0)
continue;
...
if (pkts_ok > 0)
odp_pktio_send(pktio_dst, pkt_tbl, pkts_ok);
...
}

In this example we never call odp_pktio_send() on pktio_dst if there wasn't
any new packets received on pktio_src. DPDK needs manual TX completion. The
above example should have an odp_pktio_send_completion(pktio_dst) right at the
beginning of the loop.

Signed-off-by: Zoltan Kiss 
---
 include/odp/api/packet_io.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index b97b2b8..3a4054c 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -119,6 +119,22 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t 
pkt_table[], int len);
 int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int len);
 
 /**
+ * Release sent packets
+ *
+ * This function should be called after sending on a pktio. If the platform
+ * doesn't implement send completion in other ways, this function should call
+ * odp_packet_free() on packets where transmission is already completed. It can
+ * be a no-op if the platform guarantees that the packets will be released upon
+ * completion, but the application must call it periodically after send to make
+ * sure packets are released.
+ *
+ * @param pktioODP packet IO handle
+ *
+ * @retval <0 on failure
+ */
+int odp_pktio_send_complete(odp_pktio_t pktio);
+
+/**
  * Set the default input queue to be associated with a pktio handle
  *
  * @param pktioODP packet IO handle
-- 
1.9.1

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

Re: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

[Ola Liljedahl]

On 28 May 2015 at 16:25, Zoltan Kiss  wrote:

> Yes, I missed that prefix. Do you want me to resend the patch?
> I'll send an another patch to implement this behaviour in the repo
> wherever odp_pktio_send is called. But I think we can't create a unit test
> for it, can we?
>
We can sort-of test that any packets not being consumed by odp_pktio_send()
still are ours and valid (although I think it is implementation specific
whether ODP will detect any violations, e.g. whether it detects that an
application uses a packet handle it does not "own").

But can we force odp_pktio_send() not to consume all packets passed to it?
This seems less likely.



> On 28/05/15 14:56, Bill Fischofer wrote:
>
>> This needs to be API-NEXT as it is a change to an API file.
>>
>> On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo)
>> mailto:petri.savolai...@nokia.com>> wrote:
>>
>> Reviewed-by: Petri Savolainen > >
>>
>>
>>  > -Original Message-
>>  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
>> ] On Behalf Of ext
>>  > Zoltan Kiss
>>  > Sent: Thursday, May 28, 2015 3:19 PM
>>  > To: lng-odp@lists.linaro.org 
>>  > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what
>> happens when
>>  > not all packets are sent
>>  >
>>  > Currently our examples are not handling this situation as well.
>>  >
>>  > Signed-off-by: Zoltan Kiss > >
>>  > ---
>>  >  include/odp/api/packet_io.h | 4 +++-
>>  >  1 file changed, 3 insertions(+), 1 deletion(-)
>>  >
>>  > diff --git a/include/odp/api/packet_io.h
>> b/include/odp/api/packet_io.h
>>  > index 89356a6..b97b2b8 100644
>>  > --- a/include/odp/api/packet_io.h
>>  > +++ b/include/odp/api/packet_io.h
>>  > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio,
>> odp_packet_t
>>  > pkt_table[], int len);
>>  >   * @param pkt_table[]  Array of packets to send
>>  >   * @param len  length of pkt_table[]
>>  >   *
>>  > - * @return Number of packets sent
>>  > + * @return Number of packets sent. If it is less than 'len', the
>>  > remaining
>>  > + * packets at the end of pkt_table[] are left intact, and caller
>> has to
>>  > take
>>  > + * care of them.
>>  >   * @retval <0 on failure
>>  >   */
>>  >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
>> int len);
>>  > --
>>  > 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 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-next: packet_io: clarify what happens when not all packets are sent

[Mike Holmes]

On 28 May 2015 at 10:16, Ola Liljedahl  wrote:

> On 28 May 2015 at 15:56, Bill Fischofer  wrote:
>
>> This needs to be API-NEXT as it is a change to an API file.
>>
> I don't see this as an API change, just as a clarification of what is
> defined/expected behavior.
> I was expecting this behavior already with the current API but I agree
> that it should be spelled out clearly.
>

The rule is that anything that touches "include/odp/api" needs to go via
api-next, it can then be cherry picked into master very quickly. The
other mechanisms we tried left ambiguity in how to handle the patch becasue
api-next and master are currently maintained by Maxim but api-next has
extra rules with Petris signoff.

I think it would be clearer, faster, simpler if we do split api-next to its
own repo and Petri sends pull requests to Maxim every time he is happy for
an odp/api change to go in.


>
>
>
>>
>> On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo) <
>> petri.savolai...@nokia.com> wrote:
>>
>>> Reviewed-by: Petri Savolainen 
>>>
>>>
>>> > -Original Message-
>>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> ext
>>> > Zoltan Kiss
>>> > Sent: Thursday, May 28, 2015 3:19 PM
>>> > To: lng-odp@lists.linaro.org
>>> > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what happens
>>> when
>>> > not all packets are sent
>>> >
>>> > Currently our examples are not handling this situation as well.
>>> >
>>> > Signed-off-by: Zoltan Kiss 
>>> > ---
>>> >  include/odp/api/packet_io.h | 4 +++-
>>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
>>> > index 89356a6..b97b2b8 100644
>>> > --- a/include/odp/api/packet_io.h
>>> > +++ b/include/odp/api/packet_io.h
>>> > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
>>> > pkt_table[], int len);
>>> >   * @param pkt_table[]  Array of packets to send
>>> >   * @param len  length of pkt_table[]
>>> >   *
>>> > - * @return Number of packets sent
>>> > + * @return Number of packets sent. If it is less than 'len', the
>>> > remaining
>>> > + * packets at the end of pkt_table[] are left intact, and caller has
>>> to
>>> > take
>>> > + * care of them.
>>> >   * @retval <0 on failure
>>> >   */
>>> >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int
>>> len);
>>> > --
>>> > 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 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
>
>


-- 
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] api-next: packet_io: clarify what happens when not all packets are sent

[Bill Fischofer]

We agreed that *any* change to the include/odp directory would be flagged
API-NEXT (avoids having to make decisions).  We can then decide which to
cherry-pick into the mainline on an expedited basis for simple things like
documentation only changes, but these would be reviewed on a case-by-case
basis.

On Thu, May 28, 2015 at 9:25 AM, Zoltan Kiss  wrote:

> Yes, I missed that prefix. Do you want me to resend the patch?
> I'll send an another patch to implement this behaviour in the repo
> wherever odp_pktio_send is called. But I think we can't create a unit test
> for it, can we?
>
> On 28/05/15 14:56, Bill Fischofer wrote:
>
>> This needs to be API-NEXT as it is a change to an API file.
>>
>> On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo)
>> mailto:petri.savolai...@nokia.com>> wrote:
>>
>> Reviewed-by: Petri Savolainen > >
>>
>>
>>  > -Original Message-
>>  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
>> ] On Behalf Of ext
>>  > Zoltan Kiss
>>  > Sent: Thursday, May 28, 2015 3:19 PM
>>  > To: lng-odp@lists.linaro.org 
>>  > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what
>> happens when
>>  > not all packets are sent
>>  >
>>  > Currently our examples are not handling this situation as well.
>>  >
>>  > Signed-off-by: Zoltan Kiss > >
>>
>>  > ---
>>  >  include/odp/api/packet_io.h | 4 +++-
>>  >  1 file changed, 3 insertions(+), 1 deletion(-)
>>  >
>>  > diff --git a/include/odp/api/packet_io.h
>> b/include/odp/api/packet_io.h
>>  > index 89356a6..b97b2b8 100644
>>  > --- a/include/odp/api/packet_io.h
>>  > +++ b/include/odp/api/packet_io.h
>>  > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio,
>> odp_packet_t
>>  > pkt_table[], int len);
>>  >   * @param pkt_table[]  Array of packets to send
>>  >   * @param len  length of pkt_table[]
>>  >   *
>>  > - * @return Number of packets sent
>>  > + * @return Number of packets sent. If it is less than 'len', the
>>  > remaining
>>  > + * packets at the end of pkt_table[] are left intact, and caller
>> has to
>>  > take
>>  > + * care of them.
>>  >   * @retval <0 on failure
>>  >   */
>>  >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
>> int len);
>>  > --
>>  > 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

[Zoltan Kiss]

Yes, I missed that prefix. Do you want me to resend the patch?
I'll send an another patch to implement this behaviour in the repo 
wherever odp_pktio_send is called. But I think we can't create a unit 
test for it, can we?


On 28/05/15 14:56, Bill Fischofer wrote:

This needs to be API-NEXT as it is a change to an API file.

On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo)
mailto:petri.savolai...@nokia.com>> wrote:

Reviewed-by: Petri Savolainen mailto:petri.savolai...@nokia.com>>


 > -Original Message-
 > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
] On Behalf Of ext
 > Zoltan Kiss
 > Sent: Thursday, May 28, 2015 3:19 PM
 > To: lng-odp@lists.linaro.org 
 > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what
happens when
 > not all packets are sent
 >
 > Currently our examples are not handling this situation as well.
 >
 > Signed-off-by: Zoltan Kiss mailto:zoltan.k...@linaro.org>>
 > ---
 >  include/odp/api/packet_io.h | 4 +++-
 >  1 file changed, 3 insertions(+), 1 deletion(-)
 >
 > diff --git a/include/odp/api/packet_io.h
b/include/odp/api/packet_io.h
 > index 89356a6..b97b2b8 100644
 > --- a/include/odp/api/packet_io.h
 > +++ b/include/odp/api/packet_io.h
 > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio,
odp_packet_t
 > pkt_table[], int len);
 >   * @param pkt_table[]  Array of packets to send
 >   * @param len  length of pkt_table[]
 >   *
 > - * @return Number of packets sent
 > + * @return Number of packets sent. If it is less than 'len', the
 > remaining
 > + * packets at the end of pkt_table[] are left intact, and caller
has to
 > take
 > + * care of them.
 >   * @retval <0 on failure
 >   */
 >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[],
int len);
 > --
 > 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

[Ola Liljedahl]

On 28 May 2015 at 15:56, Bill Fischofer  wrote:

> This needs to be API-NEXT as it is a change to an API file.
>
I don't see this as an API change, just as a clarification of what is
defined/expected behavior.
I was expecting this behavior already with the current API but I agree that
it should be spelled out clearly.



>
> On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo) <
> petri.savolai...@nokia.com> wrote:
>
>> Reviewed-by: Petri Savolainen 
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> ext
>> > Zoltan Kiss
>> > Sent: Thursday, May 28, 2015 3:19 PM
>> > To: lng-odp@lists.linaro.org
>> > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what happens
>> when
>> > not all packets are sent
>> >
>> > Currently our examples are not handling this situation as well.
>> >
>> > Signed-off-by: Zoltan Kiss 
>> > ---
>> >  include/odp/api/packet_io.h | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
>> > index 89356a6..b97b2b8 100644
>> > --- a/include/odp/api/packet_io.h
>> > +++ b/include/odp/api/packet_io.h
>> > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
>> > pkt_table[], int len);
>> >   * @param pkt_table[]  Array of packets to send
>> >   * @param len  length of pkt_table[]
>> >   *
>> > - * @return Number of packets sent
>> > + * @return Number of packets sent. If it is less than 'len', the
>> > remaining
>> > + * packets at the end of pkt_table[] are left intact, and caller has to
>> > take
>> > + * care of them.
>> >   * @retval <0 on failure
>> >   */
>> >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int
>> len);
>> > --
>> > 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 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 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

[Ola Liljedahl]

On 28 May 2015 at 14:58, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> How people think 0 is special or different from e.g. value 1?
>
A packet of length 1 will require at least one segment.
A packet of length 0 does not require any segment from a formal point of
view (but an implementation will probably allocate a segment anyway).

So implementations might implement  zer0 length packets differently. The
question is how this can be observed by applications. Preferably not at
all. But it seems like implementation specifics are leaking out and some
code might expect a certain behavior which is not mandated by the API. We
want to avoid this and think we can achieve it by amending the API
documentation. I also think the validation suite might need some specific
test cases here.


> We can change documentation wording, but not add lengthy documentation for
> value 0 as a special case (which is not).
>
> -Petri
>
>
> > -Original Message-
> > From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> > Sent: Thursday, May 28, 2015 3:51 PM
> > To: Savolainen, Petri (Nokia - FI/Espoo); ext Bill Fischofer
> > Cc: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
> > of 0 len on odp_packet_alloc()
> >
> > I don't think so. There was a lengthy discussion on the arch meeting how
> > should you interpret that, I think that proves it's worth to clarify
> > what's the expected behaviour.
> >
> > On 28/05/15 13:45, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > > I think it should be enough to note that len can be 0. There’s no
> > > special handling for value zero.
> > >
> > > -Petri
> > >
> > > *From:*ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
> > > *Sent:* Thursday, May 28, 2015 2:48 PM
> > > *To:* Savolainen, Petri (Nokia - FI/Espoo)
> > > *Cc:* lng-odp@lists.linaro.org
> > > *Subject:* Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify
> > > use of 0 len on odp_packet_alloc()
> > >
> > > The purpose of the note was to expand on the case of len = 0.  Are you
> > > saying this is not needed?  The consensus on the Wednesday arch call
> was
> > > that it was, hence this patch.
> > >
> > > On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo)
> > > mailto:petri.savolai...@nokia.com>>
> wrote:
> > >
> > >
> > >   * ... The
> > >   * packet is initialized with data pointers and lengths set according
> > > to the
> > >   * specified len, ...
> > >
> > > The current documentation covers functionality also when len is 0. We
> > > should minimize @note content over all the APIs, otherwise the actual
> > > API spec gets fragmented. API documentation and functionality is the
> > > same for len == 0, len == 1, ... In all the cases, implementation
> > > decides on packet segmentation in limits of pool parameters.
> > >
> > > If needed, we could add:
> > >
> > > @note Zero is a valid 'len' value
> > >
> > >
> > > -Petri
> > >
> > >
> > >
> > >  > -Original Message-
> > >  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
> > > ] On Behalf Of ext
> > >  > Bill Fischofer
> > >  > Sent: Wednesday, May 27, 2015 6:51 PM
> > >  > To: lng-odp@lists.linaro.org 
> > >  > Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify
> use
> > > of 0
> > >  > len on odp_packet_alloc()
> > >  >
> > >  > Signed-off-by: Bill Fischofer  > > >
> > >  > ---
> > >  >  include/odp/api/packet.h | 10 ++
> > >  >  1 file changed, 10 insertions(+)
> > >  >
> > >  > diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> > >  > index 3a454b5..ea124df 100644
> > >  > --- a/include/odp/api/packet.h
> > >  > +++ b/include/odp/api/packet.h
> > >  > @@ -73,6 +73,16 @@ extern "C" {
> > >  >   * @note The default headroom and tailroom used for packets is
> > specified
> > >  > by
> > >  >   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM
> > defines
> > >  > in
> > >  >   * odp_config.h.
> > >  > + *
> > >  > + * @note The len parameter sets the initial length of the allocated
> > >  > packet.
> > >  > + * If specified as 0, the implementation will allocate a packet of
> a
> > >  > default
> > >  > + * length chosen by the implementation based on the pool create
> > >  > parameters
> > >  > + * and will then set the actual length of the packet to 0. The
> > result is
> > >  > + * the same as if the following sequence had been called by the
> > >  > application:
> > >  > + * @code
> > >  > + * pkt = odp_packet_alloc(pool, default_len);
> > >  > + * odp_packet_reset(pkt, 0);
> > >  > + * @endcode
> > >  >   */
> > >  >  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
> > >  >
> > >  > --
> > >  > 2.1.0
> > >  >
> > >
> > >  > ___
> > >  > lng-odp mailing list
> > >  > lng-odp@lists.linaro.org 

Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

[Zoltan Kiss]

On 28/05/15 13:58, Savolainen, Petri (Nokia - FI/Espoo) wrote:

How people think 0 is special or different from e.g. value 1?


Well, 0 is a special number in many ways, not just in mathematics and 
computer science:


http://en.wikipedia.org/wiki/0_%28number%29

It is special in this case as well, because it's defined to be equal to:

pkt = odp_packet_alloc(pool, default_len);
odp_packet_reset(pkt, 0);

Which is not necessarily what you would expect. Most people had 
different ideas what 0 should mean.




We can change documentation wording, but not add lengthy documentation for 
value 0 as a special case (which is not).

-Petri



-Original Message-
From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
Sent: Thursday, May 28, 2015 3:51 PM
To: Savolainen, Petri (Nokia - FI/Espoo); ext Bill Fischofer
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
of 0 len on odp_packet_alloc()

I don't think so. There was a lengthy discussion on the arch meeting how
should you interpret that, I think that proves it's worth to clarify
what's the expected behaviour.

On 28/05/15 13:45, Savolainen, Petri (Nokia - FI/Espoo) wrote:

I think it should be enough to note that len can be 0. There’s no
special handling for value zero.

-Petri

*From:*ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
*Sent:* Thursday, May 28, 2015 2:48 PM
*To:* Savolainen, Petri (Nokia - FI/Espoo)
*Cc:* lng-odp@lists.linaro.org
*Subject:* Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify
use of 0 len on odp_packet_alloc()

The purpose of the note was to expand on the case of len = 0.  Are you
saying this is not needed?  The consensus on the Wednesday arch call was
that it was, hence this patch.

On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo)
mailto:petri.savolai...@nokia.com>> wrote:


   * ... The
   * packet is initialized with data pointers and lengths set according
to the
   * specified len, ...

The current documentation covers functionality also when len is 0. We
should minimize @note content over all the APIs, otherwise the actual
API spec gets fragmented. API documentation and functionality is the
same for len == 0, len == 1, ... In all the cases, implementation
decides on packet segmentation in limits of pool parameters.

If needed, we could add:

@note Zero is a valid 'len' value


-Petri



  > -Original Message-
  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
] On Behalf Of ext
  > Bill Fischofer
  > Sent: Wednesday, May 27, 2015 6:51 PM
  > To: lng-odp@lists.linaro.org 
  > Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
of 0
  > len on odp_packet_alloc()
  >
  > Signed-off-by: Bill Fischofer mailto:bill.fischo...@linaro.org>>
  > ---
  >  include/odp/api/packet.h | 10 ++
  >  1 file changed, 10 insertions(+)
  >
  > diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
  > index 3a454b5..ea124df 100644
  > --- a/include/odp/api/packet.h
  > +++ b/include/odp/api/packet.h
  > @@ -73,6 +73,16 @@ extern "C" {
  >   * @note The default headroom and tailroom used for packets is

specified

  > by
  >   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM

defines

  > in
  >   * odp_config.h.
  > + *
  > + * @note The len parameter sets the initial length of the allocated
  > packet.
  > + * If specified as 0, the implementation will allocate a packet of a
  > default
  > + * length chosen by the implementation based on the pool create
  > parameters
  > + * and will then set the actual length of the packet to 0. The

result is

  > + * the same as if the following sequence had been called by the
  > application:
  > + * @code
  > + * pkt = odp_packet_alloc(pool, default_len);
  > + * odp_packet_reset(pkt, 0);
  > + * @endcode
  >   */
  >  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
  >
  > --
  > 2.1.0
  >

  > ___
  > 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] api-next: packet_io: clarify what happens when not all packets are sent

[Bill Fischofer]

This needs to be API-NEXT as it is a change to an API file.

On Thu, May 28, 2015 at 7:53 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Reviewed-by: Petri Savolainen 
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> > Zoltan Kiss
> > Sent: Thursday, May 28, 2015 3:19 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when
> > not all packets are sent
> >
> > Currently our examples are not handling this situation as well.
> >
> > Signed-off-by: Zoltan Kiss 
> > ---
> >  include/odp/api/packet_io.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> > index 89356a6..b97b2b8 100644
> > --- a/include/odp/api/packet_io.h
> > +++ b/include/odp/api/packet_io.h
> > @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
> > pkt_table[], int len);
> >   * @param pkt_table[]  Array of packets to send
> >   * @param len  length of pkt_table[]
> >   *
> > - * @return Number of packets sent
> > + * @return Number of packets sent. If it is less than 'len', the
> > remaining
> > + * packets at the end of pkt_table[] are left intact, and caller has to
> > take
> > + * care of them.
> >   * @retval <0 on failure
> >   */
> >  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int
> len);
> > --
> > 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 mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] Fwd: [PATCH 1/3] example: classifier: remove extra local init

[Mike Holmes]

Merged

On 28 May 2015 at 09:36, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>  It will be another patch.
>
>
>
> -Petri
>
>
>
> *From:* ext Mike Holmes [mailto:mike.hol...@linaro.org]
> *Sent:* Thursday, May 28, 2015 4:29 PM
> *To:* Bala Manoharan
> *Cc:* Maxim Uvarov; LNG ODP Mailman List; Savolainen, Petri (Nokia -
> FI/Espoo)
> *Subject:* Re: [lng-odp] Fwd: [PATCH 1/3] example: classifier: remove
> extra local init
>
>
>
> Is the referenced documentation change in progress ? I think the confusion
> may have been that it was going to be added to this patch and then no one
> followed up.
>
>
>
> I will merge it now.
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
> On 28 May 2015 at 09:05, Bala Manoharan  wrote:
>
> Hi Maxim,
>
> This patch from Petri fixes an issue in classifier example and I had
> sent my Reviewed-by for the same.
> Can you please merge this patch.
>
> Regards,
> Bala
>
>
> -- Forwarded message --
> From: Savolainen, Petri (Nokia - FI/Espoo) 
> Date: 7 May 2015 at 18:54
> Subject: RE: [lng-odp] [PATCH 1/3] example: classifier: remove extra local
> init
> To: ext Bala Manoharan 
> Cc: LNG ODP Mailman List 
>
>
> I noticed the same and will add that documentation.
>
>
>
> -Petri
>
>
>
> From: ext Bala Manoharan [mailto:bala.manoha...@linaro.org]
> Sent: Thursday, May 07, 2015 3:49 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH 1/3] example: classifier: remove extra local
> init
>
>
>
> Reviewed-by: Balasubramanian Manoharan 
>
> IMO, we can add additional information in odph_linux_pthread_create()
> header file documentation that this function is expected to call
> odp_init_local() for the thread it creates. Current documentation only
> says the following
>
> /**
>  * Creates and launches pthreads
>  *
>  * Creates, pins and launches threads to separate CPU's based on the
> cpumask.
>  *
>  * @param thread_tblThread table
>  * @param mask  CPU mask
>  * @param start_routine Thread start function
>  * @param arg   Thread argument
>  */
> void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
>const odp_cpumask_t *mask,
>void *(*start_routine) (void *), void *arg);
>
> Regards,
>
> Bala
>
>
>
> On 7 May 2015 at 17:04, Petri Savolainen 
> wrote:
>
> Worker threads are created with odph_linux_pthread_create()
> which calls odp_local_init() before entering the function.
>
> Signed-off-by: Petri Savolainen 
> ---
>  example/classifier/odp_classifier.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/example/classifier/odp_classifier.c
> b/example/classifier/odp_classifier.c
> index d78eb7b..35d9684 100644
> --- a/example/classifier/odp_classifier.c
> +++ b/example/classifier/odp_classifier.c
> @@ -249,13 +249,6 @@ static void *pktio_receive_thread(void *arg)
> appl_args_t *appl = (appl_args_t *)arg;
> global_statistics *stats;
>
> -
> -   /* Init this thread */
> -   if (odp_init_local()) {
> -   EXAMPLE_ERR("ODP thread local init failed.\n");
> -   exit(EXIT_FAILURE);
> -   }
> -
> /* Loop packets */
> for (;;) {
> odp_pktio_t pktio_tmp;
> --
> 2.4.0
>
> ___
> 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
>
>
>
>
>
> --
>
> Mike Holmes
>
> Technical Manager - Linaro Networking Group
>
> Linaro.org  *│ *Open source software for ARM SoCs
>
>
>



-- 
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] Fwd: [PATCH 1/3] example: classifier: remove extra local init

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

It will be another patch.

-Petri

From: ext Mike Holmes [mailto:mike.hol...@linaro.org]
Sent: Thursday, May 28, 2015 4:29 PM
To: Bala Manoharan
Cc: Maxim Uvarov; LNG ODP Mailman List; Savolainen, Petri (Nokia - FI/Espoo)
Subject: Re: [lng-odp] Fwd: [PATCH 1/3] example: classifier: remove extra local 
init

Is the referenced documentation change in progress ? I think the confusion may 
have been that it was going to be added to this patch and then no one followed 
up.

I will merge it now.

Mike





On 28 May 2015 at 09:05, Bala Manoharan 
mailto:bala.manoha...@linaro.org>> wrote:
Hi Maxim,

This patch from Petri fixes an issue in classifier example and I had
sent my Reviewed-by for the same.
Can you please merge this patch.

Regards,
Bala

-- Forwarded message --
From: Savolainen, Petri (Nokia - FI/Espoo) 
mailto:petri.savolai...@nokia.com>>
Date: 7 May 2015 at 18:54
Subject: RE: [lng-odp] [PATCH 1/3] example: classifier: remove extra local init
To: ext Bala Manoharan 
mailto:bala.manoha...@linaro.org>>
Cc: LNG ODP Mailman List 
mailto:lng-odp@lists.linaro.org>>


I noticed the same and will add that documentation.



-Petri



From: ext Bala Manoharan 
[mailto:bala.manoha...@linaro.org]
Sent: Thursday, May 07, 2015 3:49 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH 1/3] example: classifier: remove extra local init



Reviewed-by: Balasubramanian Manoharan 
mailto:bala.manoha...@linaro.org>>

IMO, we can add additional information in odph_linux_pthread_create()
header file documentation that this function is expected to call
odp_init_local() for the thread it creates. Current documentation only
says the following

/**
 * Creates and launches pthreads
 *
 * Creates, pins and launches threads to separate CPU's based on the cpumask.
 *
 * @param thread_tblThread table
 * @param mask  CPU mask
 * @param start_routine Thread start function
 * @param arg   Thread argument
 */
void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
   const odp_cpumask_t *mask,
   void *(*start_routine) (void *), void *arg);

Regards,

Bala



On 7 May 2015 at 17:04, Petri Savolainen 
mailto:petri.savolai...@nokia.com>> wrote:

Worker threads are created with odph_linux_pthread_create()
which calls odp_local_init() before entering the function.

Signed-off-by: Petri Savolainen 
mailto:petri.savolai...@nokia.com>>
---
 example/classifier/odp_classifier.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/example/classifier/odp_classifier.c
b/example/classifier/odp_classifier.c
index d78eb7b..35d9684 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -249,13 +249,6 @@ static void *pktio_receive_thread(void *arg)
appl_args_t *appl = (appl_args_t *)arg;
global_statistics *stats;

-
-   /* Init this thread */
-   if (odp_init_local()) {
-   EXAMPLE_ERR("ODP thread local init failed.\n");
-   exit(EXIT_FAILURE);
-   }
-
/* Loop packets */
for (;;) {
odp_pktio_t pktio_tmp;
--
2.4.0

___
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



--
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] Fwd: [PATCH 1/3] example: classifier: remove extra local init

[Mike Holmes]

Is the referenced documentation change in progress ? I think the confusion
may have been that it was going to be added to this patch and then no one
followed up.

I will merge it now.

Mike





On 28 May 2015 at 09:05, Bala Manoharan  wrote:

> Hi Maxim,
>
> This patch from Petri fixes an issue in classifier example and I had
> sent my Reviewed-by for the same.
> Can you please merge this patch.
>
> Regards,
> Bala
>
> -- Forwarded message --
> From: Savolainen, Petri (Nokia - FI/Espoo) 
> Date: 7 May 2015 at 18:54
> Subject: RE: [lng-odp] [PATCH 1/3] example: classifier: remove extra local
> init
> To: ext Bala Manoharan 
> Cc: LNG ODP Mailman List 
>
>
> I noticed the same and will add that documentation.
>
>
>
> -Petri
>
>
>
> From: ext Bala Manoharan [mailto:bala.manoha...@linaro.org]
> Sent: Thursday, May 07, 2015 3:49 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH 1/3] example: classifier: remove extra local
> init
>
>
>
> Reviewed-by: Balasubramanian Manoharan 
>
> IMO, we can add additional information in odph_linux_pthread_create()
> header file documentation that this function is expected to call
> odp_init_local() for the thread it creates. Current documentation only
> says the following
>
> /**
>  * Creates and launches pthreads
>  *
>  * Creates, pins and launches threads to separate CPU's based on the
> cpumask.
>  *
>  * @param thread_tblThread table
>  * @param mask  CPU mask
>  * @param start_routine Thread start function
>  * @param arg   Thread argument
>  */
> void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
>const odp_cpumask_t *mask,
>void *(*start_routine) (void *), void *arg);
>
> Regards,
>
> Bala
>
>
>
> On 7 May 2015 at 17:04, Petri Savolainen 
> wrote:
>
> Worker threads are created with odph_linux_pthread_create()
> which calls odp_local_init() before entering the function.
>
> Signed-off-by: Petri Savolainen 
> ---
>  example/classifier/odp_classifier.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/example/classifier/odp_classifier.c
> b/example/classifier/odp_classifier.c
> index d78eb7b..35d9684 100644
> --- a/example/classifier/odp_classifier.c
> +++ b/example/classifier/odp_classifier.c
> @@ -249,13 +249,6 @@ static void *pktio_receive_thread(void *arg)
> appl_args_t *appl = (appl_args_t *)arg;
> global_statistics *stats;
>
> -
> -   /* Init this thread */
> -   if (odp_init_local()) {
> -   EXAMPLE_ERR("ODP thread local init failed.\n");
> -   exit(EXIT_FAILURE);
> -   }
> -
> /* Loop packets */
> for (;;) {
> odp_pktio_t pktio_tmp;
> --
> 2.4.0
>
> ___
> 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
>



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

[lng-odp] Fwd: [PATCH 1/3] example: classifier: remove extra local init

[Bala Manoharan]

Hi Maxim,

This patch from Petri fixes an issue in classifier example and I had
sent my Reviewed-by for the same.
Can you please merge this patch.

Regards,
Bala

-- Forwarded message --
From: Savolainen, Petri (Nokia - FI/Espoo) 
Date: 7 May 2015 at 18:54
Subject: RE: [lng-odp] [PATCH 1/3] example: classifier: remove extra local init
To: ext Bala Manoharan 
Cc: LNG ODP Mailman List 


I noticed the same and will add that documentation.



-Petri



From: ext Bala Manoharan [mailto:bala.manoha...@linaro.org]
Sent: Thursday, May 07, 2015 3:49 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH 1/3] example: classifier: remove extra local init



Reviewed-by: Balasubramanian Manoharan 

IMO, we can add additional information in odph_linux_pthread_create()
header file documentation that this function is expected to call
odp_init_local() for the thread it creates. Current documentation only
says the following

/**
 * Creates and launches pthreads
 *
 * Creates, pins and launches threads to separate CPU's based on the cpumask.
 *
 * @param thread_tblThread table
 * @param mask  CPU mask
 * @param start_routine Thread start function
 * @param arg   Thread argument
 */
void odph_linux_pthread_create(odph_linux_pthread_t *thread_tbl,
   const odp_cpumask_t *mask,
   void *(*start_routine) (void *), void *arg);

Regards,

Bala



On 7 May 2015 at 17:04, Petri Savolainen  wrote:

Worker threads are created with odph_linux_pthread_create()
which calls odp_local_init() before entering the function.

Signed-off-by: Petri Savolainen 
---
 example/classifier/odp_classifier.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/example/classifier/odp_classifier.c
b/example/classifier/odp_classifier.c
index d78eb7b..35d9684 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -249,13 +249,6 @@ static void *pktio_receive_thread(void *arg)
appl_args_t *appl = (appl_args_t *)arg;
global_statistics *stats;

-
-   /* Init this thread */
-   if (odp_init_local()) {
-   EXAMPLE_ERR("ODP thread local init failed.\n");
-   exit(EXIT_FAILURE);
-   }
-
/* Loop packets */
for (;;) {
odp_pktio_t pktio_tmp;
--
2.4.0

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

Re: [lng-odp] odp_classifier issue

[Bala Manoharan]

Yes. I am also searching this patch in the repo.
Looks like the patch from Petri has been missed.

Regards,
Bala

On 28 May 2015 at 18:31, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
> I send a patch that corrected this, but not sure what happened to it.
>
>
>
> -Petri
>
>
>
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Radu-Andrei Bulie
> Sent: Thursday, May 28, 2015 3:54 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] odp_classifier issue
>
>
>
> Hi,
>
>
>
> There is a problem in the odp_classifier demo application. Each time an
> odp_thread is created,  inside the thread function an odp_init_local is done
>
> which is not ok.  Init_local is already done in the odp_thread helper,  when
> a thread is created,  so there is no need in calling again odp_init_local on
> the
>
> existing thread.
>
>
>
> Regards,
>
>
>
> Radu
>
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] odp_classifier issue

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

I send a patch that corrected this, but not sure what happened to it.

-Petri

From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext 
Radu-Andrei Bulie
Sent: Thursday, May 28, 2015 3:54 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] odp_classifier issue

Hi,

There is a problem in the odp_classifier demo application. Each time an 
odp_thread is created,  inside the thread function an odp_init_local is done
which is not ok.  Init_local is already done in the odp_thread helper,  when a 
thread is created,  so there is no need in calling again odp_init_local on the
existing thread.

Regards,

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

Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

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

How people think 0 is special or different from e.g. value 1?

We can change documentation wording, but not add lengthy documentation for 
value 0 as a special case (which is not).

-Petri 


> -Original Message-
> From: ext Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> Sent: Thursday, May 28, 2015 3:51 PM
> To: Savolainen, Petri (Nokia - FI/Espoo); ext Bill Fischofer
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
> of 0 len on odp_packet_alloc()
> 
> I don't think so. There was a lengthy discussion on the arch meeting how
> should you interpret that, I think that proves it's worth to clarify
> what's the expected behaviour.
> 
> On 28/05/15 13:45, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> > I think it should be enough to note that len can be 0. There’s no
> > special handling for value zero.
> >
> > -Petri
> >
> > *From:*ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
> > *Sent:* Thursday, May 28, 2015 2:48 PM
> > *To:* Savolainen, Petri (Nokia - FI/Espoo)
> > *Cc:* lng-odp@lists.linaro.org
> > *Subject:* Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify
> > use of 0 len on odp_packet_alloc()
> >
> > The purpose of the note was to expand on the case of len = 0.  Are you
> > saying this is not needed?  The consensus on the Wednesday arch call was
> > that it was, hence this patch.
> >
> > On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo)
> > mailto:petri.savolai...@nokia.com>> wrote:
> >
> >
> >   * ... The
> >   * packet is initialized with data pointers and lengths set according
> > to the
> >   * specified len, ...
> >
> > The current documentation covers functionality also when len is 0. We
> > should minimize @note content over all the APIs, otherwise the actual
> > API spec gets fragmented. API documentation and functionality is the
> > same for len == 0, len == 1, ... In all the cases, implementation
> > decides on packet segmentation in limits of pool parameters.
> >
> > If needed, we could add:
> >
> > @note Zero is a valid 'len' value
> >
> >
> > -Petri
> >
> >
> >
> >  > -Original Message-
> >  > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
> > ] On Behalf Of ext
> >  > Bill Fischofer
> >  > Sent: Wednesday, May 27, 2015 6:51 PM
> >  > To: lng-odp@lists.linaro.org 
> >  > Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
> > of 0
> >  > len on odp_packet_alloc()
> >  >
> >  > Signed-off-by: Bill Fischofer  > >
> >  > ---
> >  >  include/odp/api/packet.h | 10 ++
> >  >  1 file changed, 10 insertions(+)
> >  >
> >  > diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> >  > index 3a454b5..ea124df 100644
> >  > --- a/include/odp/api/packet.h
> >  > +++ b/include/odp/api/packet.h
> >  > @@ -73,6 +73,16 @@ extern "C" {
> >  >   * @note The default headroom and tailroom used for packets is
> specified
> >  > by
> >  >   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM
> defines
> >  > in
> >  >   * odp_config.h.
> >  > + *
> >  > + * @note The len parameter sets the initial length of the allocated
> >  > packet.
> >  > + * If specified as 0, the implementation will allocate a packet of a
> >  > default
> >  > + * length chosen by the implementation based on the pool create
> >  > parameters
> >  > + * and will then set the actual length of the packet to 0. The
> result is
> >  > + * the same as if the following sequence had been called by the
> >  > application:
> >  > + * @code
> >  > + * pkt = odp_packet_alloc(pool, default_len);
> >  > + * odp_packet_reset(pkt, 0);
> >  > + * @endcode
> >  >   */
> >  >  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
> >  >
> >  > --
> >  > 2.1.0
> >  >
> >
> >  > ___
> >  > 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] odp_classifier issue

[Radu-Andrei Bulie]

Hi,

There is a problem in the odp_classifier demo application. Each time an 
odp_thread is created,  inside the thread function an odp_init_local is done
which is not ok.  Init_local is already done in the odp_thread helper,  when a 
thread is created,  so there is no need in calling again odp_init_local on the
existing thread.

Regards,

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

Re: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

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

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Zoltan Kiss
> Sent: Thursday, May 28, 2015 3:19 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] api-next: packet_io: clarify what happens when
> not all packets are sent
> 
> Currently our examples are not handling this situation as well.
> 
> Signed-off-by: Zoltan Kiss 
> ---
>  include/odp/api/packet_io.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index 89356a6..b97b2b8 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t
> pkt_table[], int len);
>   * @param pkt_table[]  Array of packets to send
>   * @param len  length of pkt_table[]
>   *
> - * @return Number of packets sent
> + * @return Number of packets sent. If it is less than 'len', the
> remaining
> + * packets at the end of pkt_table[] are left intact, and caller has to
> take
> + * care of them.
>   * @retval <0 on failure
>   */
>  int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int len);
> --
> 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] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

[Zoltan Kiss]

I don't think so. There was a lengthy discussion on the arch meeting how 
should you interpret that, I think that proves it's worth to clarify 
what's the expected behaviour.


On 28/05/15 13:45, Savolainen, Petri (Nokia - FI/Espoo) wrote:

I think it should be enough to note that len can be 0. There’s no
special handling for value zero.

-Petri

*From:*ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
*Sent:* Thursday, May 28, 2015 2:48 PM
*To:* Savolainen, Petri (Nokia - FI/Espoo)
*Cc:* lng-odp@lists.linaro.org
*Subject:* Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify
use of 0 len on odp_packet_alloc()

The purpose of the note was to expand on the case of len = 0.  Are you
saying this is not needed?  The consensus on the Wednesday arch call was
that it was, hence this patch.

On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo)
mailto:petri.savolai...@nokia.com>> wrote:


  * ... The
  * packet is initialized with data pointers and lengths set according
to the
  * specified len, ...

The current documentation covers functionality also when len is 0. We
should minimize @note content over all the APIs, otherwise the actual
API spec gets fragmented. API documentation and functionality is the
same for len == 0, len == 1, ... In all the cases, implementation
decides on packet segmentation in limits of pool parameters.

If needed, we could add:

@note Zero is a valid 'len' value


-Petri



 > -Original Message-
 > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org
] On Behalf Of ext
 > Bill Fischofer
 > Sent: Wednesday, May 27, 2015 6:51 PM
 > To: lng-odp@lists.linaro.org 
 > Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use
of 0
 > len on odp_packet_alloc()
 >
 > Signed-off-by: Bill Fischofer mailto:bill.fischo...@linaro.org>>
 > ---
 >  include/odp/api/packet.h | 10 ++
 >  1 file changed, 10 insertions(+)
 >
 > diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
 > index 3a454b5..ea124df 100644
 > --- a/include/odp/api/packet.h
 > +++ b/include/odp/api/packet.h
 > @@ -73,6 +73,16 @@ extern "C" {
 >   * @note The default headroom and tailroom used for packets is specified
 > by
 >   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM defines
 > in
 >   * odp_config.h.
 > + *
 > + * @note The len parameter sets the initial length of the allocated
 > packet.
 > + * If specified as 0, the implementation will allocate a packet of a
 > default
 > + * length chosen by the implementation based on the pool create
 > parameters
 > + * and will then set the actual length of the packet to 0. The result is
 > + * the same as if the following sequence had been called by the
 > application:
 > + * @code
 > + * pkt = odp_packet_alloc(pool, default_len);
 > + * odp_packet_reset(pkt, 0);
 > + * @endcode
 >   */
 >  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
 >
 > --
 > 2.1.0
 >

 > ___
 > 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 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

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

I think it should be enough to note that len can be 0. There’s no special 
handling for value zero.

-Petri


From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Thursday, May 28, 2015 2:48 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 
len on odp_packet_alloc()

The purpose of the note was to expand on the case of len = 0.  Are you saying 
this is not needed?  The consensus on the Wednesday arch call was that it was, 
hence this patch.

On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo) 
mailto:petri.savolai...@nokia.com>> wrote:

 * ... The
 * packet is initialized with data pointers and lengths set according to the
 * specified len, ...

The current documentation covers functionality also when len is 0. We should 
minimize @note content over all the APIs, otherwise the actual API spec gets 
fragmented. API documentation and functionality is the same for len == 0, len 
== 1, ... In all the cases, implementation decides on packet segmentation in 
limits of pool parameters.

If needed, we could add:

@note Zero is a valid 'len' value


-Petri


> -Original Message-
> From: lng-odp 
> [mailto:lng-odp-boun...@lists.linaro.org]
>  On Behalf Of ext
> Bill Fischofer
> Sent: Wednesday, May 27, 2015 6:51 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0
> len on odp_packet_alloc()
>
> Signed-off-by: Bill Fischofer 
> mailto:bill.fischo...@linaro.org>>
> ---
>  include/odp/api/packet.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 3a454b5..ea124df 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -73,6 +73,16 @@ extern "C" {
>   * @note The default headroom and tailroom used for packets is specified
> by
>   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM defines
> in
>   * odp_config.h.
> + *
> + * @note The len parameter sets the initial length of the allocated
> packet.
> + * If specified as 0, the implementation will allocate a packet of a
> default
> + * length chosen by the implementation based on the pool create
> parameters
> + * and will then set the actual length of the packet to 0. The result is
> + * the same as if the following sequence had been called by the
> application:
> + * @code
> + * pkt = odp_packet_alloc(pool, default_len);
> + * odp_packet_reset(pkt, 0);
> + * @endcode
>   */
>  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
>
> --
> 2.1.0
>
> ___
> 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] packets left behind by odp_pktio_send()

[Zoltan Kiss]

On 27/05/15 19:50, Mike Holmes wrote:



On 27 May 2015 at 14:45, Ola Liljedahl mailto:ola.liljed...@linaro.org>> wrote:

On 27 May 2015 at 19:30, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:

Hi,

While hunting some ODP-DPDK bugs I've found something which
needs clarification: what happens with those packets not sent by
odp_pktio_send()? This is the case when e.g. there is no free TX
descriptors, so the function returns with less than "len". Our
examples either doesn't seem to do anything about that, or
handle it as a failure. But a real world application should be
able to handle that. I can see two options:
- odp_pktio_send() calls odp_packet_free on the packets which
were not successfully sent.

In this case, odp_pktio_send() could also return "len". All packets
were taken care of (one way or the other). Transmission is not
guaranteed, packets can go missing practically anywhere.

Pro: we can have better information about which buffers exactly
were not sent (although rationally, the last "len-"
packets). Cons: the application might have other plans with
those packets, e.g. send them later
- The application has to handle those packets. Pro: more choice,
not just dropping. Cons: we have to mandate that the last
"len-" packets have to be the ones which were not sent.

If an implementation fails to send (transmit, enqueue, whatever)
packet N, it should stop trying to send any more packets in the
vector and just return N. So 0..N-1 were sent and N..len-1 were not
sent.

I can't come up with a scenario where it wouldn't be the case
anyway, but I have a gut feeling it can happen, and platforms
have to handle that

I prefer the second option, that's how DPDK handles that too. It
needs a comment upgrade in the API, and fixing our usage of
odp_pktio_send around the code base to release the not sent packets.

Agree.


Can you describe what is needed in a Bug Zoltan ?
https://bugs.linaro.org/enter_bug.cgi?product=OpenDataPlane


I've sent in a patch instead: "[PATCH] api-next: packet_io: clarify what 
happens when not all packets are sent"





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




--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org ***│ *Open source software for ARM SoCs

__



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

[lng-odp] [PATCH] api-next: packet_io: clarify what happens when not all packets are sent

[Zoltan Kiss]

Currently our examples are not handling this situation as well.

Signed-off-by: Zoltan Kiss 
---
 include/odp/api/packet_io.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
index 89356a6..b97b2b8 100644
--- a/include/odp/api/packet_io.h
+++ b/include/odp/api/packet_io.h
@@ -111,7 +111,9 @@ int odp_pktio_recv(odp_pktio_t pktio, odp_packet_t 
pkt_table[], int len);
  * @param pkt_table[]  Array of packets to send
  * @param len  length of pkt_table[]
  *
- * @return Number of packets sent
+ * @return Number of packets sent. If it is less than 'len', the remaining
+ * packets at the end of pkt_table[] are left intact, and caller has to take
+ * care of them.
  * @retval <0 on failure
  */
 int odp_pktio_send(odp_pktio_t pktio, odp_packet_t pkt_table[], int len);
-- 
1.9.1

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

Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

[Bill Fischofer]

The purpose of the note was to expand on the case of len = 0.  Are you
saying this is not needed?  The consensus on the Wednesday arch call was
that it was, hence this patch.

On Thu, May 28, 2015 at 5:40 AM, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

>
>  * ... The
>  * packet is initialized with data pointers and lengths set according to
> the
>  * specified len, ...
>
> The current documentation covers functionality also when len is 0. We
> should minimize @note content over all the APIs, otherwise the actual API
> spec gets fragmented. API documentation and functionality is the same for
> len == 0, len == 1, ... In all the cases, implementation decides on packet
> segmentation in limits of pool parameters.
>
> If needed, we could add:
>
> @note Zero is a valid 'len' value
>
>
> -Petri
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> > Bill Fischofer
> > Sent: Wednesday, May 27, 2015 6:51 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of
> 0
> > len on odp_packet_alloc()
> >
> > Signed-off-by: Bill Fischofer 
> > ---
> >  include/odp/api/packet.h | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> > index 3a454b5..ea124df 100644
> > --- a/include/odp/api/packet.h
> > +++ b/include/odp/api/packet.h
> > @@ -73,6 +73,16 @@ extern "C" {
> >   * @note The default headroom and tailroom used for packets is specified
> > by
> >   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM defines
> > in
> >   * odp_config.h.
> > + *
> > + * @note The len parameter sets the initial length of the allocated
> > packet.
> > + * If specified as 0, the implementation will allocate a packet of a
> > default
> > + * length chosen by the implementation based on the pool create
> > parameters
> > + * and will then set the actual length of the packet to 0. The result is
> > + * the same as if the following sequence had been called by the
> > application:
> > + * @code
> > + * pkt = odp_packet_alloc(pool, default_len);
> > + * odp_packet_reset(pkt, 0);
> > + * @endcode
> >   */
> >  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
> >
> > --
> > 2.1.0
> >
> > ___
> > 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] [PATCH] linux-generic: pool: group and document pool statistics

[Bill Fischofer]

Address bug https://bugs.linaro.org/show_bug.cgi?id=1480

Signed-off-by: Bill Fischofer 
---
 platform/linux-generic/include/odp_pool_internal.h | 44 +++
 platform/linux-generic/odp_pool.c  | 50 +++---
 2 files changed, 52 insertions(+), 42 deletions(-)

diff --git a/platform/linux-generic/include/odp_pool_internal.h 
b/platform/linux-generic/include/odp_pool_internal.h
index 247a75a..136db2c 100644
--- a/platform/linux-generic/include/odp_pool_internal.h
+++ b/platform/linux-generic/include/odp_pool_internal.h
@@ -73,6 +73,20 @@ typedef struct local_cache_t {
 #define POOL_LOCK_INIT(a) odp_spinlock_init(a)
 #endif
 
+/**
+ * ODP Pool stats - Maintain some useful stats regarding pool utilization
+ */
+typedef struct {
+   odp_atomic_u64_t bufallocs; /**< Count of successful buf allocs */
+   odp_atomic_u64_t buffrees;  /**< Count of successful buf frees */
+   odp_atomic_u64_t blkallocs; /**< Count of successful blk allocs */
+   odp_atomic_u64_t blkfrees;  /**< Count of successful blk frees */
+   odp_atomic_u64_t bufempty;  /**< Count of unsuccessful buf allocs */
+   odp_atomic_u64_t blkempty;  /**< Count of unsuccessful blk allocs */
+   odp_atomic_u64_t high_wm_count; /**< Count of high wm conditions */
+   odp_atomic_u64_t low_wm_count;  /**< Count of low wm conditions */
+} _odp_pool_stats_t;
+
 struct pool_entry_s {
 #ifdef POOL_USE_TICKETLOCK
odp_ticketlock_tlock ODP_ALIGNED_CACHE;
@@ -111,14 +125,7 @@ struct pool_entry_s {
void   *blk_freelist;
odp_atomic_u32_tbufcount;
odp_atomic_u32_tblkcount;
-   odp_atomic_u64_tbufallocs;
-   odp_atomic_u64_tbuffrees;
-   odp_atomic_u64_tblkallocs;
-   odp_atomic_u64_tblkfrees;
-   odp_atomic_u64_tbufempty;
-   odp_atomic_u64_tblkempty;
-   odp_atomic_u64_thigh_wm_count;
-   odp_atomic_u64_tlow_wm_count;
+   _odp_pool_stats_t   poolstats;
uint32_tbuf_num;
uint32_tseg_size;
uint32_tblk_size;
@@ -153,12 +160,12 @@ static inline void *get_blk(struct pool_entry_s *pool)
 
if (odp_unlikely(myhead == NULL)) {
POOL_UNLOCK(&pool->blk_lock);
-   odp_atomic_inc_u64(&pool->blkempty);
+   odp_atomic_inc_u64(&pool->poolstats.blkempty);
} else {
pool->blk_freelist = ((odp_buf_blk_t *)myhead)->next;
POOL_UNLOCK(&pool->blk_lock);
odp_atomic_dec_u32(&pool->blkcount);
-   odp_atomic_inc_u64(&pool->blkallocs);
+   odp_atomic_inc_u64(&pool->poolstats.blkallocs);
}
 
return myhead;
@@ -174,7 +181,7 @@ static inline void ret_blk(struct pool_entry_s *pool, void 
*block)
POOL_UNLOCK(&pool->blk_lock);
 
odp_atomic_inc_u32(&pool->blkcount);
-   odp_atomic_inc_u64(&pool->blkfrees);
+   odp_atomic_inc_u64(&pool->poolstats.blkfrees);
 }
 
 static inline odp_buffer_hdr_t *get_buf(struct pool_entry_s *pool)
@@ -186,7 +193,7 @@ static inline odp_buffer_hdr_t *get_buf(struct pool_entry_s 
*pool)
 
if (odp_unlikely(myhead == NULL)) {
POOL_UNLOCK(&pool->buf_lock);
-   odp_atomic_inc_u64(&pool->bufempty);
+   odp_atomic_inc_u64(&pool->poolstats.bufempty);
} else {
pool->buf_freelist = myhead->next;
POOL_UNLOCK(&pool->buf_lock);
@@ -196,10 +203,10 @@ static inline odp_buffer_hdr_t *get_buf(struct 
pool_entry_s *pool)
/* Check for low watermark condition */
if (bufcount == pool->low_wm && !pool->low_wm_assert) {
pool->low_wm_assert = 1;
-   odp_atomic_inc_u64(&pool->low_wm_count);
+   odp_atomic_inc_u64(&pool->poolstats.low_wm_count);
}
 
-   odp_atomic_inc_u64(&pool->bufallocs);
+   odp_atomic_inc_u64(&pool->poolstats.bufallocs);
myhead->allocator = odp_thread_id();
}
 
@@ -229,10 +236,10 @@ static inline void ret_buf(struct pool_entry_s *pool, 
odp_buffer_hdr_t *buf)
/* Check if low watermark condition should be deasserted */
if (bufcount == pool->high_wm && pool->low_wm_assert) {
pool->low_wm_assert = 0;
-   odp_atomic_inc_u64(&pool->high_wm_count);
+   odp_atomic_inc_u64(&pool->poolstats.high_wm_count);
}
 
-   odp_atomic_inc_u64(&pool->buffrees);
+   odp_atomic_inc_u64(&pool->poolstats.buffrees);
 }
 
 static inline void *get_local_buf(local_cache_t *buf_cache,
@@ -291,8 +298,9 @@ static inline void flush_cache(local_cache_t *buf_cache,
flush_count++;
}
 
-   odp_atomic_add_u64(&pool->bufallocs, buf_cache->bufallocs);
-   odp_atomic_add

Re: [lng-odp] loopback interface

[Ola Liljedahl]

On 28 May 2015 at 13:01, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolai...@nokia.com> wrote:

> Yes, classification is setup per pktio interface and is done right after
> packet arriving the device. A list of interfaces is device (implementation)
> specific. Valid interfaces may include e.g. eth0, 10ge_0, 10ge_loop0, etc.
> The only reserved interface name is "loop", which must be a packet loopback
> interface. There can be several other packet input or loopback interfaces.
> Classification can be configured for any interface.
>
Perhaps we need multiple loopback interfaces. Because the classification
rules might be different (and conflicting)

We could change the definition so that all interface (pkio) names which
start with "loop" are loopback interfaces. The number of supported loopback
interfaces would be implementation specific.

-- Ola


>
> -Petri
>
>
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> > Mario Torrecillas Rodriguez
> > Sent: Thursday, May 28, 2015 1:50 PM
> > To: Bala; Mike Holmes
> > Cc: LNG ODP Mailman List
> > Subject: Re: [lng-odp] loopback interface
> >
> > On a related noteŠ
> >
> > It is my current understanding that, with the current set of APIs,
> > classification has to be performed right after IO. What makes me think
> > that is that the classification API seems to be linked to the packetIO
> > API.
> > So, my question is, firstly, am I right with my assumption? And secondly,
> > how would you go about classifying (or re-classifying) packets at a later
> > stage, after some processing has already been performed and hence packets
> > are not coming straight from a pktio interface.
> > For instance, you may need to decrypt packets and strip the IPSec headers
> > off, then go through another classification stage. Can this be achieved?
> >
> > Thanks,
> > Mario.
> >
> > On 28/05/2015 10:44, "Bala"  wrote:
> >
> > >
> > >I am get pcaps for classification rules but currently the classification
> > >validation suite creates packets with different values for PMR rules and
> > >sends them across the loop back interface to test classification
> > >feature. So if I understand correctly is the pcap file going to recreate
> > >this scenario?
> > >
> > >Regards,
> > >bala
> > >On Thursday 28 May 2015 03:08 PM, Mike Holmes wrote:
> > >> Bala if you can get the pcaps to test the classification rules, I hope
> > >>the
> > >> new assignee coming on line shortly will be able to work running them
> > >>into
> > >> the validation test suite.
> > >>
> > >> On 28 May 2015 at 05:24, Bala Manoharan 
> > >>wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Yes. Lookback interface should behave like other interfaces in the
> > >>> system and classification rules if set should get applied.
> > >>>
> > >>> Regards,
> > >>> Bala
> > >>>
> > >>> On 28 May 2015 at 14:51, Ola Liljedahl 
> > >>>wrote:
> >  Is the loopback interface supposed to be supported in all ODP
> >  implementations? And it will have the same functionality as real
> > pktio
> >  interfaces?
> > 
> >  I was thinking of feeding the loopback interface packets that are
> > read
> > >>> from
> >  a pcap file. Classification rules could then be associated with the
> > >>> loopback
> >  interface and packets will eventually be enqueued on the queues
> > >>> specified in
> >  the matching class of service.
> > 
> >  -- Ola
> > 
> > 
> >  ___
> >  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
> >
> >
> > -- IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose the
> > contents to any other person, use it for any purpose, or store or copy
> the
> > information in any medium.  Thank you.
> >
> > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> > Registered in England & Wales, Company No:  2557590
> > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> > Registered in England & Wales, Company No:  2548782
> >
> > ___
> > 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] loopback interface

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

Yes, classification is setup per pktio interface and is done right after packet 
arriving the device. A list of interfaces is device (implementation) specific. 
Valid interfaces may include e.g. eth0, 10ge_0, 10ge_loop0, etc. The only 
reserved interface name is "loop", which must be a packet loopback interface. 
There can be several other packet input or loopback interfaces. Classification 
can be configured for any interface.

-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Mario Torrecillas Rodriguez
> Sent: Thursday, May 28, 2015 1:50 PM
> To: Bala; Mike Holmes
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] loopback interface
> 
> On a related noteŠ
> 
> It is my current understanding that, with the current set of APIs,
> classification has to be performed right after IO. What makes me think
> that is that the classification API seems to be linked to the packetIO
> API.
> So, my question is, firstly, am I right with my assumption? And secondly,
> how would you go about classifying (or re-classifying) packets at a later
> stage, after some processing has already been performed and hence packets
> are not coming straight from a pktio interface.
> For instance, you may need to decrypt packets and strip the IPSec headers
> off, then go through another classification stage. Can this be achieved?
> 
> Thanks,
> Mario.
> 
> On 28/05/2015 10:44, "Bala"  wrote:
> 
> >
> >I am get pcaps for classification rules but currently the classification
> >validation suite creates packets with different values for PMR rules and
> >sends them across the loop back interface to test classification
> >feature. So if I understand correctly is the pcap file going to recreate
> >this scenario?
> >
> >Regards,
> >bala
> >On Thursday 28 May 2015 03:08 PM, Mike Holmes wrote:
> >> Bala if you can get the pcaps to test the classification rules, I hope
> >>the
> >> new assignee coming on line shortly will be able to work running them
> >>into
> >> the validation test suite.
> >>
> >> On 28 May 2015 at 05:24, Bala Manoharan 
> >>wrote:
> >>
> >>> Hi,
> >>>
> >>> Yes. Lookback interface should behave like other interfaces in the
> >>> system and classification rules if set should get applied.
> >>>
> >>> Regards,
> >>> Bala
> >>>
> >>> On 28 May 2015 at 14:51, Ola Liljedahl 
> >>>wrote:
>  Is the loopback interface supposed to be supported in all ODP
>  implementations? And it will have the same functionality as real
> pktio
>  interfaces?
> 
>  I was thinking of feeding the loopback interface packets that are
> read
> >>> from
>  a pcap file. Classification rules could then be associated with the
> >>> loopback
>  interface and packets will eventually be enqueued on the queues
> >>> specified in
>  the matching class of service.
> 
>  -- Ola
> 
> 
>  ___
>  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
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
> 
> ___
> 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] [PATCH 6/6] validation: moving pktio plt specific to platform

[Christophe Milard]

The platform specific scripts for pktio are now moved
from the validation to the platform side.
Pktio tests are now initiated from the platform side.

Signed-off-by: Christophe Milard 
---
 configure.ac   |  1 +
 platform/linux-generic/test/.gitignore |  2 ++
 platform/linux-generic/test/Makefile.am|  8 +++-
 platform/linux-generic/test/pktio/.gitignore   |  2 ++
 platform/linux-generic/test/pktio/Makefile.am  |  2 ++
 platform/linux-generic/test/{ => pktio}/pktio_env  |  0
 .../linux-generic/test}/pktio/pktio_run| 24 --
 test/performance/odp_l2fwd_run |  4 ++--
 test/validation/Makefile.am|  4 +---
 test/validation/pktio/Makefile.am  |  2 --
 10 files changed, 25 insertions(+), 24 deletions(-)
 create mode 100644 platform/linux-generic/test/.gitignore
 create mode 100644 platform/linux-generic/test/pktio/.gitignore
 create mode 100644 platform/linux-generic/test/pktio/Makefile.am
 rename platform/linux-generic/test/{ => pktio}/pktio_env (100%)
 rename {test/validation => platform/linux-generic/test}/pktio/pktio_run (71%)

diff --git a/configure.ac b/configure.ac
index 38667be..27d1f8d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -297,6 +297,7 @@ AC_CONFIG_FILES([Makefile
 helper/test/Makefile
 pkgconfig/libodp.pc
 platform/linux-generic/Makefile
+platform/linux-generic/test/pktio/Makefile
 test/Makefile
 test/api_test/Makefile
 test/performance/Makefile
diff --git a/platform/linux-generic/test/.gitignore 
b/platform/linux-generic/test/.gitignore
new file mode 100644
index 000..7e563b8
--- /dev/null
+++ b/platform/linux-generic/test/.gitignore
@@ -0,0 +1,2 @@
+*.log
+*.trs
diff --git a/platform/linux-generic/test/Makefile.am 
b/platform/linux-generic/test/Makefile.am
index 91e361c..8c5a386 100644
--- a/platform/linux-generic/test/Makefile.am
+++ b/platform/linux-generic/test/Makefile.am
@@ -1 +1,7 @@
-dist_bin_SCRIPTS = $(srcdir)/pktio_env
+
+if test_vald
+TESTS = pktio/pktio_run
+endif
+
+ODP_MODULES = pktio
+SUBDIRS = $(ODP_MODULES)
diff --git a/platform/linux-generic/test/pktio/.gitignore 
b/platform/linux-generic/test/pktio/.gitignore
new file mode 100644
index 000..7e563b8
--- /dev/null
+++ b/platform/linux-generic/test/pktio/.gitignore
@@ -0,0 +1,2 @@
+*.log
+*.trs
diff --git a/platform/linux-generic/test/pktio/Makefile.am 
b/platform/linux-generic/test/pktio/Makefile.am
new file mode 100644
index 000..93281dd
--- /dev/null
+++ b/platform/linux-generic/test/pktio/Makefile.am
@@ -0,0 +1,2 @@
+dist_bin_SCRIPTS = pktio_env \
+  pktio_run
diff --git a/platform/linux-generic/test/pktio_env 
b/platform/linux-generic/test/pktio/pktio_env
similarity index 100%
rename from platform/linux-generic/test/pktio_env
rename to platform/linux-generic/test/pktio/pktio_env
diff --git a/test/validation/pktio/pktio_run 
b/platform/linux-generic/test/pktio/pktio_run
similarity index 71%
rename from test/validation/pktio/pktio_run
rename to platform/linux-generic/test/pktio/pktio_run
index aed0cd2..d048aa8 100755
--- a/test/validation/pktio/pktio_run
+++ b/platform/linux-generic/test/pktio/pktio_run
@@ -13,15 +13,10 @@
 # 1. user build ODP in the same dir as the source (most likely)
 #here the user can simply call pktio_run
 # 2. user may have built ODP in a separate build dir (like bitbake usually 
does)
-#here the user has to do something like $ODP/test/validation/pktio_run
-#
-# In both situations the script assumes that the user is in the directory where
-# pktio_main exists. If that's not true, then the user has to specify the path
-# to it and run:
-# TEST_DIR=$builddir $ODP/test/validation/pktio_run
+#here the user has to do something like 
$ODP/platform/linux-generic/test/pktio/pktio_run
 
 # directory where test binaries have been built
-TEST_DIR="${TEST_DIR:-$PWD}"
+TEST_DIR="${TEST_DIR:-$PWD}/../../../test/validation/pktio"
 # directory where test sources are, including scripts
 TEST_SRC_DIR=$(dirname $0)
 
@@ -33,12 +28,8 @@ TEST_SKIPPED=77
 # Use installed pktio env or for make check take it from platform directory
 if [ -f "./pktio_env" ]; then
. ./pktio_env
-elif  [ "$ODP_PLATFORM" = "" ]; then
-   echo "$0: error: ODP_PLATFORM must be defined"
-   # not skipped as this should never happen via "make check"
-   exit 1
-elif [ -f ${TEST_SRC_DIR}/../../../platform/$ODP_PLATFORM/test/pktio_env ]; 
then
-   . ${TEST_SRC_DIR}/../../../platform/$ODP_PLATFORM/test/pktio_env
+elif [ -f ${TEST_SRC_DIR}/pktio_env ]; then
+   . ${TEST_SRC_DIR}/pktio_env
 else
echo "BUG: unable to find pktio_env!"
echo "pktio_env has to be in current directory or in 
platform/\$ODP_PLATFORM/test."
@@ -61,7 +52,7 @@ run_test()
if [ "$disabletype" != "SKIP" ]; then
  

[lng-odp] [PATCH 4/6] validation: creating own dir and lib for pktio

[Christophe Milard]

Module pktio now gets its own directory and create its own lib
(currentely only containing its executable)
Startup scripting stuff is just moved to the pktio directory but remains 
untouched
at this stage (test is still ran from validation side)

Signed-off-by: Christophe Milard 
---
 configure.ac   |  1 +
 test/validation/.gitignore |  1 -
 test/validation/Makefile.am| 13 -
 test/validation/Makefile.inc   |  7 +++
 test/validation/pktio/.gitignore   |  4 
 test/validation/pktio/Makefile.am  | 10 ++
 test/validation/{odp_pktio.c => pktio/pktio.c} |  9 ++---
 test/validation/pktio/pktio.h  |  7 +++
 test/validation/pktio/pktio_main.c | 12 
 test/validation/{odp_pktio_run => pktio/pktio_run} | 16 
 10 files changed, 55 insertions(+), 25 deletions(-)
 create mode 100644 test/validation/Makefile.inc
 create mode 100644 test/validation/pktio/.gitignore
 create mode 100644 test/validation/pktio/Makefile.am
 rename test/validation/{odp_pktio.c => pktio/pktio.c} (99%)
 create mode 100644 test/validation/pktio/pktio.h
 create mode 100644 test/validation/pktio/pktio_main.c
 rename test/validation/{odp_pktio_run => pktio/pktio_run} (85%)

diff --git a/configure.ac b/configure.ac
index f8a7e72..95eceae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -301,6 +301,7 @@ AC_CONFIG_FILES([Makefile
 test/performance/Makefile
 test/validation/Makefile
 test/validation/common/Makefile
+test/validation/pktio/Makefile
 test/miscellaneous/Makefile
 ])
 
diff --git a/test/validation/.gitignore b/test/validation/.gitignore
index 34ea143..7d3a0fc 100644
--- a/test/validation/.gitignore
+++ b/test/validation/.gitignore
@@ -9,7 +9,6 @@ odp_init
 odp_init_abort
 odp_init_log
 odp_packet
-odp_pktio
 odp_pool
 odp_queue
 odp_random
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index 8299e01..a82e35c 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -25,16 +25,12 @@ EXECUTABLES = odp_buffer \
  odp_thread \
  odp_ver_abt_log_dbg
 
-COMPILE_ONLY = odp_pktio
-
-TESTSCRIPTS = odp_pktio_run
+TESTSCRIPTS = pktio/pktio_run
 
 if test_vald
 TESTS = $(EXECUTABLES) $(TESTSCRIPTS)
 endif
 
-dist_bin_SCRIPTS = odp_pktio_run
-
 bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
 
 ODP_CU_COMMON=common/odp_cunit_common.c
@@ -58,9 +54,6 @@ dist_odp_shared_memory_SOURCES= odp_shared_memory.c
 dist_odp_synchronizers_SOURCES = odp_synchronizers.c
 dist_odp_time_SOURCES   = odp_time.c
 dist_odp_timer_SOURCES  = odp_timer.c
-odp_pktio_LDADD = $(top_builddir)/test/validation/common/libcunit_common.a \
-   $(LIB)/libodp.la
-dist_odp_pktio_SOURCES = odp_pktio.c
 dist_odp_packet_SOURCES = odp_packet.c
 dist_odp_pool_SOURCES = odp_pool.c
 dist_odp_cpumask_SOURCES = odp_cpumask.c
@@ -69,4 +62,6 @@ odp_ver_abt_log_dbg_CFLAGS = $(AM_CFLAGS) 
-I$(srcdir)/ver_abt_log_dbg
 dist_odp_ver_abt_log_dbg_SOURCES  = ver_abt_log_dbg/odp_system.c \
ver_abt_log_dbg/odp_errno.c \
 ver_abt_log_dbg/odp_ver_abt_log_dbg.c
-SUBDIRS = common
+
+ODP_MODULES = pktio
+SUBDIRS = common $(ODP_MODULES)
diff --git a/test/validation/Makefile.inc b/test/validation/Makefile.inc
new file mode 100644
index 000..3cdc6a7
--- /dev/null
+++ b/test/validation/Makefile.inc
@@ -0,0 +1,7 @@
+include $(top_srcdir)/test/Makefile.inc
+
+AM_CFLAGS += -I$(top_srcdir)/test/validation/common
+AM_LDFLAGS += -static
+
+LIBCUNIT_COMMON = $(top_builddir)/test/validation/common/libcunit_common.a
+LIBODP = $(LIB)/libodp.la
diff --git a/test/validation/pktio/.gitignore b/test/validation/pktio/.gitignore
new file mode 100644
index 000..7aa8e13
--- /dev/null
+++ b/test/validation/pktio/.gitignore
@@ -0,0 +1,4 @@
+*.log
+*.trs
+libpktio.a
+pktio_main
diff --git a/test/validation/pktio/Makefile.am 
b/test/validation/pktio/Makefile.am
new file mode 100644
index 000..2acb63b
--- /dev/null
+++ b/test/validation/pktio/Makefile.am
@@ -0,0 +1,10 @@
+include ../Makefile.inc
+
+dist_bin_SCRIPTS = pktio_run
+
+noinst_LIBRARIES = libpktio.a
+libpktio_a_SOURCES = pktio.c
+
+check_PROGRAMS = pktio_main
+dist_pktio_main_SOURCES = pktio_main.c
+pktio_main_LDADD = libpktio.a $(LIBCUNIT_COMMON) $(LIBODP)
diff --git a/test/validation/odp_pktio.c b/test/validation/pktio/pktio.c
similarity index 99%
rename from test/validation/odp_pktio.c
rename to test/validation/pktio/pktio.c
index 156285a..1fd7585 100644
--- a/test/validation/odp_pktio.c
+++ b/test/validation/pktio/pktio.c
@@ -12,6 +12,7 @@
 #include 
 
 #include 
+#include "pktio.h"
 
 #define PKT_BUF_NUM32
 #define PKT_BUF_SIZE   (9 * 1024)
@@ -693,13 +694,7 @@ static CU_S

[lng-odp] [PATCH 5/6] validation: changing build order

[Christophe Milard]

When tests will be ran from the platform side, they will use
platform agnostic tests from the validation side: i.e.
 -the validation side must be build before the platform test side.
And the platform agnostic tests uses ODP.
The building order must therefore be as follows:
1)  (i.e. ODP)
2) validation (i.e. common tests)
3) /test (i.e. the platform specific test setup and tests)

Saddly, writting SUBDIRS=platform/@with_platform@ does not work with
autotools, which leads to a bit of clutter in configure.ac.
Hopefully changed if things move around in the future...

Signed-off-by: Christophe Milard 
---
 Makefile.am| 8 +++-
 configure.ac   | 3 ++-
 platform/Makefile.am   | 1 -
 platform/linux-generic/Makefile.am | 2 --
 4 files changed, 9 insertions(+), 5 deletions(-)
 delete mode 100644 platform/Makefile.am

diff --git a/Makefile.am b/Makefile.am
index cff83f7..1692b88 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,13 @@
 ACLOCAL_AMFLAGS=-I m4
 AUTOMAKE_OPTIONS = foreign
 
-SUBDIRS = doc platform example test helper
+#@with_platform@ works alone in subdir but not as part of a path???
+SUBDIRS = @platform_with_platform@ \
+ test \
+ @platform_with_platform_test@ \
+ helper \
+ doc \
+ example
 
 include $(top_srcdir)/aminclude.am
 
diff --git a/configure.ac b/configure.ac
index 95eceae..38667be 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,6 +76,8 @@ AC_ARG_WITH([platform],
 ])
 
 AC_SUBST([with_platform])
+AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
+AC_SUBST([platform_with_platform_test], ["platform/${with_platform}/test"])
 
 if test "${with_platform}" == "linux-generic";
 then
@@ -294,7 +296,6 @@ AC_CONFIG_FILES([Makefile
 helper/Makefile
 helper/test/Makefile
 pkgconfig/libodp.pc
-platform/Makefile
 platform/linux-generic/Makefile
 test/Makefile
 test/api_test/Makefile
diff --git a/platform/Makefile.am b/platform/Makefile.am
deleted file mode 100644
index e618747..000
--- a/platform/Makefile.am
+++ /dev/null
@@ -1 +0,0 @@
-SUBDIRS = @with_platform@
diff --git a/platform/linux-generic/Makefile.am 
b/platform/linux-generic/Makefile.am
index 66f0474..b8f93c7 100644
--- a/platform/linux-generic/Makefile.am
+++ b/platform/linux-generic/Makefile.am
@@ -5,8 +5,6 @@ AM_CFLAGS +=  -I$(srcdir)/include
 AM_CFLAGS +=  -I$(top_srcdir)/include
 AM_CFLAGS +=  -I$(top_srcdir)/helper/include
 
-SUBDIRS = test
-
 include_HEADERS = \
  $(top_srcdir)/include/odp.h
 
-- 
1.9.1

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

[lng-odp] [PATCH 2/6] validation: own main and renaming in odp_pktio.c

[Christophe Milard]

Renaming of things which may be, one day, exported in a lib.
This renaming is important, as it creates consistency between test
symbols, which is needed if things get eventually exported in the lib.
Also, tests are often created from other tests: Fixing the first exemples
will help geting future tests better.

Also defining local test main.

Things that are candidate to be exported in the lib in the future
have been named as follows:
 -Tests, i.e. functions which are used in CUNIT testsuites are named:
_test_*
 -Test arrays, i.e. arrays of CU_TestInfo, listing the test functions
  belonging to a suite, are called:
_suite[_*]
  where the possible suffix can be used if many suites are declared.
 -CUNIT suite init and termination functions are called:
_suite[_*]_init() and _suite[_*]_term()
  respectively.
 -Suite arrays, i.e. arrays of CU_SuiteInfo used in executables are called:
_suites[_*]
  where the possible suffix identifies the executable using it, if many.
 -Main function(s), are called:
_main[_*]
  where the possible suffix identifies the executable using it

Signed-off-by: Christophe Milard 
---
 test/Makefile.inc   |  7 +++-
 test/validation/Makefile.am |  8 ++---
 test/validation/odp_pktio.c | 81 +
 3 files changed, 55 insertions(+), 41 deletions(-)

diff --git a/test/Makefile.inc b/test/Makefile.inc
index e20a848..c579c46 100644
--- a/test/Makefile.inc
+++ b/test/Makefile.inc
@@ -1,7 +1,12 @@
 include $(top_srcdir)/Makefile.inc
 include $(top_srcdir)/platform/@with_platform@/Makefile.inc
 LIB   = $(top_builddir)/lib
-LDADD = $(LIB)/libodp.la
+
+#in the following line, the libs using the symbols should come before
+#the libs using them! The includer is given a chance to add things before 
libodp
+#by setting PRE_LDDAD before the inclusion.
+LDADD = $(PRE_LDDAD) $(LIB)/libodp.la
+
 INCFLAGS = -I$(srcdir) \
-I$(top_srcdir)/test \
-I$(top_srcdir)/platform/@with_platform@/include \
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index 965f603..8299e01 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -1,13 +1,9 @@
+PRE_LDDAD = $(top_builddir)/test/validation/common/libcunit_common_as_main.a
 include $(top_srcdir)/test/Makefile.inc
 
 AM_CFLAGS += -I$(srcdir)/common
 AM_LDFLAGS += -static
 
-#warning: in the following line, the libs using the symbols should come before
-#the libs using them!
-LDADD = $(top_builddir)/test/validation/common/libcunit_common_as_main.a \
-   $(LIB)/libodp.la
-
 TESTS_ENVIRONMENT = ODP_PLATFORM=${with_platform} TEST_DIR=${builddir}
 
 EXECUTABLES = odp_buffer \
@@ -62,6 +58,8 @@ dist_odp_shared_memory_SOURCES= odp_shared_memory.c
 dist_odp_synchronizers_SOURCES = odp_synchronizers.c
 dist_odp_time_SOURCES   = odp_time.c
 dist_odp_timer_SOURCES  = odp_timer.c
+odp_pktio_LDADD = $(top_builddir)/test/validation/common/libcunit_common.a \
+   $(LIB)/libodp.la
 dist_odp_pktio_SOURCES = odp_pktio.c
 dist_odp_packet_SOURCES = odp_packet.c
 dist_odp_pool_SOURCES = odp_pool.c
diff --git a/test/validation/odp_pktio.c b/test/validation/odp_pktio.c
index d4bf7bf..9806376 100644
--- a/test/validation/odp_pktio.c
+++ b/test/validation/odp_pktio.c
@@ -420,7 +420,7 @@ static void pktio_txrx_multi(pktio_info_t *pktio_a, 
pktio_info_t *pktio_b,
CU_ASSERT(i == num_pkts);
 }
 
-static void pktio_test_txrx(odp_queue_type_t q_type, int num_pkts)
+static void test_txrx(odp_queue_type_t q_type, int num_pkts)
 {
int ret, i, if_b;
pktio_info_t pktios[MAX_NUM_IFACES];
@@ -456,34 +456,34 @@ static void pktio_test_txrx(odp_queue_type_t q_type, int 
num_pkts)
}
 }
 
-static void test_odp_pktio_poll_queue(void)
+static void pktio_test_poll_queue(void)
 {
-   pktio_test_txrx(ODP_QUEUE_TYPE_POLL, 1);
+   test_txrx(ODP_QUEUE_TYPE_POLL, 1);
 }
 
-static void test_odp_pktio_poll_multi(void)
+static void pktio_test_poll_multi(void)
 {
-   pktio_test_txrx(ODP_QUEUE_TYPE_POLL, 4);
+   test_txrx(ODP_QUEUE_TYPE_POLL, 4);
 }
 
-static void test_odp_pktio_sched_queue(void)
+static void pktio_test_sched_queue(void)
 {
-   pktio_test_txrx(ODP_QUEUE_TYPE_SCHED, 1);
+   test_txrx(ODP_QUEUE_TYPE_SCHED, 1);
 }
 
-static void test_odp_pktio_sched_multi(void)
+static void pktio_test_sched_multi(void)
 {
-   pktio_test_txrx(ODP_QUEUE_TYPE_SCHED, 4);
+   test_txrx(ODP_QUEUE_TYPE_SCHED, 4);
 }
 
-static void test_odp_pktio_jumbo(void)
+static void pktio_test_jumbo(void)
 {
packet_len = PKT_LEN_JUMBO;
-   test_odp_pktio_sched_multi();
+   pktio_test_sched_multi();
packet_len = PKT_LEN_NORMAL;
 }
 
-static void test_odp_pktio_mtu(void)
+static void pktio_test_mtu(void)
 {
int ret;
int mtu;
@@ -500,7 +500,7 @@ static void test_odp_pktio_mtu(void)
return;
 }
 
-static void test_odp_pktio_promisc(void)
+static void pktio_test_promisc(void)
 {
int ret;
odp

[lng-odp] [PATCH 3/6] validation: cosmetic fixes in odp_pktio.c

[Christophe Milard]

Preparing for the next patch where this file is moved and
check-odp would yell if these things were still there.

Signed-off-by: Christophe Milard 
---
 test/validation/odp_pktio.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/test/validation/odp_pktio.c b/test/validation/odp_pktio.c
index 9806376..156285a 100644
--- a/test/validation/odp_pktio.c
+++ b/test/validation/odp_pktio.c
@@ -14,7 +14,7 @@
 #include 
 
 #define PKT_BUF_NUM32
-#define PKT_BUF_SIZE   (9*1024)
+#define PKT_BUF_SIZE   (9 * 1024)
 #define PKT_LEN_NORMAL 64
 #define PKT_LEN_JUMBO  (PKT_BUF_SIZE - ODPH_ETHHDR_LEN - \
ODPH_IPV4HDR_LEN - ODPH_UDPHDR_LEN)
@@ -212,7 +212,7 @@ static int default_pool_create(void)
params.type= ODP_POOL_PACKET;
 
default_pkt_pool = odp_pool_create("pkt_pool_default",
- ODP_SHM_NULL, ¶ms);
+  ODP_SHM_NULL, ¶ms);
if (default_pkt_pool == ODP_POOL_INVALID)
return -1;
 
@@ -265,7 +265,8 @@ static int create_inq(odp_pktio_t pktio, odp_queue_type_t 
qtype)
 odp_pktio_to_u64(pktio));
inq_def = odp_queue_lookup(inq_name);
if (inq_def == ODP_QUEUE_INVALID)
-   inq_def = odp_queue_create(inq_name,
+   inq_def = odp_queue_create(
+   inq_name,
ODP_QUEUE_TYPE_PKTIN,
qtype == ODP_QUEUE_TYPE_POLL ? NULL : &qparam);
 
@@ -496,8 +497,6 @@ static void pktio_test_mtu(void)
 
ret = odp_pktio_close(pktio);
CU_ASSERT(ret == 0);
-
-   return;
 }
 
 static void pktio_test_promisc(void)
@@ -521,8 +520,6 @@ static void pktio_test_promisc(void)
 
ret = odp_pktio_close(pktio);
CU_ASSERT(ret == 0);
-
-   return;
 }
 
 static void pktio_test_mac(void)
@@ -547,8 +544,6 @@ static void pktio_test_mac(void)
 
ret = odp_pktio_close(pktio);
CU_ASSERT(0 == ret);
-
-   return;
 }
 
 static void pktio_test_inq_remdef(void)
-- 
1.9.1

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

[lng-odp] [PATCH 1/6] validation: preparing for main in tests

[Christophe Milard]

In odp_cunit_common.c, a macro, called MODULE_HAS_OWN_MAIN is used to tell
whether to define a main or not.
If MODULE_HAS_OWN_MAIN is defined, odp_cunit_common.c does not
define any main, but offers odp_cunit_run(CU_SuiteInfo testsuites[])
to run the tests.
Two libs are then built, one with MODULE_HAS_OWN_MAIN defined
(to be used in the future, by tests which define their own main)
and one with MODULE_HAS_OWN_MAIN undefined, used by all tests at
this stage.

Signed-off-by: Christophe Milard 
---
 configure.ac  |  1 +
 test/validation/Makefile.am   | 44 ++-
 test/validation/common/.gitignore |  2 ++
 test/validation/common/Makefile.am| 10 +++
 test/validation/common/odp_cunit_common.c | 18 +++--
 test/validation/common/odp_cunit_common.h |  3 +++
 6 files changed, 51 insertions(+), 27 deletions(-)
 create mode 100644 test/validation/common/.gitignore
 create mode 100644 test/validation/common/Makefile.am

diff --git a/configure.ac b/configure.ac
index 59e9057..f8a7e72 100644
--- a/configure.ac
+++ b/configure.ac
@@ -300,6 +300,7 @@ AC_CONFIG_FILES([Makefile
 test/api_test/Makefile
 test/performance/Makefile
 test/validation/Makefile
+test/validation/common/Makefile
 test/miscellaneous/Makefile
 ])
 
diff --git a/test/validation/Makefile.am b/test/validation/Makefile.am
index 577063b..965f603 100644
--- a/test/validation/Makefile.am
+++ b/test/validation/Makefile.am
@@ -3,6 +3,11 @@ include $(top_srcdir)/test/Makefile.inc
 AM_CFLAGS += -I$(srcdir)/common
 AM_LDFLAGS += -static
 
+#warning: in the following line, the libs using the symbols should come before
+#the libs using them!
+LDADD = $(top_builddir)/test/validation/common/libcunit_common_as_main.a \
+   $(LIB)/libodp.la
+
 TESTS_ENVIRONMENT = ODP_PLATFORM=${with_platform} TEST_DIR=${builddir}
 
 EXECUTABLES = odp_buffer \
@@ -39,30 +44,31 @@ bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
 ODP_CU_COMMON=common/odp_cunit_common.c
 
 odp_buffer_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/buffer
-dist_odp_buffer_SOURCES = odp_buffer.c $(ODP_CU_COMMON)
+dist_odp_buffer_SOURCES = odp_buffer.c
 odp_classification_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/classification
 dist_odp_classification_SOURCES = classification/odp_classification_tests.c \
classification/odp_classification_basic.c \
-   odp_classification.c $(ODP_CU_COMMON)
+   odp_classification.c
 odp_crypto_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/crypto
 dist_odp_crypto_SOURCES = crypto/odp_crypto_test_inp.c \
- odp_crypto.c $(ODP_CU_COMMON)
-dist_odp_init_SOURCES  = init/odp_init.c $(ODP_CU_COMMON)
-dist_odp_init_abort_SOURCES = init/odp_init_abort.c $(ODP_CU_COMMON)
-dist_odp_init_log_SOURCES = init/odp_init_log.c $(ODP_CU_COMMON)
-dist_odp_queue_SOURCES = odp_queue.c $(ODP_CU_COMMON)
-dist_odp_random_SOURCES = odp_random.c $(ODP_CU_COMMON)
-dist_odp_scheduler_SOURCES = odp_scheduler.c $(ODP_CU_COMMON)
-dist_odp_shared_memory_SOURCES = odp_shared_memory.c $(ODP_CU_COMMON)
-dist_odp_synchronizers_SOURCES = odp_synchronizers.c $(ODP_CU_COMMON)
-dist_odp_time_SOURCES   = odp_time.c $(ODP_CU_COMMON)
-dist_odp_timer_SOURCES  = odp_timer.c $(ODP_CU_COMMON)
-dist_odp_pktio_SOURCES = odp_pktio.c $(ODP_CU_COMMON)
-dist_odp_packet_SOURCES = odp_packet.c $(ODP_CU_COMMON)
-dist_odp_pool_SOURCES = odp_pool.c $(ODP_CU_COMMON)
-dist_odp_cpumask_SOURCES = odp_cpumask.c $(ODP_CU_COMMON)
-dist_odp_thread_SOURCES = odp_thread.c $(ODP_CU_COMMON)
+ odp_crypto.c
+dist_odp_init_SOURCES  = init/odp_init.c
+dist_odp_init_abort_SOURCES = init/odp_init_abort.c
+dist_odp_init_log_SOURCES = init/odp_init_log.c
+dist_odp_queue_SOURCES = odp_queue.c
+dist_odp_random_SOURCES = odp_random.c
+dist_odp_scheduler_SOURCES = odp_scheduler.c
+dist_odp_shared_memory_SOURCES = odp_shared_memory.c
+dist_odp_synchronizers_SOURCES = odp_synchronizers.c
+dist_odp_time_SOURCES   = odp_time.c
+dist_odp_timer_SOURCES  = odp_timer.c
+dist_odp_pktio_SOURCES = odp_pktio.c
+dist_odp_packet_SOURCES = odp_packet.c
+dist_odp_pool_SOURCES = odp_pool.c
+dist_odp_cpumask_SOURCES = odp_cpumask.c
+dist_odp_thread_SOURCES = odp_thread.c
 odp_ver_abt_log_dbg_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/ver_abt_log_dbg
 dist_odp_ver_abt_log_dbg_SOURCES  = ver_abt_log_dbg/odp_system.c \
ver_abt_log_dbg/odp_errno.c \
-ver_abt_log_dbg/odp_ver_abt_log_dbg.c 
$(ODP_CU_COMMON)
+ver_abt_log_dbg/odp_ver_abt_log_dbg.c
+SUBDIRS = common
diff --git a/test/validation/common/.gitignore 
b/test/validation/common/.gitignore
new file mode 100644
index 000..e8aa876
--- /dev/null
+++ b/test/validation/common/.gitignore
@@ -0,0 +1,2 @@
+libcunit_common.a
+libcunit_common_as_main

[lng-odp] [PATCH 0/6] validation: pktio test move to platform side

[Christophe Milard]

This series of patches comes following the request from Stuart to
see the effect of the new test structure on module pktio rather than on a 
simpler module, such as 'random'.

Please, review carefully, keeping in mind that many of you have a better and
larger view on the whole environment... I can miss things :-) ...

Be also aware that after applying these patches, you end up with a mixed 
environment: pktio will be ran from the platform side, while all other tests
will still be ran from the validation side: as a consequence, you will notice
that:

- the make check "grand total" (19 PASS) is now split 18 + 1: this split will
  remain untill all tests are "moved" to the platform side.
- despite the creation of pktio own Makefile.am, a lot of complexity remains 
  in the validation Makefile.am: the complexity of the validation/Makefile.am 
  will reduce as tests gets moved, resulting in a simple list of modules.
- the tests results will spread between the validation and the platform sides.
  I expect this to remain (depending on whether the test was platform dependent,
  or not).

This approach also requires to build the things in the following order:
1) ODP (i.e: platform// things)
2) the platform agnostic tests (i.e: validation/test/ things), using ODP.
3) the platform dependent tests (platform//test)
This changed is introduced by patch "0005-validation-changing-build-order.patch"
which is a hack to workaround what seems to be an autotools limitation:
"SUBDIRS = @MACRO@" works, while
"SUBDIRS = xxx/@MACRO@/yyy" does not work.
This is hopefully a temporary fix as I assume that this directory structure 
will change: Having the ODP code in "platform//*" and the tests in
"platform//tests" seems to imply that tests are a subpart of ODP,
which is not true.

When this patch is accepted, other modeles conversion will follows.

thanks for your time.

Christophe Milard (6):
  validation: preparing for main in tests
  validation: own main and renaming in odp_pktio.c
  validation: cosmetic fixes in odp_pktio.c
  validation: creating own dir and lib for pktio
  validation: changing build order
  validation: moving pktio plt specific to platform

 Makefile.am|  8 +-
 configure.ac   |  6 +-
 platform/Makefile.am   |  1 -
 platform/linux-generic/Makefile.am |  2 -
 platform/linux-generic/test/.gitignore |  2 +
 platform/linux-generic/test/Makefile.am|  8 +-
 platform/linux-generic/test/pktio/.gitignore   |  2 +
 platform/linux-generic/test/pktio/Makefile.am  |  2 +
 platform/linux-generic/test/{ => pktio}/pktio_env  |  0
 .../linux-generic/test/pktio/pktio_run | 26 +++
 test/Makefile.inc  |  7 +-
 test/performance/odp_l2fwd_run |  4 +-
 test/validation/.gitignore |  1 -
 test/validation/Makefile.am| 49 ++--
 test/validation/Makefile.inc   |  7 ++
 test/validation/common/.gitignore  |  2 +
 test/validation/common/Makefile.am | 10 +++
 test/validation/common/odp_cunit_common.c  | 18 +++--
 test/validation/common/odp_cunit_common.h  |  3 +
 test/validation/pktio/.gitignore   |  4 +
 test/validation/pktio/Makefile.am  |  8 ++
 test/validation/{odp_pktio.c => pktio/pktio.c} | 89 +++---
 test/validation/pktio/pktio.h  |  7 ++
 test/validation/pktio/pktio_main.c | 12 +++
 24 files changed, 173 insertions(+), 105 deletions(-)
 delete mode 100644 platform/Makefile.am
 create mode 100644 platform/linux-generic/test/.gitignore
 create mode 100644 platform/linux-generic/test/pktio/.gitignore
 create mode 100644 platform/linux-generic/test/pktio/Makefile.am
 rename platform/linux-generic/test/{ => pktio}/pktio_env (100%)
 rename test/validation/odp_pktio_run => 
platform/linux-generic/test/pktio/pktio_run (70%)
 create mode 100644 test/validation/Makefile.inc
 create mode 100644 test/validation/common/.gitignore
 create mode 100644 test/validation/common/Makefile.am
 create mode 100644 test/validation/pktio/.gitignore
 create mode 100644 test/validation/pktio/Makefile.am
 rename test/validation/{odp_pktio.c => pktio/pktio.c} (90%)
 create mode 100644 test/validation/pktio/pktio.h
 create mode 100644 test/validation/pktio/pktio_main.c

-- 
1.9.1

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

Re: [lng-odp] loopback interface

[Mario Torrecillas Rodriguez]

On a related noteŠ

It is my current understanding that, with the current set of APIs,
classification has to be performed right after IO. What makes me think
that is that the classification API seems to be linked to the packetIO API.
So, my question is, firstly, am I right with my assumption? And secondly,
how would you go about classifying (or re-classifying) packets at a later
stage, after some processing has already been performed and hence packets
are not coming straight from a pktio interface.
For instance, you may need to decrypt packets and strip the IPSec headers
off, then go through another classification stage. Can this be achieved?

Thanks,
Mario.

On 28/05/2015 10:44, "Bala"  wrote:

>
>I am get pcaps for classification rules but currently the classification
>validation suite creates packets with different values for PMR rules and
>sends them across the loop back interface to test classification
>feature. So if I understand correctly is the pcap file going to recreate
>this scenario?
>
>Regards,
>bala
>On Thursday 28 May 2015 03:08 PM, Mike Holmes wrote:
>> Bala if you can get the pcaps to test the classification rules, I hope
>>the
>> new assignee coming on line shortly will be able to work running them
>>into
>> the validation test suite.
>>
>> On 28 May 2015 at 05:24, Bala Manoharan 
>>wrote:
>>
>>> Hi,
>>>
>>> Yes. Lookback interface should behave like other interfaces in the
>>> system and classification rules if set should get applied.
>>>
>>> Regards,
>>> Bala
>>>
>>> On 28 May 2015 at 14:51, Ola Liljedahl 
>>>wrote:
 Is the loopback interface supposed to be supported in all ODP
 implementations? And it will have the same functionality as real pktio
 interfaces?

 I was thinking of feeding the loopback interface packets that are read
>>> from
 a pcap file. Classification rules could then be associated with the
>>> loopback
 interface and packets will eventually be enqueued on the queues
>>> specified in
 the matching class of service.

 -- Ola


 ___
 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


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

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

Re: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0 len on odp_packet_alloc()

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

 * ... The
 * packet is initialized with data pointers and lengths set according to the
 * specified len, ...

The current documentation covers functionality also when len is 0. We should 
minimize @note content over all the APIs, otherwise the actual API spec gets 
fragmented. API documentation and functionality is the same for len == 0, len 
== 1, ... In all the cases, implementation decides on packet segmentation in 
limits of pool parameters.

If needed, we could add:

@note Zero is a valid 'len' value


-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext
> Bill Fischofer
> Sent: Wednesday, May 27, 2015 6:51 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH 2/2] api-next: packet: clarify use of 0
> len on odp_packet_alloc()
> 
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/packet.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/include/odp/api/packet.h b/include/odp/api/packet.h
> index 3a454b5..ea124df 100644
> --- a/include/odp/api/packet.h
> +++ b/include/odp/api/packet.h
> @@ -73,6 +73,16 @@ extern "C" {
>   * @note The default headroom and tailroom used for packets is specified
> by
>   * the ODP_CONFIG_PACKET_HEADROOM and ODP_CONFIG_PACKET_TAILROOM defines
> in
>   * odp_config.h.
> + *
> + * @note The len parameter sets the initial length of the allocated
> packet.
> + * If specified as 0, the implementation will allocate a packet of a
> default
> + * length chosen by the implementation based on the pool create
> parameters
> + * and will then set the actual length of the packet to 0. The result is
> + * the same as if the following sequence had been called by the
> application:
> + * @code
> + * pkt = odp_packet_alloc(pool, default_len);
> + * odp_packet_reset(pkt, 0);
> + * @endcode
>   */
>  odp_packet_t odp_packet_alloc(odp_pool_t pool, uint32_t len);
> 
> --
> 2.1.0
> 
> ___
> 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] loopback interface

[Bala]

I am get pcaps for classification rules but currently the classification 
validation suite creates packets with different values for PMR rules and 
sends them across the loop back interface to test classification 
feature. So if I understand correctly is the pcap file going to recreate 
this scenario?


Regards,
bala
On Thursday 28 May 2015 03:08 PM, Mike Holmes wrote:

Bala if you can get the pcaps to test the classification rules, I hope the
new assignee coming on line shortly will be able to work running them into
the validation test suite.

On 28 May 2015 at 05:24, Bala Manoharan  wrote:


Hi,

Yes. Lookback interface should behave like other interfaces in the
system and classification rules if set should get applied.

Regards,
Bala

On 28 May 2015 at 14:51, Ola Liljedahl  wrote:

Is the loopback interface supposed to be supported in all ODP
implementations? And it will have the same functionality as real pktio
interfaces?

I was thinking of feeding the loopback interface packets that are read

from

a pcap file. Classification rules could then be associated with the

loopback

interface and packets will eventually be enqueued on the queues

specified in

the matching class of service.

-- Ola


___
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] loopback interface

[Mike Holmes]

Bala if you can get the pcaps to test the classification rules, I hope the
new assignee coming on line shortly will be able to work running them into
the validation test suite.

On 28 May 2015 at 05:24, Bala Manoharan  wrote:

> Hi,
>
> Yes. Lookback interface should behave like other interfaces in the
> system and classification rules if set should get applied.
>
> Regards,
> Bala
>
> On 28 May 2015 at 14:51, Ola Liljedahl  wrote:
> > Is the loopback interface supposed to be supported in all ODP
> > implementations? And it will have the same functionality as real pktio
> > interfaces?
> >
> > I was thinking of feeding the loopback interface packets that are read
> from
> > a pcap file. Classification rules could then be associated with the
> loopback
> > interface and packets will eventually be enqueued on the queues
> specified in
> > the matching class of service.
> >
> > -- Ola
> >
> >
> > ___
> > 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
>



-- 
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] loopback interface

[Bala Manoharan]

Hi,

Yes. Lookback interface should behave like other interfaces in the
system and classification rules if set should get applied.

Regards,
Bala

On 28 May 2015 at 14:51, Ola Liljedahl  wrote:
> Is the loopback interface supposed to be supported in all ODP
> implementations? And it will have the same functionality as real pktio
> interfaces?
>
> I was thinking of feeding the loopback interface packets that are read from
> a pcap file. Classification rules could then be associated with the loopback
> interface and packets will eventually be enqueued on the queues specified in
> the matching class of service.
>
> -- Ola
>
>
> ___
> 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] loopback interface

[Ola Liljedahl]

Is the loopback interface supposed to be supported in all ODP
implementations? And it will have the same functionality as real pktio
interfaces?

I was thinking of feeding the loopback interface packets that are read from
a pcap file. Classification rules could then be associated with the
loopback interface and packets will eventually be enqueued on the queues
specified in the matching class of service.

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

Re: [lng-odp] [PATCH 1/2] test: helper: add ring test

[Mike Holmes]

On 28 May 2015 at 02:43, Christophe Milard 
wrote:

> Hi Mike,
>
> Got:
> PASS: odp_thread
> PASS: odp_process
> ../../../test-driver: line 107:  7705 Segmentation fault  (core
> dumped) "$@" > $log_file 2>&1
> FAIL: odp_ring
> when running
> PATCH_DIR=/home/erachmi/incoming ./apply-and-build.sh
> (check-odp)
>
>
Thanks, will take a look



>
> On 27 May 2015 at 19:39, Mike Holmes  wrote:
>
>> Signed-off-by: Mike Holmes 
>> ---
>>  helper/test/.gitignore  |   1 +
>>  helper/test/Makefile.am |   4 +-
>>  helper/test/odp_ring.c  | 556
>> 
>>  3 files changed, 560 insertions(+), 1 deletion(-)
>>  create mode 100644 helper/test/odp_ring.c
>>
>> diff --git a/helper/test/.gitignore b/helper/test/.gitignore
>> index fe65f30..c4fd3d1 100644
>> --- a/helper/test/.gitignore
>> +++ b/helper/test/.gitignore
>> @@ -2,3 +2,4 @@
>>  *.log
>>  odp_process
>>  odp_thread
>> +odp_ring
>> diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
>> index f330533..a511f67 100644
>> --- a/helper/test/Makefile.am
>> +++ b/helper/test/Makefile.am
>> @@ -6,7 +6,8 @@ AM_LDFLAGS += -static
>>  TESTS_ENVIRONMENT = ODP_PLATFORM=${with_platform} TEST_DIR=${builddir}
>>
>>  EXECUTABLES = odp_thread \
>> -  odp_process
>> +  odp_process \
>> +  odp_ring
>>
>>  COMPILE_ONLY =
>>
>> @@ -23,3 +24,4 @@ bin_PROGRAMS = $(EXECUTABLES) $(COMPILE_ONLY)
>>
>>  dist_odp_thread_SOURCES = odp_thread.c
>>  dist_odp_process_SOURCES = odp_process.c
>> +dist_odp_ring_SOURCES = odp_ring.c
>> diff --git a/helper/test/odp_ring.c b/helper/test/odp_ring.c
>> new file mode 100644
>> index 000..5c4f229
>> --- /dev/null
>> +++ b/helper/test/odp_ring.c
>> @@ -0,0 +1,556 @@
>> +/* Copyright (c) 2015, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +/*-
>> + *   BSD LICENSE
>> + *
>> + *   Copyright(c) 2010-2013 Intel Corporation. All rights reserved.
>> + *   All rights reserved.
>> + *
>> + *   Redistribution and use in source and binary forms, with or without
>> + *   modification, are permitted provided that the following conditions
>> + *   are met:
>> + *
>> + * * Redistributions of source code must retain the above copyright
>> + *   notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above
>> copyright
>> + *   notice, this list of conditions and the following disclaimer in
>> + *   the documentation and/or other materials provided with the
>> + *   distribution.
>> + * * Neither the name of Intel Corporation nor the names of its
>> + *   contributors may be used to endorse or promote products derived
>> + *   from this software without specific prior written permission.
>> + *
>> + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>> FOR
>> + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>> INCIDENTAL,
>> + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>> USE,
>> + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>> ANY
>> + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
>> USE
>> + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +/**
>> + * @file
>> + *
>> + * ODP test ring
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define RING_SIZE 4096
>> +#define MAX_BULK 32
>> +
>> +#define RING_TEST_BASIC
>> +#define MAX_WORKERS 32 /**< Maximum number of work threads */
>> +
>> +/* Globals */
>> +static odph_linux_pthread_t thread_tbl[MAX_WORKERS]; /**< worker threads
>> table*/
>> +static int num_workers;/**< number
>> of workers */
>> +
>> +typedef enum {
>> +   ODP_ATOMIC_TEST = 0,
>> +   ODP_SHM_TEST,
>> +   ODP_RING_TEST_BASIC,
>> +   ODP_RING_TEST_STRESS,
>> +   ODP_TIMER_PING_TEST,
>> +   ODP_MAX_TEST
>> +} odp_test_case_e;
>> +
>> +/**
>> + * Thread argument
>> + */
>> +typedef struct {
>> +   int testcase; /**< specifies which set of API's to exercise */
>> +   int numthrds; /**< no of pthreads to create */
>> +} pthrd_arg;
>> +
>> +/**
>> + * Print system information
>> + */
>> +static void odp_print_system_info(void)
>> +{
>> +   odp_cpumask_t cpumask;
>> +   char str[ODP_CPUMASK_STR_SIZE];
>> +
>> +   memset(str, 1, sizeof(str));
>> +
>> +   odp_cpumask_zero(&cpumask);
>> +
>> +   odp_cpumask_from_str(&cpumask, "

[lng-odp] [PATCH] validation: schedule: fix maybe-uninitialized warnings when odp_schedule() compile as inline function

[Jerin Jacob]

use of CU_ASSERT(from == queue) in 'test_schedule_pause_resume'
odp_schedule.c: In function 'test_schedule_pause_resume':
odp_schedule.c:573:3: error: 'from' may be used uninitialized
in this function [-Werror=maybe-uninitialized]

use of CU_ASSERT(from != ODP_QUEUE_INVALID) in 'schedule_common_'
odp_schedule.c: In function 'schedule_common_':
odp_schedule.c:218:4: error: 'from' may be used uninitialized
in this function [-Werror=maybe-uninitialized]

Signed-off-by: Jerin Jacob 
---
 test/validation/odp_scheduler.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/test/validation/odp_scheduler.c b/test/validation/odp_scheduler.c
index a3ac505..c2eb996 100644
--- a/test/validation/odp_scheduler.c
+++ b/test/validation/odp_scheduler.c
@@ -179,7 +179,7 @@ static void *schedule_common_(void *arg)
while (1) {
odp_event_t ev;
odp_buffer_t buf;
-   odp_queue_t from;
+   odp_queue_t from = ODP_QUEUE_INVALID;
int num = 0;
int locked;
 
@@ -569,6 +569,7 @@ static void test_schedule_pause_resume(void)
}
 
for (i = 0; i < NUM_BUFS_BEFORE_PAUSE; i++) {
+   from = ODP_QUEUE_INVALID;
ev = odp_schedule(&from, ODP_SCHED_NO_WAIT);
CU_ASSERT(from == queue);
buf = odp_buffer_from_event(ev);
-- 
2.1.0

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