Petri Savolainen(psavol) replied on github web page:
platform/linux-generic/odp_packet.c
line 21
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_p
yes, discovery is done by other tools like lspci, /proc and /sys
interfaces. Also udev rules are there to make naming persistent.
For pci it can be:
odp_pktio_open("mdev:eth0")
then you parse /proc/bus/pci/devices to find actual driver used for this
eth0. And if you have matching mdev pktio dri
Well, we do not need to scan all the platform because the pktio_open
contains enough information to target the right device.
This is almost true as we need to have an additional "selector" for the
port on multiport NICs that are controlled by a single pci ID.
:: or something like that.
All ports m
Hi,
you probably already received this invitation directly, but I think this is
an opportunity to illustrate ODP concrete usages.
If your company policies allow responding to the survey, please do.
Cordially,
François-Frédéric
-- Forwarded message --
From: SDxCentral
Date: 25 O
From: Petri Savolainen
Test packet pool subparameters when those are supported.
Signed-off-by: Petri Savolainen
---
/** Email created from pull request 234 (psavol:next-pool-param)
** https://github.com/Linaro/odp/pull/234
** Patch: https://github.com/Linaro/odp/pull/234.patch
** Base sha: d
Added packet pool parameters for more fine grained pool
configuration. The basic usage of the parameters is not changed,
except that implementation may now round up 'num' by default.
Application can limit the round up with new 'max_num' parameter.
If application does not limit max_num (but is still
From: Petri Savolainen
Use odp_pool_param_init() to initialize pool parameters.
Signed-off-by: Petri Savolainen
---
/** Email created from pull request 234 (psavol:next-pool-param)
** https://github.com/Linaro/odp/pull/234
** Patch: https://github.com/Linaro/odp/pull/234.patch
** Base sha: d
From: Petri Savolainen
Packet pool parameters does not require application to specify
the maximum number of packet. Application is more portable, if
it does not restrict max_num, but instead uses this info field
after pool creation.
Signed-off-by: Petri Savolainen
---
/** Email created from pul
From: Petri Savolainen
Added packet pool parameter 'max_num', so that 'num' parameter
can be round up by the implementation. Most implementations have
a fixed segment size, and need this flexibility. For example,
when 'len' is larger than the pool segment size, there may be
e.g. 2 x 'num' segment
From: Petri Savolainen
Additional packet length and number specification gives
more information to implementation about intended packet
length distribution in the pool. This enables e.g. correct
initialization when pool implementation is based on multiple
fixed packet / segment sizes (subpools).
From: Petri Savolainen
Added odp_pool_info() test for packet pools.
Signed-off-by: Petri Savolainen
---
/** Email created from pull request 234 (psavol:next-pool-param)
** https://github.com/Linaro/odp/pull/234
** Patch: https://github.com/Linaro/odp/pull/234.patch
** Base sha: d61d32590d177
From: Petri Savolainen
Implemented max_num info for packet pools.
Signed-off-by: Petri Savolainen
---
/** Email created from pull request 234 (psavol:next-pool-param)
** https://github.com/Linaro/odp/pull/234
** Patch: https://github.com/Linaro/odp/pull/234.patch
** Base sha: d61d32590d1772b
From: Petri Savolainen
Remove anonymous union from pool parameter structure.
Union makes it impossible to initialize parameters per
pool type (use other values than all zeros). This change
is not visible to applications (union was anonymous).
Signed-off-by: Petri Savolainen
---
/** Email create
Ilias Apalodimas(apalos) replied on github web page:
platform/linux-generic/odp_packet.c
line 24
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_p
Petri Savolainen(psavol) replied on github web page:
platform/linux-generic/odp_packet.c
line 24
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_p
Petri Savolainen(psavol) replied on github web page:
platform/linux-generic/odp_packet.c
line 24
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_p
Ilias Apalodimas(apalos) replied on github web page:
platform/linux-generic/odp_packet.c
line 24
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_p
Hi Maxim,
This is exactly what we have in mind for the mediated device design.
Regards
Ilias
On 27 October 2017 at 10:25, Maxim Uvarov wrote:
> yes, discovery is done by other tools like lspci, /proc and /sys
> interfaces. Also udev rules are there to make naming persistent.
>
> For pci it ca
Branch: refs/heads/api-next
Home: https://github.com/Linaro/odp
Commit: 201a96f9bbcbabd904362ba05a179c72689a578e
https://github.com/Linaro/odp/commit/201a96f9bbcbabd904362ba05a179c72689a578e
Author: Maxim Uvarov
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M scrip
This should not be limited to pci .
The good news is that with netmdev you start with /sys/class/net and can
find what you need. Actually you even do NOT need pci pus information from
/sys/bus/pci because netmdev provides what you need in a bus independent
manner.
FF
Le ven. 27 oct. 2017 à 10:11
The 10/27/2017 10:25, Maxim Uvarov wrote:
> yes, discovery is done by other tools like lspci, /proc and /sys
> interfaces. Also udev rules are there to make naming persistent.
>
> For pci it can be:
>
> odp_pktio_open("mdev:eth0")
>
> then you parse /proc/bus/pci/devices to find actual driver used
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
github
/** Email created from pull request 263 (muvarov:master_fixscripts)
** https://github.com/Linaro/odp/pull/263
** Patch: https://github.com/Linaro/odp/pull/263.patch
** Base sha: 3edee38da55876e36f
From: Maxim Uvarov
Signed-off-by: Maxim Uvarov
---
/** Email created from pull request 263 (muvarov:master_fixscripts)
** https://github.com/Linaro/odp/pull/263
** Patch: https://github.com/Linaro/odp/pull/263.patch
** Base sha: 3edee38da55876e36f654a5d1a4b87c2ea5b8bfe
** Merge commit sha: 7
In the case of netmdev the device is still there. Please check with Ilias
for detailed behavior of this technology
FF
Le ven. 27 oct. 2017 à 10:29, Jianbo Liu a écrit :
> The 10/27/2017 10:25, Maxim Uvarov wrote:
> > yes, discovery is done by other tools like lspci, /proc and /sys
> > interfac
> -Original Message-
> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
> Sent: Thursday, October 26, 2017 3:45 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) ;
> Github ODP bot ; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH API-NEXT v4 1/3] api: ipsec:
Petri Savolainen(psavol) replied on github web page:
include/README
line 15
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP AP
Balasubramanian Manoharan(bala-manoharan) replied on github web page:
include/odp/api/spec/classification.h
line 48
@@ -206,6 +213,53 @@ typedef struct odp_cls_cos_param {
/** Drop policy associated with CoS */
odp_cls_drop_t drop_policy;
+
+ /** Random Early Detection (RED
Petri Savolainen(psavol) replied on github web page:
include/README
line 15
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP AP
Balasubramanian Manoharan(bala-manoharan) replied on github web page:
platform/linux-generic/odp_classification.c
line 1
@@ -190,6 +190,8 @@ int odp_cls_capability(odp_cls_capability_t *capability)
capability->supported_terms.bit.tcp_sport = 1;
Comment:
Will do in next version.
> muvaro
Signed-off-by: Dmitry Eremin-Solenikov
---
.travis.yml | 8
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 49b922e3cdba..fdeeefd113ea 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -244,6 +244,14 @@ jobs:
- ./configure --prefix=$HO
Signed-off-by: Dmitry Eremin-Solenikov
---
.travis.yml | 4
1 file changed, 4 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index fdeeefd113ea..6196f91d41de 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -74,6 +74,10 @@ env:
- CROSS_ARCH="armhf" CFLAGS="-march=armv7-a"
__odp_force is not part of ODP API, so it should not be used directly.
Signed-off-by: Dmitry Eremin-Solenikov
---
platform/linux-generic/odp_ipsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/platform/linux-generic/odp_ipsec.c
b/platform/linux-generic/odp_ipsec.c
index
__odp_force is not part of ODP API, so it should not be used directly.
Signed-off-by: Dmitry Eremin-Solenikov
---
helper/include/odp/helper/chksum.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/helper/include/odp/helper/chksum.h
b/helper/include/odp/helper/chksum.h
index
This is a copy of https://github.com/Linaro/odp/pull/250, since mailer
scripts won't send huge patch series.
This patch serie is based on discussions during SFO17.
My main goals were:
- providing full set of ABI headers to be used by other implementations
- restructuring existing headers, to pr
Signed-off-by: Dmitry Eremin-Solenikov
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 4bc77500c279..255de960c180 100644
--- a/configure.ac
+++ b/configure.ac
@@ -271,6 +271,7 @@ AC_ARG_ENABLE([abi-compat],
ODP_LIBSO_VERSION=0:0:0
Signed-off-by: Dmitry Eremin-Solenikov
---
Makefile.inc | 12
example/Makefile.inc | 12
helper/Makefile.am | 12
helper/test/Makefile.am
Install ABI headers directly to odp/api/abi, removing the need for extra
symlink.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/include/Makefile.am b/include/Makefile.am
index 5328133dd4e4..d841e65b
There is no need to install ABI headers (or to have them in include
path) in non-ABI-compat mode, they should not be used at all. Still
provide default ABI headers, because platform may depend on them.
Signed-off-by: Dmitry Eremin-Solenikov
---
Makefile.inc| 6 +-
include/Makefile.am
Signed-off-by: Dmitry Eremin-Solenikov
---
include/odp/api/spec/queue.h | 5 -
platform/linux-generic/include/odp/api/queue.h | 12
2 files changed, 17 deletions(-)
diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
index 73598be06d93..3c
Signed-off-by: Dmitry Eremin-Solenikov
---
include/odp/api/spec/classification.h | 11 ---
platform/linux-generic/include/odp/api/classification.h | 13 -
2 files changed, 24 deletions(-)
diff --git a/include/odp/api/spec/classification.h
b/include/odp/api/
Change defines guarding inclusion of ODP API spec files from ODP_API_FOO
to ODP_API_SPEC_FOO, as they are placed in odp/api/spec/foo.h path.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/odp/api/spec/align.h | 4 ++--
include/odp/api/spec/atomic.h | 4 ++--
include/
Provide a set of platform-neutral ABI files. They are mostly modified
versions of linux-generic api files.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 188 -
include/odp/arch/arm32-linux/odp/api/abi/atomic.h | 7 +
includ
Reduce amount of directory levels by moving default ABI headers to
odp/api/abi-default.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 82 +++---
.../default/api/abi => api/abi-default}/atomic.h | 0
.../default/api/abi => api/a
Move the rest of ODP_SCHED_GROUP_* defines to schedule_types.h to remove
duplication between headers.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/odp/api/abi-default/schedule.h | 8
include/odp/api/abi-default/schedule_types.h | 8
include/odp/api/spec/schedule.h
Rework more platform headers to use odp/api/abi/ subdir instead of
odp/api/plat/.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 8 +
.../include => include}/odp/api/barrier.h | 6 ++--
.../include => include}/odp/api/buffer.h
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 1 +
include/odp/api/atomic.h | 28 +++
platform/linux-generic/Makefile.am | 3 +-
.../odp/api/abi/atomic.h} | 14 ++
Rewrite atomic_types.h/atomic_inlines.h to clearly separate simple
(common) and locked 64-bit cases. This is allows us to ease switching of
atomic header to abi setup.
Signed-off-by: Dmitry Eremin-Solenikov
---
.../include/odp/api/plat/atomic_inlines.h | 315 +
.../i
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 1 +
include/odp/api/byteorder.h| 28 ++
platform/linux-generic/Makefile.am | 3 +-
.../odp/api/abi/byteorder.h} | 15 +--
Signed-off-by: Dmitry Eremin-Solenikov
---
example/traffic_mgmt/odp_traffic_mgmt.c| 1 +
helper/test/linux/process.c| 2 ++
helper/test/linux/pthread.c| 2 ++
helper/threads.c | 1 +
include/Makefile
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 1 +
include/odp/api/sync.h | 28 ++
platform/linux-generic/Makefile.am | 2 +-
.../odp/api => include-abi/odp/api/abi}/sync.h | 12
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am | 1 +
.../include => include}/odp/api/ticketlock.h| 11 +++
platform/linux-generic/Makefile.am | 7 +++
.../odp/api/abi/ticketlock.h} | 21 +
Move more generic headers from platform include dir to common include
dir.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am | 10 ++
{platform/linux-generic/include => include}/odp/api/chksum.h | 12 ++--
.../linux-generic/in
Signed-off-by: Dmitry Eremin-Solenikov
---
include/Makefile.am| 6 ++
.../include => include}/odp/api/classification.h | 2 +-
.../include => include}/odp/api/crypto.h | 2 +-
.../include => include}/odp/api/packet.h | 11 +---
.../include
Several files consist only (or mostly) of functions compiled only if
ODP is compiled in ABI compatibility mode. Instead of having an ifdef
inside, guard them with if ODP_ABI_COMPAT condition in Makefile.am
Signed-off-by: Dmitry Eremin-Solenikov
---
platform/linux-generic/Makefile.am
Split away inclusion of API implementation to the files selected by
Automake.
Signed-off-by: Dmitry Eremin-Solenikov
---
platform/linux-generic/Makefile.am| 2 ++
platform/linux-generic/odp_packet.c | 5 -
platform/linux-generic/odp_packet_api.c | 28 +++
Replace static_inline.h header with unconditional defines of _ODP_INLINE
macro (either to 'static inline' or to empty value) depending on the
compilation place.
Signed-off-by: Dmitry Eremin-Solenikov
---
Makefile.inc | 1 -
platform/linux-generic/.gitignore
There is no point in installing inline headers in non-ABI-compat mode
anymore. They are not included by any other header.
Signed-off-by: Dmitry Eremin-Solenikov
---
platform/linux-generic/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/platform/linux-generic/Makef
With static_inline.h gone, there is no need to
AC_SUBST([ODP_ABI_COMPAT]). Drop it from configure.ac.
Signed-off-by: Dmitry Eremin-Solenikov
---
configure.ac | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 255de960c180..6d74c98b3083 100644
--- a/configure.ac
Provide formal description of files being part of ODP specification,
platform-specific headers, substituting parts of ODP specification and
additional headers supplementing ODP specification.
Signed-off-by: Dmitry Eremin-Solenikov
---
include/README | 77 +
function name already has l3 and l4 layer, argument enable
is more clean here.
Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org
github
/** Email created from pull request 264 (muvarov:api-next_chsum)
** https://github.com/Linaro/odp/pull/264
** Patch: h
From: Maxim Uvarov
function name already has l3 and l4 layer, argument enable
is more clean here.
Signed-off-by: Maxim Uvarov
---
/** Email created from pull request 264 (muvarov:api-next_chsum)
** https://github.com/Linaro/odp/pull/264
** Patch: https://github.com/Linaro/odp/pull/264.patch
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
Dmitry Eremin-Solenikov(lumag) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
Petri Savolainen(psavol) replied on github web page:
include/README
@@ -0,0 +1,76 @@
+ODP specification
+=
+
+ODP specification consists of several types of files, which together provide
+full list of types, values and functions that ODP implemention MUST provide.
+
+ODP API specif
ODP 2.0 assumes Linux system services are available so the question of how
to operate in bare metal environments is a separate one and up to those ODP
implementations. Again the application will provide a
sufficiently-qualified device name string to identify which device it wants
to open in an unam
We have to support both types of drivers as of now:
1) Legacy all user space drivers - In this case, what Jianbo says is correct.
2) net-mdev drivers.
So, DDF has to support both the use cases.
Thank you,
Honnappa
On 27 October 2017 at 04:47, Francois Ozog wrote:
> In the case of netmdev the
On 10/27/17 17:56, Honnappa Nagarahalli wrote:
> We have to support both types of drivers as of now:
>
> 1) Legacy all user space drivers - In this case, what Jianbo says is correct.
> 2) net-mdev drivers.
>
> So, DDF has to support both the use cases.
>
> Thank you,
> Honnappa
>
Generic net-m
Le ven. 27 oct. 2017 à 17:00, Maxim Uvarov a
écrit :
> On 10/27/17 17:56, Honnappa Nagarahalli wrote:
> > We have to support both types of drivers as of now:
> >
> > 1) Legacy all user space drivers - In this case, what Jianbo says is
> correct.
> > 2) net-mdev drivers.
> >
> > So, DDF has to sup
On 27 October 2017 at 09:50, Bill Fischofer
wrote:
> ODP 2.0 assumes Linux system services are available so the question of how
> to operate in bare metal environments is a separate one and up to those ODP
> implementations. Again the application will provide a
> sufficiently-qualified device nam
The problem with scanning, especially in a VNF environment, is that (a) the
application probably isn't authorized to to that and (b) the application
certainly doesn't have real visibility into what the actual device topology
is. It only knows what it "needs to know" (as determined by higher-level
f
On 27 October 2017 at 02:36, Francois Ozog wrote:
> Well, we do not need to scan all the platform because the pktio_open
> contains enough information to target the right device.
> This is almost true as we need to have an additional "selector" for the
> port on multiport NICs that are controlled
Le ven. 27 oct. 2017 à 17:17, Bill Fischofer a
écrit :
> The problem with scanning, especially in a VNF environment, is that (a)
> the application probably isn't authorized to to that
>
nothing prevents scanning what is available for n the vm. "Scale up" Events
are triggered when increasing reso
Le ven. 27 oct. 2017 à 17:31, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> a écrit :
> On 27 October 2017 at 02:36, Francois Ozog
> wrote:
>
>> Well, we do not need to scan all the platform because the pktio_open
>> contains enough information to target the right device.
>> This is alm
muvarov replied on github web page:
platform/linux-generic/odp_packet.c
line 23
@@ -1739,9 +1739,68 @@ void odp_packet_print(odp_packet_t pkt)
seg = odp_packet_next_seg(pkt, seg);
}
- str[len] = '\0';
+ ODP_PRINT("%s\n", str);
+}
+
+void odp_packet_print_data(
On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
> a écrit :
>
>> The problem with scanning, especially in a VNF environment, is that (a)
>> the application probably isn't authorized to to that
>>
>
> nothing prevents scanning what is availa
Branch: refs/heads/api-next
Home: https://github.com/Linaro/odp
Commit: c04eff910a7b18f47365f90fadb6133474e9cae5
https://github.com/Linaro/odp/commit/c04eff910a7b18f47365f90fadb6133474e9cae5
Author: Petri Savolainen
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M i
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: 8d22e0e2013596403ae6a35457cdf30b0a0c559b
https://github.com/Linaro/odp/commit/8d22e0e2013596403ae6a35457cdf30b0a0c559b
Author: Bill Fischofer
Date: 2017-10-26 (Thu, 26 Oct 2017)
Changed paths:
M doc/use
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: fa9533ede03e40f0455c6d889997042f32235fc1
https://github.com/Linaro/odp/commit/fa9533ede03e40f0455c6d889997042f32235fc1
Author: Petri Savolainen
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M inclu
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: 0841edfc364b39fce8c1ed1cdbddecde1d98b42e
https://github.com/Linaro/odp/commit/0841edfc364b39fce8c1ed1cdbddecde1d98b42e
Author: Brian Brooks
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M test/perf
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: 86b8f3d4371b3fd0ec09091b404b829f2e97730d
https://github.com/Linaro/odp/commit/86b8f3d4371b3fd0ec09091b404b829f2e97730d
Author: Matias Elo
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M include/odp
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: 4c1190787a1d48147cbfe7e20c8b31b0b05c94f3
https://github.com/Linaro/odp/commit/4c1190787a1d48147cbfe7e20c8b31b0b05c94f3
Author: Balasubramanian Manoharan
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: 79b1cc361a7e1eb1098d006e0b70c903460d32c7
https://github.com/Linaro/odp/commit/79b1cc361a7e1eb1098d006e0b70c903460d32c7
Author: Maxim Uvarov
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M scripts/D
Branch: refs/heads/next
Home: https://github.com/Linaro/odp
Commit: f4657562b7c2b23e64aaba234820cbe50c2422ec
https://github.com/Linaro/odp/commit/f4657562b7c2b23e64aaba234820cbe50c2422ec
Author: Mykyta Iziumtsev
Date: 2017-10-27 (Fri, 27 Oct 2017)
Changed paths:
M inclu
On 26/10/17 09:57, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> We need one branch that holds all new API changes before those are released
> (> 4 months currently): either it's master or api-next. If we change API
> development to master, then applications would need follow the latest release
Le ven. 27 oct. 2017 à 20:35, Bill Fischofer a
écrit :
> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>> a écrit :
>>
>>> The problem with scanning, especially in a VNF environment, is that (a)
>>> the application probably isn't a
On 27 October 2017 at 13:35, Bill Fischofer
wrote:
>
>
> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>> a écrit :
>>
>>> The problem with scanning, especially in a VNF environment, is that (a)
>>> the application probably isn't a
Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
honnappa.nagaraha...@linaro.org> a écrit :
> On 27 October 2017 at 13:35, Bill Fischofer
> wrote:
>
>>
>>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>>> a écrit :
>>>
>
On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
> honnappa.nagaraha...@linaro.org> a écrit :
>
>> On 27 October 2017 at 13:35, Bill Fischofer
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog <
>>> francois.o..
Le ven. 27 oct. 2017 à 23:51, Bill Fischofer a
écrit :
> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
> wrote:
>
>>
>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>> honnappa.nagaraha...@linaro.org> a écrit :
>>
>>> On 27 October 2017 at 13:35, Bill Fischofer
>>> wrote:
>>>
On Fri, Oct 27, 2017 at 3:43 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 20:35, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 10:45 AM, Francois Ozog > > wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 17:17, Bill Fischofer
>>> a écrit :
>>>
The problem with scanning, especially
Le ven. 27 oct. 2017 à 23:54, Francois Ozog a
écrit :
> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
>> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>>> honnappa.nagaraha...@linaro.org> a écrit :
>>>
On Fri, Oct 27, 2017 at 4:54 PM, Francois Ozog
wrote:
>
> Le ven. 27 oct. 2017 à 23:51, Bill Fischofer
> a écrit :
>
>> On Fri, Oct 27, 2017 at 4:24 PM, Francois Ozog
>> wrote:
>>
>>>
>>> Le ven. 27 oct. 2017 à 23:05, Honnappa Nagarahalli <
>>> honnappa.nagaraha...@linaro.org> a écrit :
>>>
>>>
96 matches
Mail list logo
