[lng-odp] [API-NEXTv2] api: ipsec: reorganize odp_ipsec_sa_param_t structure based on SA direction
Signed-off-by: Bogdan Pricope --- include/odp/api/spec/ipsec.h | 114 --- 1 file changed, 63 insertions(+), 51 deletions(-) diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index e602e4b..5373ede 100644 --- a/include/odp/api/spec/ipsec.h +++ b/include/odp/api/spec/ipsec.h @@ -604,8 +604,8 @@ typedef enum odp_ipsec_ip_version_t { * IPSEC Security Association (SA) parameters */ typedef struct odp_ipsec_sa_param_t { - /** IPSEC SA direction: inbound or outbound */ - odp_ipsec_dir_t dir; + /** SPI value */ + uint32_t spi; /** IPSEC protocol: ESP or AH */ odp_ipsec_protocol_t proto; @@ -616,51 +616,12 @@ typedef struct odp_ipsec_sa_param_t { /** Parameters for crypto and authentication algorithms */ odp_ipsec_crypto_param_t crypto; - /** Parameters for tunnel mode */ - odp_ipsec_tunnel_param_t tunnel; - - /** Fragmentation mode */ - odp_ipsec_frag_mode_t frag_mode; - - /** Various SA option flags */ - odp_ipsec_sa_opt_t opt; - /** SA lifetime parameters */ odp_ipsec_lifetime_t lifetime; - /** SA lookup mode */ - odp_ipsec_lookup_mode_t lookup_mode; - - /** Minimum anti-replay window size. Use 0 to disable anti-replay - * service. */ - uint32_t antireplay_ws; - /** Initial sequence number */ uint64_t seq; - /** SPI value */ - uint32_t spi; - - /** Additional inbound SA lookup parameters. Values are considered -* only in ODP_IPSEC_LOOKUP_DSTADDR_SPI lookup mode. */ - struct { - /** Select IP version -*/ - odp_ipsec_ip_version_t ip_version; - - /** IP destination address (NETWORK ENDIAN) */ - void*dst_addr; - - } lookup_param; - - /** MTU for outbound IP fragmentation offload -* -* This is the maximum length of IP packets that outbound IPSEC -* operations may produce. The value may be updated later with -* odp_ipsec_mtu_update(). -*/ - uint32_t mtu; - /** Select pipelined destination for resulting events * * Asynchronous and inline modes generate events. Select where @@ -677,16 +638,67 @@ typedef struct odp_ipsec_sa_param_t { */ odp_queue_t dest_queue; - /** Classifier destination CoS for resulting packets -* -* Successfully decapsulated packets are sent to classification -* through this CoS. Other resulting events are sent to 'dest_queue'. -* This field is considered only when 'pipeline' is -* ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio -* interface default CoS. The maximum number of different CoS supported -* is defined by IPSEC capability max_cls_cos. -*/ - odp_cos_t dest_cos; + /** IPSEC SA direction: inbound or outbound */ + odp_ipsec_dir_t dir; + + /** IPSEC SA direction dependent parameters */ + union { + /** Inbound specific parameters */ + struct { + /** SA lookup mode */ + odp_ipsec_lookup_mode_t lookup_mode; + + /** Additional inbound SA lookup parameters. Values are + * considered only in ODP_IPSEC_LOOKUP_DSTADDR_SPI + * lookup mode. */ + struct { + /** Select IP version + */ + odp_ipsec_ip_version_t ip_version; + + /** IP destination address (NETWORK ENDIAN) */ + void*dst_addr; + + } lookup_param; + + /** Minimum anti-replay window size. Use 0 to disable + * anti-replay service. */ + uint32_t antireplay_ws; + + /** Classifier destination CoS for resulting packets + * + * Successfully decapsulated packets are sent to + * classification through this CoS. Other resulting + * events are sent to 'dest_queue'. + * This field is considered only when 'pipeline' is + * ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared + * between any pktio interface default CoS. The maximum + * number of different CoS supported is defined by + * IPSEC capability max_cls_cos. + */ + odp_cos_t dest_cos; + } inbound; + + /** Outbound specific parameters */ + struct { + /** Parameters for tunnel mode */ + odp_
[lng-odp] [API-NEXTv2] api: ipsec: reorganize odp_ipsec_sa_param_t structure
Reorganize odp_ipsec_sa_param_t structure to highlight inbound only and outbound only members. To be applied on top of Petri's v3 of 'IPSEC packet event' v2: Set names for inbound only and outbound only struct members Bogdan Pricope (1): api: ipsec: reorganize odp_ipsec_sa_param_t structure based on SA direction include/odp/api/spec/ipsec.h | 114 --- 1 file changed, 63 insertions(+), 51 deletions(-) -- 1.9.1
Re: [lng-odp] Need to standardize tools version
On Thu, Jun 22, 2017 at 3:03 AM, Honnappa Nagarahalli wrote: > Why is it Hard? It is a matter of documenting/advertising which > versions we are using in CI and making that as a minimum standard. If > someone has a different compiler they can always submit the patches > for their compilers. > I second this opinion as I also had same question in last weekly public call. if using a travis CI a way to go then it will be helpful if could be documented as minimum acceptance criteria for patches with bit of pointers on how to use it to help novice user like me. Thanks Shally > On 21 June 2017 at 14:49, Maxim Uvarov wrote: >> it's very hard to standardize tools and compiler version. For now to >> validate patches we use Linaro CI (odp-check scripts) and Travis CI >> which is based on some stable ubuntu version. Also we really want >> that all people can download odp, compile it and run. It's very rare >> case if different tools introduce issues but some times it happen. >> If such issue is found before patch submission it has to be fixed before. >> >> Maxim. >> >> On 06/21/17 22:19, Bill Fischofer wrote: >>> On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli >>> wrote: On 21 June 2017 at 12:23, Bill Fischofer wrote: > ODP is fairly open-ended in this regard because in theory we're only > dependent on > > - A C99-conforming compiler > - A platform that supports a reasonably recent Linux kernel > > Today we do test on 32 and 64 bit systems, and try to support both GCC > and clang, however as newer versions of these tools get released we > sometimes encounter problems. The same is true with older releases. We > try to accommodate, especially when the fix to support a wider range > of tools and platforms is relatively straightforward. > > It's not possible to test exhaustively on every possible combination > so when problems occur we open and fix bugs. However, once we fix a > bug we prefer to fix it only once, which means that in-flight patches > should be checked to see if they have a similar problem and should be > revised to avoid that problem as well. That way we don't fix the same > problem multiple times. > Agree. For anyone to submit a patch, they need to have a reference of what needs to be done. Scalable scheduler is an example, where we have been discovering at every patch that there is a new thing that needs to be done to accept the patch. If it was known upfront, we can work on them from day 1. This sets up the expectation and saves time for everyone, knowing that the patch works for this minimum acceptance criteria. For ex: I do not know how many times you have tried to compile the code and discovered that it does not compile. I would like to avoid those problems. >>> >>> That's what we're trying to do with CI and Travis. In this specific >>> case Petri discovered an issue that effected an older LTS level of >>> Ubuntu and provided a simple fix to the issue. So I don't see a >>> problem with propagating that fix as Brian seems to have confirmed >>> that the fix is good. >>> > > On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli > wrote: >> Along with this, we need to standardize 32b/64b compilations and the >> platforms on which we run the test cases. >> Thanks, >> Honnappa >> >> On 21 June 2017 at 11:38, Honnappa Nagarahalli >> wrote: >>> Hi, >>>I think there is a need to identify tools and specific versions of >>> the tools from patch acceptance perspective. Any failures outside of >>> these versions should be the responsibility of the person facing the >>> issues, they should submit a patch for those versions and tools. >>> >>> Travis CI is a step in that direction. But I think we still allow >>> submissions of patches via email. So, for this case, should we >>> standardize the tools and versions being used in Travis CI as the >>> acceptance criteria? >>> >>> Thanks, >>> Honnappa >>
Re: [lng-odp] [CLOUD-DEV] ddf: examples: add ddf module skeleton and ddf application
Hi, Bogdan This looks good to me as an evaluation example of the DDF, two comments: 1, Copyright (c) 2014, Linaro Limited needs to be updated. 2, make distcheck failures: Making all in ddf_ifs make[3]: Entering directory '/home/yihe01/workspace/odp-linux/opendataplane-1.14.0.0/_build/sub/example/ddf_ifs' CC ddf_ifs.lo CC ddf_ifs_enumr_class.lo CC ddf_ifs_enumr_dpdk.lo ../../../../example/ddf_ifs/ddf_ifs_enumr_dpdk.c:9:25: fatal error: ddf_ifs_api.h: No such file or directory compilation terminated. thanks and best regards, Yi On 21 June 2017 at 16:10, Bogdan Pricope wrote: > Signed-off-by: Bogdan Pricope > --- > example/Makefile.am | 4 +- > example/ddf_app/Makefile.am | 10 > example/ddf_app/odp_ddf_app.c | 49 +++ > example/ddf_ifs/Makefile.am | 26 ++ > example/ddf_ifs/ddf_ifs.c | 28 +++ > example/ddf_ifs/ddf_ifs.h | 18 +++ > example/ddf_ifs/ddf_ifs_api.h | 25 ++ > example/ddf_ifs/ddf_ifs_dev_dpdk.c | 25 ++ > example/ddf_ifs/ddf_ifs_dev_dpdk.h | 24 + > example/ddf_ifs/ddf_ifs_devio_direct.c | 51 +++ > example/ddf_ifs/ddf_ifs_devio_direct.h | 20 > example/ddf_ifs/ddf_ifs_driver.c| 69 ++ > example/ddf_ifs/ddf_ifs_driver.h| 20 > example/ddf_ifs/ddf_ifs_enumr_class.c | 47 ++ > example/ddf_ifs/ddf_ifs_enumr_class.h | 20 > example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 > + > example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 > example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++ > example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 > example/ddf_ifs/odp.conf| 4 ++ > example/m4/configure.m4 | 2 + > 21 files changed, 624 insertions(+), 1 deletion(-) > create mode 100644 example/ddf_app/Makefile.am > create mode 100644 example/ddf_app/odp_ddf_app.c > create mode 100644 example/ddf_ifs/Makefile.am > create mode 100644 example/ddf_ifs/ddf_ifs.c > create mode 100644 example/ddf_ifs/ddf_ifs.h > create mode 100644 example/ddf_ifs/ddf_ifs_api.h > create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c > create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h > create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c > create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h > create mode 100644 example/ddf_ifs/ddf_ifs_driver.c > create mode 100644 example/ddf_ifs/ddf_ifs_driver.h > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c > create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h > create mode 100644 example/ddf_ifs/odp.conf > > diff --git a/example/Makefile.am b/example/Makefile.am > index dfc07b6..b209585 100644 > --- a/example/Makefile.am > +++ b/example/Makefile.am > @@ -8,4 +8,6 @@ SUBDIRS = classifier \ > switch \ > time \ > timer \ > - traffic_mgmt > + traffic_mgmt \ > + ddf_ifs \ > + ddf_app > diff --git a/example/ddf_app/Makefile.am b/example/ddf_app/Makefile.am > new file mode 100644 > index 000..e654202 > --- /dev/null > +++ b/example/ddf_app/Makefile.am > @@ -0,0 +1,10 @@ > +include $(top_srcdir)/example/Makefile.inc > + > +bin_PROGRAMS = odp_ddf_app$(EXEEXT) > +odp_ddf_app_LDFLAGS = $(AM_LDFLAGS) -shared > +odp_ddf_app_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example > + > +noinst_HEADERS = \ > + $(top_srcdir)/example/example_debug.h > + > +dist_odp_ddf_app_SOURCES = odp_ddf_app.c > diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c > new file mode 100644 > index 000..c2d7abf > --- /dev/null > +++ b/example/ddf_app/odp_ddf_app.c > @@ -0,0 +1,49 @@ > +/* Copyright (c) 2014, Linaro Limited > + * All rights reserved. > + * > + * SPDX-License-Identifier: BSD-3-Clause > + */ > + > +/** enable strtok */ > +#ifndef _GNU_SOURCE > +#define _GNU_SOURCE > +#endif > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +int main(int argc, char *argv[]) > +{ > + odp_instance_t instance; > + > + (void)argc; > + (void)argv; > + > + EXAMPLE_DBG("Start DDF Application...\n"); > + > + /* Initialize ODP before calling anything else */ > + if (odp_init_global(&instance, NULL, NULL)) { > + EXAMPLE_ERR("Error: ODP global init failed.\n"); > + exit(EXIT_FAILURE); > + } > + > + if (odp_init_local(instance, ODP_THREAD_CONTROL)) { > + EXAMPLE_ERR("Error: ODP local init failed.\n"); > + exit(EXIT_FAILURE); > + } > +
[lng-odp] [PATCH] build: fix conditional compilation of sources
Explicitly add all arch//* files to respective _SOURCES variables instead of using @ARCH_DIR@ substitution. This patch fixes the broken build for ARM, PPC, and MIPS introduced by [1] and the similar issue reported while testing [2]. >From the Autoconf manual [3]: You can't put a configure substitution (e.g., '@FOO@' or '$(FOO)' where FOO is defined via AC_SUBST) into a _SOURCES variable. The reason for this is a bit hard to explain, but suffice to say that it simply won't work. Here be dragons.. [1] https://lists.linaro.org/pipermail/lng-odp/2017-April/030324.html [2] https://lists.linaro.org/pipermail/lng-odp/2017-June/031598.html [3] https://www.gnu.org/software/automake/manual/html_node/Conditional-Sources.html Signed-off-by: Brian Brooks --- configure.ac | 3 +++ platform/linux-generic/Makefile.am | 40 ++ 2 files changed, 35 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 46c7bbd2..45812f66 100644 --- a/configure.ac +++ b/configure.ac @@ -225,6 +225,9 @@ AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"]) AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ]) AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"]) AM_CONDITIONAL([helper_linux], [test x$helper_linux = xyes ]) +AM_CONDITIONAL([ARCH_IS_ARM], [test "x${ARCH_DIR}" = "xarm"]) +AM_CONDITIONAL([ARCH_IS_MIPS64], [test "x${ARCH_DIR}" = "xmips64"]) +AM_CONDITIONAL([ARCH_IS_POWERPC], [test "x${ARCH_DIR}" = "xpowerpc"]) AM_CONDITIONAL([ARCH_IS_X86], [test "x${ARCH_DIR}" = "xx86"]) ## diff --git a/platform/linux-generic/Makefile.am b/platform/linux-generic/Makefile.am index 8dcdebd2..385c5304 100644 --- a/platform/linux-generic/Makefile.am +++ b/platform/linux-generic/Makefile.am @@ -63,8 +63,20 @@ odpapiinclude_HEADERS = \ $(srcdir)/include/odp/api/time.h \ $(srcdir)/include/odp/api/timer.h \ $(srcdir)/include/odp/api/traffic_mngr.h \ - $(srcdir)/include/odp/api/version.h \ - $(srcdir)/arch/@ARCH_DIR@/odp/api/cpu_arch.h + $(srcdir)/include/odp/api/version.h + +if ARCH_IS_ARM +odpapiinclude_HEADERS += $(srcdir)/arch/arm/odp/api/cpu_arch.h +endif +if ARCH_IS_MIPS64 +odpapiinclude_HEADERS += $(srcdir)/arch/mips64/odp/api/cpu_arch.h +endif +if ARCH_IS_POWERPC +odpapiinclude_HEADERS += $(srcdir)/arch/powerpc/odp/api/cpu_arch.h +endif +if ARCH_IS_X86 +odpapiinclude_HEADERS += $(srcdir)/arch/x86/odp/api/cpu_arch.h +endif odpapiplatincludedir= $(includedir)/odp/api/plat odpapiplatinclude_HEADERS = \ @@ -217,20 +229,32 @@ __LIB__libodp_linux_la_SOURCES = \ odp_timer_wheel.c \ odp_traffic_mngr.c \ odp_version.c \ - odp_weak.c \ - arch/@ARCH_DIR@/odp_cpu_arch.c \ - arch/@ARCH_DIR@/odp_sysinfo_parse.c - -__LIB__libodp_linux_la_LIBADD = $(ATOMIC_LIBS) + odp_weak.c +if ARCH_IS_ARM +__LIB__libodp_linux_la_SOURCES += arch/arm/odp_cpu_arch.c \ + arch/arm/odp_sysinfo_parse.c +endif +if ARCH_IS_MIPS64 +__LIB__libodp_linux_la_SOURCES += arch/mips64/odp_cpu_arch.c \ + arch/mips64/odp_sysinfo_parse.c +endif +if ARCH_IS_POWERPC +__LIB__libodp_linux_la_SOURCES += arch/powerpc/odp_cpu_arch.c \ + arch/powerpc/odp_sysinfo_parse.c +endif if ARCH_IS_X86 -__LIB__libodp_linux_la_SOURCES += arch/@ARCH_DIR@/cpu_flags.c +__LIB__libodp_linux_la_SOURCES += arch/x86/odp_cpu_arch.c \ + arch/x86/odp_sysinfo_parse.c \ + arch/x86/cpu_flags.c endif if HAVE_PCAP __LIB__libodp_linux_la_SOURCES += pktio/pcap.c endif +__LIB__libodp_linux_la_LIBADD = $(ATOMIC_LIBS) + # Create symlink for ABI header files. Application does not need to use the arch # specific include path for installed files. install-data-hook: -- 2.13.1
Re: [lng-odp] Need to standardize tools version
Why is it Hard? It is a matter of documenting/advertising which versions we are using in CI and making that as a minimum standard. If someone has a different compiler they can always submit the patches for their compilers. On 21 June 2017 at 14:49, Maxim Uvarov wrote: > it's very hard to standardize tools and compiler version. For now to > validate patches we use Linaro CI (odp-check scripts) and Travis CI > which is based on some stable ubuntu version. Also we really want > that all people can download odp, compile it and run. It's very rare > case if different tools introduce issues but some times it happen. > If such issue is found before patch submission it has to be fixed before. > > Maxim. > > On 06/21/17 22:19, Bill Fischofer wrote: >> On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli >> wrote: >>> On 21 June 2017 at 12:23, Bill Fischofer wrote: ODP is fairly open-ended in this regard because in theory we're only dependent on - A C99-conforming compiler - A platform that supports a reasonably recent Linux kernel Today we do test on 32 and 64 bit systems, and try to support both GCC and clang, however as newer versions of these tools get released we sometimes encounter problems. The same is true with older releases. We try to accommodate, especially when the fix to support a wider range of tools and platforms is relatively straightforward. It's not possible to test exhaustively on every possible combination so when problems occur we open and fix bugs. However, once we fix a bug we prefer to fix it only once, which means that in-flight patches should be checked to see if they have a similar problem and should be revised to avoid that problem as well. That way we don't fix the same problem multiple times. >>> Agree. For anyone to submit a patch, they need to have a reference of >>> what needs to be done. Scalable scheduler is an example, where we have >>> been discovering at every patch that there is a new thing that needs >>> to be done to accept the patch. If it was known upfront, we can work >>> on them from day 1. This sets up the expectation and saves time for >>> everyone, knowing that the patch works for this minimum acceptance >>> criteria. For ex: I do not know how many times you have tried to >>> compile the code and discovered that it does not compile. I would like >>> to avoid those problems. >> >> That's what we're trying to do with CI and Travis. In this specific >> case Petri discovered an issue that effected an older LTS level of >> Ubuntu and provided a simple fix to the issue. So I don't see a >> problem with propagating that fix as Brian seems to have confirmed >> that the fix is good. >> >>> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli wrote: > Along with this, we need to standardize 32b/64b compilations and the > platforms on which we run the test cases. > Thanks, > Honnappa > > On 21 June 2017 at 11:38, Honnappa Nagarahalli > wrote: >> Hi, >>I think there is a need to identify tools and specific versions of >> the tools from patch acceptance perspective. Any failures outside of >> these versions should be the responsibility of the person facing the >> issues, they should submit a patch for those versions and tools. >> >> Travis CI is a step in that direction. But I think we still allow >> submissions of patches via email. So, for this case, should we >> standardize the tools and versions being used in Travis CI as the >> acceptance criteria? >> >> Thanks, >> Honnappa >
Re: [lng-odp] Need to standardize tools version
I am not talking in the context of Petri's GCC 4.8 issue. In general, if there are 16 people and all have their own environment, it is difficult for a patch submitter to have all those 16 environments and make it compile/work for all of them. I am not saying that we do not have multiple versions, but all them needs to be in CI, known to everyone upfront. We need to have that minimum basic set against which the patch compiles and works. Anything beyond that should be addressed by the ones who have specific tools. On 21 June 2017 at 14:19, Bill Fischofer wrote: > On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli > wrote: >> On 21 June 2017 at 12:23, Bill Fischofer wrote: >>> ODP is fairly open-ended in this regard because in theory we're only >>> dependent on >>> >>> - A C99-conforming compiler >>> - A platform that supports a reasonably recent Linux kernel >>> >>> Today we do test on 32 and 64 bit systems, and try to support both GCC >>> and clang, however as newer versions of these tools get released we >>> sometimes encounter problems. The same is true with older releases. We >>> try to accommodate, especially when the fix to support a wider range >>> of tools and platforms is relatively straightforward. >>> >>> It's not possible to test exhaustively on every possible combination >>> so when problems occur we open and fix bugs. However, once we fix a >>> bug we prefer to fix it only once, which means that in-flight patches >>> should be checked to see if they have a similar problem and should be >>> revised to avoid that problem as well. That way we don't fix the same >>> problem multiple times. >>> >> Agree. For anyone to submit a patch, they need to have a reference of >> what needs to be done. Scalable scheduler is an example, where we have >> been discovering at every patch that there is a new thing that needs >> to be done to accept the patch. If it was known upfront, we can work >> on them from day 1. This sets up the expectation and saves time for >> everyone, knowing that the patch works for this minimum acceptance >> criteria. For ex: I do not know how many times you have tried to >> compile the code and discovered that it does not compile. I would like >> to avoid those problems. > > That's what we're trying to do with CI and Travis. In this specific > case Petri discovered an issue that effected an older LTS level of > Ubuntu and provided a simple fix to the issue. So I don't see a > problem with propagating that fix as Brian seems to have confirmed > that the fix is good. > >> >>> >>> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli >>> wrote: Along with this, we need to standardize 32b/64b compilations and the platforms on which we run the test cases. Thanks, Honnappa On 21 June 2017 at 11:38, Honnappa Nagarahalli wrote: > Hi, >I think there is a need to identify tools and specific versions of > the tools from patch acceptance perspective. Any failures outside of > these versions should be the responsibility of the person facing the > issues, they should submit a patch for those versions and tools. > > Travis CI is a step in that direction. But I think we still allow > submissions of patches via email. So, for this case, should we > standardize the tools and versions being used in Travis CI as the > acceptance criteria? > > Thanks, > Honnappa
Re: [lng-odp] [API-NEXT PATCH v9 0/6] A scalable software scheduler
I explained that my review was premature. I had forgotten to check make distcheck. This needs to be fixed prior to merge. On Wed, Jun 21, 2017 at 4:22 PM Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> wrote: > Just wondering here. Why is this being enforced now? Why was this not > enforced when the patch was approved? > > On 21 June 2017 at 15:26, Bill Fischofer > wrote: > > On Wed, Jun 21, 2017 at 3:17 PM, Brian Brooks > wrote: > >> On 06/20 19:38:59, Bill Fischofer wrote: > >>> Now that master has been merged back into api-next I can confirm that > >>> make distcheck fails for 64-bit systems as well, so I need to withdraw > >>> my earlier reviewed-and-tested-by until that is fixed. > >> > >> This appears to be a problem in pristine upstream as well. "make > distcheck" > >> is broken on ARM (and likely all non-x86 archs). > >> > >> The issue is that in platform/linux-generic/Makefile.am "if ARCH_IS_X86" > >> is always true. I have not yet found a workaround.. > > > > Good to know, but with this patch it's also broken for x86. Sounds > > like we have two issues to address. > > > >> > >>> On Mon, Jun 19, 2017 at 6:13 PM, Bill Fischofer > >>> wrote: > >>> > Looks like I posted a wee bit too soon. On a 32-bit system: > >>> > > >>> > bill@Ub16-32:~/linaro/armschedv9$ make distcheck > >>> > make dist-gzip am__post_remove_distdir='@:' > >>> > make[1]: Entering directory '/home/bill/linaro/armschedv9' > >>> > if test -d "opendataplane-1.14.0.0"; then find > >>> > "opendataplane-1.14.0.0" -type d ! -perm -200 -exec chmod u+w {} ';' > >>> > && rm -rf "opendataplane-1.14.0.0" || { sleep 5 && rm -rf > >>> > "opendataplane-1.14.0.0"; }; else :; fi > >>> > test -d "opendataplane-1.14.0.0" || mkdir "opendataplane-1.14.0.0" > >>> > (cd platform/linux-generic && make > >>> > top_distdir=../../opendataplane-1.14.0.0 > >>> > distdir=../../opendataplane-1.14.0.0/platform/linux-generic \ > >>> > am__remove_distdir=: am__skip_length_check=: > am__skip_mode_fix=: distdir) > >>> > make[2]: Entering directory > >>> > '/home/bill/linaro/armschedv9/platform/linux-generic' > >>> > make[2]: *** No rule to make target 'arch/x86/odp_atomic.h', needed > by > >>> > 'distdir'. Stop. > >>> > make[2]: Leaving directory > '/home/bill/linaro/armschedv9/platform/linux-generic' > >>> > Makefile:603: recipe for target 'distdir' failed > >>> > make[1]: *** [distdir] Error 1 > >>> > make[1]: Leaving directory '/home/bill/linaro/armschedv9' > >>> > Makefile:702: recipe for target 'dist' failed > >>> > make: *** [dist] Error 2 > >>> > > >>> > On Mon, Jun 19, 2017 at 6:11 PM, Bill Fischofer > >>> > wrote: > >>> >> For the v9 series: > >>> >> > >>> >> Reviewed-and-tested-by: Bill Fischofer > >>> >> > >>> >> I also verified that there are no conflicts between this series and > >>> >> Petri's queue cleanup patch, so this can apply and run just fine on > >>> >> top of it. Maxim should be able to merge both tomorrow. > >>> >> > >>> >> On Mon, Jun 19, 2017 at 2:12 PM, Brian Brooks > wrote: > >>> >>> This work derives from Ola Liljedahl's prototype [1] which > introduced a > >>> >>> scalable scheduler design based on primarily lock-free algorithms > and > >>> >>> data structures designed to decrease contention. A thread searches > >>> >>> through a data structure containing only queues that are both > non-empty > >>> >>> and allowed to be scheduled to that thread. Strict priority > scheduling is > >>> >>> respected, and (W)RR scheduling may be used within queues of the > same priority. > >>> >>> Lastly, pre-scheduling or stashing is not employed since it is > optional > >>> >>> functionality that can be implemented in the application. > >>> >>> > >>> >>> In addition to scalable ring buffers, the algorithm also uses > unbounded > >>> >>> concurrent queues. LL/SC and CAS variants exist in cases where > absense of > >>> >>> ABA problem cannot be proved, and also in cases where the > compiler's atomic > >>> >>> built-ins may not be lowered to the desired instruction(s). > Finally, a version > >>> >>> of the algorithm that uses locks is also provided. > >>> >>> > >>> >>> Use --enable-schedule-scalable to conditionally compile this > scheduler > >>> >>> into the library. > >>> >>> > >>> >>> [1] > https://lists.linaro.org/pipermail/lng-odp/2016-September/025682.html > >>> >>> > >>> >>> On checkpatch.pl: > >>> >>> - [2/6] and [5/6] have checkpatch.pl issues that are superfluous > >>> >>> > >>> >>> v9: > >>> >>> - Include patch to enable scalable scheduler in Travis CI > >>> >>> - Fix 'make distcheck' > >>> >>> > >>> >>> v8: > >>> >>> - Reword commit messages > >>> >>> > >>> >>> v7: > >>> >>> - Rebase against new modular queue interface > >>> >>> - Duplicate arch files under mips64 and powerpc > >>> >>> - Fix sched->order_lock() > >>> >>> - Loop until all deferred events have been enqueued > >>> >>> - Implement ord_enq_multi() > >>> >>> - Fix ordered_lock/unlock > >>> >>> - Revert stylistic changes > >>> >>> - Add default xfactor
Re: [lng-odp] [API-NEXT PATCH v9 0/6] A scalable software scheduler
Just wondering here. Why is this being enforced now? Why was this not enforced when the patch was approved? On 21 June 2017 at 15:26, Bill Fischofer wrote: > On Wed, Jun 21, 2017 at 3:17 PM, Brian Brooks wrote: >> On 06/20 19:38:59, Bill Fischofer wrote: >>> Now that master has been merged back into api-next I can confirm that >>> make distcheck fails for 64-bit systems as well, so I need to withdraw >>> my earlier reviewed-and-tested-by until that is fixed. >> >> This appears to be a problem in pristine upstream as well. "make distcheck" >> is broken on ARM (and likely all non-x86 archs). >> >> The issue is that in platform/linux-generic/Makefile.am "if ARCH_IS_X86" >> is always true. I have not yet found a workaround.. > > Good to know, but with this patch it's also broken for x86. Sounds > like we have two issues to address. > >> >>> On Mon, Jun 19, 2017 at 6:13 PM, Bill Fischofer >>> wrote: >>> > Looks like I posted a wee bit too soon. On a 32-bit system: >>> > >>> > bill@Ub16-32:~/linaro/armschedv9$ make distcheck >>> > make dist-gzip am__post_remove_distdir='@:' >>> > make[1]: Entering directory '/home/bill/linaro/armschedv9' >>> > if test -d "opendataplane-1.14.0.0"; then find >>> > "opendataplane-1.14.0.0" -type d ! -perm -200 -exec chmod u+w {} ';' >>> > && rm -rf "opendataplane-1.14.0.0" || { sleep 5 && rm -rf >>> > "opendataplane-1.14.0.0"; }; else :; fi >>> > test -d "opendataplane-1.14.0.0" || mkdir "opendataplane-1.14.0.0" >>> > (cd platform/linux-generic && make >>> > top_distdir=../../opendataplane-1.14.0.0 >>> > distdir=../../opendataplane-1.14.0.0/platform/linux-generic \ >>> > am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: >>> > distdir) >>> > make[2]: Entering directory >>> > '/home/bill/linaro/armschedv9/platform/linux-generic' >>> > make[2]: *** No rule to make target 'arch/x86/odp_atomic.h', needed by >>> > 'distdir'. Stop. >>> > make[2]: Leaving directory >>> > '/home/bill/linaro/armschedv9/platform/linux-generic' >>> > Makefile:603: recipe for target 'distdir' failed >>> > make[1]: *** [distdir] Error 1 >>> > make[1]: Leaving directory '/home/bill/linaro/armschedv9' >>> > Makefile:702: recipe for target 'dist' failed >>> > make: *** [dist] Error 2 >>> > >>> > On Mon, Jun 19, 2017 at 6:11 PM, Bill Fischofer >>> > wrote: >>> >> For the v9 series: >>> >> >>> >> Reviewed-and-tested-by: Bill Fischofer >>> >> >>> >> I also verified that there are no conflicts between this series and >>> >> Petri's queue cleanup patch, so this can apply and run just fine on >>> >> top of it. Maxim should be able to merge both tomorrow. >>> >> >>> >> On Mon, Jun 19, 2017 at 2:12 PM, Brian Brooks >>> >> wrote: >>> >>> This work derives from Ola Liljedahl's prototype [1] which introduced a >>> >>> scalable scheduler design based on primarily lock-free algorithms and >>> >>> data structures designed to decrease contention. A thread searches >>> >>> through a data structure containing only queues that are both non-empty >>> >>> and allowed to be scheduled to that thread. Strict priority scheduling >>> >>> is >>> >>> respected, and (W)RR scheduling may be used within queues of the same >>> >>> priority. >>> >>> Lastly, pre-scheduling or stashing is not employed since it is optional >>> >>> functionality that can be implemented in the application. >>> >>> >>> >>> In addition to scalable ring buffers, the algorithm also uses unbounded >>> >>> concurrent queues. LL/SC and CAS variants exist in cases where absense >>> >>> of >>> >>> ABA problem cannot be proved, and also in cases where the compiler's >>> >>> atomic >>> >>> built-ins may not be lowered to the desired instruction(s). Finally, a >>> >>> version >>> >>> of the algorithm that uses locks is also provided. >>> >>> >>> >>> Use --enable-schedule-scalable to conditionally compile this scheduler >>> >>> into the library. >>> >>> >>> >>> [1] >>> >>> https://lists.linaro.org/pipermail/lng-odp/2016-September/025682.html >>> >>> >>> >>> On checkpatch.pl: >>> >>> - [2/6] and [5/6] have checkpatch.pl issues that are superfluous >>> >>> >>> >>> v9: >>> >>> - Include patch to enable scalable scheduler in Travis CI >>> >>> - Fix 'make distcheck' >>> >>> >>> >>> v8: >>> >>> - Reword commit messages >>> >>> >>> >>> v7: >>> >>> - Rebase against new modular queue interface >>> >>> - Duplicate arch files under mips64 and powerpc >>> >>> - Fix sched->order_lock() >>> >>> - Loop until all deferred events have been enqueued >>> >>> - Implement ord_enq_multi() >>> >>> - Fix ordered_lock/unlock >>> >>> - Revert stylistic changes >>> >>> - Add default xfactor >>> >>> - Remove changes to odp_sched_latency >>> >>> - Remove ULL suffix to alleviate Clang build >>> >>> >>> >>> v6: >>> >>> - Move conversions into scalable scheduler to alleviate #ifdefs >>> >>> - Remove unnecessary prefetch >>> >>> - Fix ARMv8 build >>> >>> >>> >>> v5: >>> >>> - Allocate cache aligned memory using shm pool APIs >>> >>> - Move more code to sca
Re: [lng-odp] [PATCH API-NEXT v1 1/1] linux-generic: queue: modular queue interface
Agree, will rebase and update once we have the scalable queues merged. On 21 June 2017 at 14:53, Maxim Uvarov wrote: > On 06/19/17 08:00, Github ODP bot wrote: >> log| 1269 >> > > log has not be a part of patch. > > Maxim.
[lng-odp] Travis hangs pktio tests after update
Yesterday was Travis update https://blog.travis-ci.com/2017-06-21-trusty-updates-2017-Q2-launch it stopped to run our tests: https://travis-ci.org/muvarov/odp/jobs/245520284 I.e. it hangs forever on pktio_run_tap.sh test. Regards, Maxim.
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
On 06/21/17 23:30, Brian Brooks wrote: > #if -> #ifdef > ifdef works. > On Wed, Jun 21, 2017 at 3:27 PM, Maxim Uvarov wrote: >> odp check with ARCH=arm fails after this patch: >> >> CC arch/arm/odp_cpu_arch.lo >> arch/arm/odp_cpu_arch.c: In function 'cpu_global_time': >> arch/arm/odp_cpu_arch.c:71:5: error: "__aarch64__" is not defined >> [-Werror=undef] >> #if __aarch64__ >> ^ >> arch/arm/odp_cpu_arch.c: In function 'cpu_global_time_freq': >> arch/arm/odp_cpu_arch.c:91:5: error: "__aarch64__" is not defined >> [-Werror=undef] >> #if __aarch64__ >> ^ >> cc1: all warnings being treated as errors >> >> implementation_name:odp-linux >> host: arm-unknown-linux-gnueabihf >> ARCH_DIRarm >> ARCH_ABIarm32-linux >> with_platform: linux-generic >> helper_linux: no >> prefix: /opt/Linaro/check-odp-v3.git/new-build >> sysconfdir: ${prefix}/etc >> libdir: ${exec_prefix}/lib >> includedir: ${prefix}/include >> testdir:${exec_prefix}/lib/odp/tests >> WITH_ARCH: arm >> >> cc: arm-linux-gnueabihf-gcc >> cc version: 5.3.1 >> >> >> >> >> On 06/21/17 15:42, Bill Fischofer wrote: >>> I've confirmed this is benign on x86. Brian: Please review for ARM. >>> >>> On Wed, Jun 21, 2017 at 6:48 AM, Petri Savolainen >>> wrote: Use __aarch64__ instead of __ARM_ARCH, since it's backwards compatible between GCC versions. Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 Signed-off-by: Petri Savolainen --- platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c b/platform/linux-generic/arch/arm/odp_cpu_arch.c index 91d439d9..fd1b3ed6 100644 --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c @@ -68,7 +68,7 @@ int cpu_has_global_time(void) uint64_t cpu_global_time(void) { -#if __ARM_ARCH == 8 +#if __aarch64__ uint64_t cntvct; /* @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) uint64_t cpu_global_time_freq(void) { -#if __ARM_ARCH == 8 +#if __aarch64__ uint64_t cntfrq; __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); -- 2.13.0 >>
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
#if -> #ifdef On Wed, Jun 21, 2017 at 3:27 PM, Maxim Uvarov wrote: > odp check with ARCH=arm fails after this patch: > > CC arch/arm/odp_cpu_arch.lo > arch/arm/odp_cpu_arch.c: In function 'cpu_global_time': > arch/arm/odp_cpu_arch.c:71:5: error: "__aarch64__" is not defined > [-Werror=undef] > #if __aarch64__ > ^ > arch/arm/odp_cpu_arch.c: In function 'cpu_global_time_freq': > arch/arm/odp_cpu_arch.c:91:5: error: "__aarch64__" is not defined > [-Werror=undef] > #if __aarch64__ > ^ > cc1: all warnings being treated as errors > > implementation_name:odp-linux > host: arm-unknown-linux-gnueabihf > ARCH_DIRarm > ARCH_ABIarm32-linux > with_platform: linux-generic > helper_linux: no > prefix: /opt/Linaro/check-odp-v3.git/new-build > sysconfdir: ${prefix}/etc > libdir: ${exec_prefix}/lib > includedir: ${prefix}/include > testdir:${exec_prefix}/lib/odp/tests > WITH_ARCH: arm > > cc: arm-linux-gnueabihf-gcc > cc version: 5.3.1 > > > > > On 06/21/17 15:42, Bill Fischofer wrote: >> I've confirmed this is benign on x86. Brian: Please review for ARM. >> >> On Wed, Jun 21, 2017 at 6:48 AM, Petri Savolainen >> wrote: >>> Use __aarch64__ instead of __ARM_ARCH, since it's backwards >>> compatible between GCC versions. >>> >>> Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 >>> >>> Signed-off-by: Petri Savolainen >>> --- >>> platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c >>> b/platform/linux-generic/arch/arm/odp_cpu_arch.c >>> index 91d439d9..fd1b3ed6 100644 >>> --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c >>> +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c >>> @@ -68,7 +68,7 @@ int cpu_has_global_time(void) >>> >>> uint64_t cpu_global_time(void) >>> { >>> -#if __ARM_ARCH == 8 >>> +#if __aarch64__ >>> uint64_t cntvct; >>> >>> /* >>> @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) >>> >>> uint64_t cpu_global_time_freq(void) >>> { >>> -#if __ARM_ARCH == 8 >>> +#if __aarch64__ >>> uint64_t cntfrq; >>> >>> __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); >>> -- >>> 2.13.0 >>> >
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
odp check with ARCH=arm fails after this patch: CC arch/arm/odp_cpu_arch.lo arch/arm/odp_cpu_arch.c: In function 'cpu_global_time': arch/arm/odp_cpu_arch.c:71:5: error: "__aarch64__" is not defined [-Werror=undef] #if __aarch64__ ^ arch/arm/odp_cpu_arch.c: In function 'cpu_global_time_freq': arch/arm/odp_cpu_arch.c:91:5: error: "__aarch64__" is not defined [-Werror=undef] #if __aarch64__ ^ cc1: all warnings being treated as errors implementation_name:odp-linux host: arm-unknown-linux-gnueabihf ARCH_DIRarm ARCH_ABIarm32-linux with_platform: linux-generic helper_linux: no prefix: /opt/Linaro/check-odp-v3.git/new-build sysconfdir: ${prefix}/etc libdir: ${exec_prefix}/lib includedir: ${prefix}/include testdir:${exec_prefix}/lib/odp/tests WITH_ARCH: arm cc: arm-linux-gnueabihf-gcc cc version: 5.3.1 On 06/21/17 15:42, Bill Fischofer wrote: > I've confirmed this is benign on x86. Brian: Please review for ARM. > > On Wed, Jun 21, 2017 at 6:48 AM, Petri Savolainen > wrote: >> Use __aarch64__ instead of __ARM_ARCH, since it's backwards >> compatible between GCC versions. >> >> Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 >> >> Signed-off-by: Petri Savolainen >> --- >> platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c >> b/platform/linux-generic/arch/arm/odp_cpu_arch.c >> index 91d439d9..fd1b3ed6 100644 >> --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c >> +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c >> @@ -68,7 +68,7 @@ int cpu_has_global_time(void) >> >> uint64_t cpu_global_time(void) >> { >> -#if __ARM_ARCH == 8 >> +#if __aarch64__ >> uint64_t cntvct; >> >> /* >> @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) >> >> uint64_t cpu_global_time_freq(void) >> { >> -#if __ARM_ARCH == 8 >> +#if __aarch64__ >> uint64_t cntfrq; >> >> __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); >> -- >> 2.13.0 >>
Re: [lng-odp] [API-NEXT PATCH v9 0/6] A scalable software scheduler
On Wed, Jun 21, 2017 at 3:17 PM, Brian Brooks wrote: > On 06/20 19:38:59, Bill Fischofer wrote: >> Now that master has been merged back into api-next I can confirm that >> make distcheck fails for 64-bit systems as well, so I need to withdraw >> my earlier reviewed-and-tested-by until that is fixed. > > This appears to be a problem in pristine upstream as well. "make distcheck" > is broken on ARM (and likely all non-x86 archs). > > The issue is that in platform/linux-generic/Makefile.am "if ARCH_IS_X86" > is always true. I have not yet found a workaround.. Good to know, but with this patch it's also broken for x86. Sounds like we have two issues to address. > >> On Mon, Jun 19, 2017 at 6:13 PM, Bill Fischofer >> wrote: >> > Looks like I posted a wee bit too soon. On a 32-bit system: >> > >> > bill@Ub16-32:~/linaro/armschedv9$ make distcheck >> > make dist-gzip am__post_remove_distdir='@:' >> > make[1]: Entering directory '/home/bill/linaro/armschedv9' >> > if test -d "opendataplane-1.14.0.0"; then find >> > "opendataplane-1.14.0.0" -type d ! -perm -200 -exec chmod u+w {} ';' >> > && rm -rf "opendataplane-1.14.0.0" || { sleep 5 && rm -rf >> > "opendataplane-1.14.0.0"; }; else :; fi >> > test -d "opendataplane-1.14.0.0" || mkdir "opendataplane-1.14.0.0" >> > (cd platform/linux-generic && make >> > top_distdir=../../opendataplane-1.14.0.0 >> > distdir=../../opendataplane-1.14.0.0/platform/linux-generic \ >> > am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: >> > distdir) >> > make[2]: Entering directory >> > '/home/bill/linaro/armschedv9/platform/linux-generic' >> > make[2]: *** No rule to make target 'arch/x86/odp_atomic.h', needed by >> > 'distdir'. Stop. >> > make[2]: Leaving directory >> > '/home/bill/linaro/armschedv9/platform/linux-generic' >> > Makefile:603: recipe for target 'distdir' failed >> > make[1]: *** [distdir] Error 1 >> > make[1]: Leaving directory '/home/bill/linaro/armschedv9' >> > Makefile:702: recipe for target 'dist' failed >> > make: *** [dist] Error 2 >> > >> > On Mon, Jun 19, 2017 at 6:11 PM, Bill Fischofer >> > wrote: >> >> For the v9 series: >> >> >> >> Reviewed-and-tested-by: Bill Fischofer >> >> >> >> I also verified that there are no conflicts between this series and >> >> Petri's queue cleanup patch, so this can apply and run just fine on >> >> top of it. Maxim should be able to merge both tomorrow. >> >> >> >> On Mon, Jun 19, 2017 at 2:12 PM, Brian Brooks >> >> wrote: >> >>> This work derives from Ola Liljedahl's prototype [1] which introduced a >> >>> scalable scheduler design based on primarily lock-free algorithms and >> >>> data structures designed to decrease contention. A thread searches >> >>> through a data structure containing only queues that are both non-empty >> >>> and allowed to be scheduled to that thread. Strict priority scheduling is >> >>> respected, and (W)RR scheduling may be used within queues of the same >> >>> priority. >> >>> Lastly, pre-scheduling or stashing is not employed since it is optional >> >>> functionality that can be implemented in the application. >> >>> >> >>> In addition to scalable ring buffers, the algorithm also uses unbounded >> >>> concurrent queues. LL/SC and CAS variants exist in cases where absense of >> >>> ABA problem cannot be proved, and also in cases where the compiler's >> >>> atomic >> >>> built-ins may not be lowered to the desired instruction(s). Finally, a >> >>> version >> >>> of the algorithm that uses locks is also provided. >> >>> >> >>> Use --enable-schedule-scalable to conditionally compile this scheduler >> >>> into the library. >> >>> >> >>> [1] https://lists.linaro.org/pipermail/lng-odp/2016-September/025682.html >> >>> >> >>> On checkpatch.pl: >> >>> - [2/6] and [5/6] have checkpatch.pl issues that are superfluous >> >>> >> >>> v9: >> >>> - Include patch to enable scalable scheduler in Travis CI >> >>> - Fix 'make distcheck' >> >>> >> >>> v8: >> >>> - Reword commit messages >> >>> >> >>> v7: >> >>> - Rebase against new modular queue interface >> >>> - Duplicate arch files under mips64 and powerpc >> >>> - Fix sched->order_lock() >> >>> - Loop until all deferred events have been enqueued >> >>> - Implement ord_enq_multi() >> >>> - Fix ordered_lock/unlock >> >>> - Revert stylistic changes >> >>> - Add default xfactor >> >>> - Remove changes to odp_sched_latency >> >>> - Remove ULL suffix to alleviate Clang build >> >>> >> >>> v6: >> >>> - Move conversions into scalable scheduler to alleviate #ifdefs >> >>> - Remove unnecessary prefetch >> >>> - Fix ARMv8 build >> >>> >> >>> v5: >> >>> - Allocate cache aligned memory using shm pool APIs >> >>> - Move more code to scalable scheduler specific files >> >>> - Remove CONFIG_SPLIT_READWRITE >> >>> - Fix 'make distcheck' issue >> >>> >> >>> v4: >> >>> - Fix a couple more checkpatch.pl issues >> >>> >> >>> v3: >> >>> - Only conditionally compile scalable scheduler and queue >> >>> - Move some code to arch/ dir >
Re: [lng-odp] [API-NEXT PATCH v9 0/6] A scalable software scheduler
On 06/20 19:38:59, Bill Fischofer wrote: > Now that master has been merged back into api-next I can confirm that > make distcheck fails for 64-bit systems as well, so I need to withdraw > my earlier reviewed-and-tested-by until that is fixed. This appears to be a problem in pristine upstream as well. "make distcheck" is broken on ARM (and likely all non-x86 archs). The issue is that in platform/linux-generic/Makefile.am "if ARCH_IS_X86" is always true. I have not yet found a workaround.. > On Mon, Jun 19, 2017 at 6:13 PM, Bill Fischofer > wrote: > > Looks like I posted a wee bit too soon. On a 32-bit system: > > > > bill@Ub16-32:~/linaro/armschedv9$ make distcheck > > make dist-gzip am__post_remove_distdir='@:' > > make[1]: Entering directory '/home/bill/linaro/armschedv9' > > if test -d "opendataplane-1.14.0.0"; then find > > "opendataplane-1.14.0.0" -type d ! -perm -200 -exec chmod u+w {} ';' > > && rm -rf "opendataplane-1.14.0.0" || { sleep 5 && rm -rf > > "opendataplane-1.14.0.0"; }; else :; fi > > test -d "opendataplane-1.14.0.0" || mkdir "opendataplane-1.14.0.0" > > (cd platform/linux-generic && make > > top_distdir=../../opendataplane-1.14.0.0 > > distdir=../../opendataplane-1.14.0.0/platform/linux-generic \ > > am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: > > distdir) > > make[2]: Entering directory > > '/home/bill/linaro/armschedv9/platform/linux-generic' > > make[2]: *** No rule to make target 'arch/x86/odp_atomic.h', needed by > > 'distdir'. Stop. > > make[2]: Leaving directory > > '/home/bill/linaro/armschedv9/platform/linux-generic' > > Makefile:603: recipe for target 'distdir' failed > > make[1]: *** [distdir] Error 1 > > make[1]: Leaving directory '/home/bill/linaro/armschedv9' > > Makefile:702: recipe for target 'dist' failed > > make: *** [dist] Error 2 > > > > On Mon, Jun 19, 2017 at 6:11 PM, Bill Fischofer > > wrote: > >> For the v9 series: > >> > >> Reviewed-and-tested-by: Bill Fischofer > >> > >> I also verified that there are no conflicts between this series and > >> Petri's queue cleanup patch, so this can apply and run just fine on > >> top of it. Maxim should be able to merge both tomorrow. > >> > >> On Mon, Jun 19, 2017 at 2:12 PM, Brian Brooks wrote: > >>> This work derives from Ola Liljedahl's prototype [1] which introduced a > >>> scalable scheduler design based on primarily lock-free algorithms and > >>> data structures designed to decrease contention. A thread searches > >>> through a data structure containing only queues that are both non-empty > >>> and allowed to be scheduled to that thread. Strict priority scheduling is > >>> respected, and (W)RR scheduling may be used within queues of the same > >>> priority. > >>> Lastly, pre-scheduling or stashing is not employed since it is optional > >>> functionality that can be implemented in the application. > >>> > >>> In addition to scalable ring buffers, the algorithm also uses unbounded > >>> concurrent queues. LL/SC and CAS variants exist in cases where absense of > >>> ABA problem cannot be proved, and also in cases where the compiler's > >>> atomic > >>> built-ins may not be lowered to the desired instruction(s). Finally, a > >>> version > >>> of the algorithm that uses locks is also provided. > >>> > >>> Use --enable-schedule-scalable to conditionally compile this scheduler > >>> into the library. > >>> > >>> [1] https://lists.linaro.org/pipermail/lng-odp/2016-September/025682.html > >>> > >>> On checkpatch.pl: > >>> - [2/6] and [5/6] have checkpatch.pl issues that are superfluous > >>> > >>> v9: > >>> - Include patch to enable scalable scheduler in Travis CI > >>> - Fix 'make distcheck' > >>> > >>> v8: > >>> - Reword commit messages > >>> > >>> v7: > >>> - Rebase against new modular queue interface > >>> - Duplicate arch files under mips64 and powerpc > >>> - Fix sched->order_lock() > >>> - Loop until all deferred events have been enqueued > >>> - Implement ord_enq_multi() > >>> - Fix ordered_lock/unlock > >>> - Revert stylistic changes > >>> - Add default xfactor > >>> - Remove changes to odp_sched_latency > >>> - Remove ULL suffix to alleviate Clang build > >>> > >>> v6: > >>> - Move conversions into scalable scheduler to alleviate #ifdefs > >>> - Remove unnecessary prefetch > >>> - Fix ARMv8 build > >>> > >>> v5: > >>> - Allocate cache aligned memory using shm pool APIs > >>> - Move more code to scalable scheduler specific files > >>> - Remove CONFIG_SPLIT_READWRITE > >>> - Fix 'make distcheck' issue > >>> > >>> v4: > >>> - Fix a couple more checkpatch.pl issues > >>> > >>> v3: > >>> - Only conditionally compile scalable scheduler and queue > >>> - Move some code to arch/ dir > >>> - Use a single shm block for queues instead of block-per-queue > >>> - De-interleave odp_llqueue.h > >>> - Use compiler macros to determine ATOM_BITSET_SIZE > >>> - Incorporated queue size changes > >>> - Dropped 'ODP_' prefix on config and moved to other files > >>> - Dro
Re: [lng-odp] [API-NEXT PATCH v9 3/6] linux-gen: sched scalable: add a bitset
On 21.06.2017 23:08, Ola Liljedahl wrote: > > On 21/06/2017, 22:00, "Dmitry Eremin-Solenikov" > wrote: > >> On 21.06.2017 21:14, Ola Liljedahl wrote: >>> >>> On 20/06/2017, 15:04, "Savolainen, Petri (Nokia - FI/Espoo)" >>> wrote: >>> > +++ b/platform/linux-generic/include/odp_bitset.h > @@ -0,0 +1,210 @@ > +/* Copyright (c) 2017, ARM Limited > + * All rights reserved. > + * > + * SPDX-License-Identifier: BSD-3-Clause > + */ > + > +#ifndef _ODP_BITSET_H_ > +#define _ODP_BITSET_H_ > + > +#include > + > +#include > + > > > +/* > ** > * > ** > + * bitset abstract data type > + > > > *** > ** > * > ***/ > +/* This could be a struct of scalars to support larger bit sets */ > + > +/* > + * Size of atomic bit set. This limits the max number of threads, > + * scheduler groups and reorder windows. On ARMv8/64-bit and x86-64, > the > + * (lock-free) max is 128 > + */ > + > +/* Find a suitable data type that supports lock-free atomic > operations > */ > +#if defined(__ARM_ARCH) && __ARM_ARCH == 8 && __ARM_64BIT_STATE == > 1 > && Why ifdef ARM? Why this code is not in arch directory ? >>> Why is this car red? >>> Because I like it like that. >> >> I think it was agreed that arch-specific code should go to arch/ dirs, >> wasn't it? > If you bend backwards enough, you will always touch ground again with your > hands. It doesn¹t mean it is meaningful to do so. Especially not when you > can just lean forward and accomplish the same without the pain. Ola, sometimes it is necessary to bend backwards. -- With best wishes Dmitry
Re: [lng-odp] [API-NEXT PATCH v9 3/6] linux-gen: sched scalable: add a bitset
On 21/06/2017, 22:00, "Dmitry Eremin-Solenikov" wrote: >On 21.06.2017 21:14, Ola Liljedahl wrote: >> >> On 20/06/2017, 15:04, "Savolainen, Petri (Nokia - FI/Espoo)" >> wrote: >> >>> >>> +++ b/platform/linux-generic/include/odp_bitset.h @@ -0,0 +1,210 @@ +/* Copyright (c) 2017, ARM Limited + * All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef _ODP_BITSET_H_ +#define _ODP_BITSET_H_ + +#include + +#include + +/* ** * ** + * bitset abstract data type + *** ** * ***/ +/* This could be a struct of scalars to support larger bit sets */ + +/* + * Size of atomic bit set. This limits the max number of threads, + * scheduler groups and reorder windows. On ARMv8/64-bit and x86-64, the + * (lock-free) max is 128 + */ + +/* Find a suitable data type that supports lock-free atomic operations */ +#if defined(__ARM_ARCH) && __ARM_ARCH == 8 && __ARM_64BIT_STATE == 1 && >>> >>> Why ifdef ARM? Why this code is not in arch directory ? >> Why is this car red? >> Because I like it like that. > >I think it was agreed that arch-specific code should go to arch/ dirs, >wasn't it? If you bend backwards enough, you will always touch ground again with your hands. It doesn¹t mean it is meaningful to do so. Especially not when you can just lean forward and accomplish the same without the pain. > > >-- >With best wishes >Dmitry
Re: [lng-odp] [API-NEXT PATCH v9 3/6] linux-gen: sched scalable: add a bitset
On 06/21/17 23:00, Dmitry Eremin-Solenikov wrote: > On 21.06.2017 21:14, Ola Liljedahl wrote: >> >> On 20/06/2017, 15:04, "Savolainen, Petri (Nokia - FI/Espoo)" >> wrote: >> >>> >>> +++ b/platform/linux-generic/include/odp_bitset.h @@ -0,0 +1,210 @@ +/* Copyright (c) 2017, ARM Limited + * All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef _ODP_BITSET_H_ +#define _ODP_BITSET_H_ + +#include + +#include + +/*** * ** + * bitset abstract data type + * * ***/ +/* This could be a struct of scalars to support larger bit sets */ + +/* + * Size of atomic bit set. This limits the max number of threads, + * scheduler groups and reorder windows. On ARMv8/64-bit and x86-64, the + * (lock-free) max is 128 + */ + +/* Find a suitable data type that supports lock-free atomic operations */ +#if defined(__ARM_ARCH) && __ARM_ARCH == 8 && __ARM_64BIT_STATE == 1 && >>> >>> Why ifdef ARM? Why this code is not in arch directory ? >> Why is this car red? >> Because I like it like that. > > I think it was agreed that arch-specific code should go to arch/ dirs, > wasn't it? > > yes, it has to be there. Maxim.
Re: [lng-odp] [API-NEXT PATCH v9 3/6] linux-gen: sched scalable: add a bitset
On 21.06.2017 21:14, Ola Liljedahl wrote: > > On 20/06/2017, 15:04, "Savolainen, Petri (Nokia - FI/Espoo)" > wrote: > >> >> >>> +++ b/platform/linux-generic/include/odp_bitset.h >>> @@ -0,0 +1,210 @@ >>> +/* Copyright (c) 2017, ARM Limited >>> + * All rights reserved. >>> + * >>> + * SPDX-License-Identifier: BSD-3-Clause >>> + */ >>> + >>> +#ifndef _ODP_BITSET_H_ >>> +#define _ODP_BITSET_H_ >>> + >>> +#include >>> + >>> +#include >>> + >>> >>> +/*** >>> * >>> ** >>> + * bitset abstract data type >>> + >>> >>> * >>> * >>> ***/ >>> +/* This could be a struct of scalars to support larger bit sets */ >>> + >>> +/* >>> + * Size of atomic bit set. This limits the max number of threads, >>> + * scheduler groups and reorder windows. On ARMv8/64-bit and x86-64, >>> the >>> + * (lock-free) max is 128 >>> + */ >>> + >>> +/* Find a suitable data type that supports lock-free atomic operations >>> */ >>> +#if defined(__ARM_ARCH) && __ARM_ARCH == 8 && __ARM_64BIT_STATE == 1 >>> && >> >> Why ifdef ARM? Why this code is not in arch directory ? > Why is this car red? > Because I like it like that. I think it was agreed that arch-specific code should go to arch/ dirs, wasn't it? -- With best wishes Dmitry
Re: [lng-odp] [PATCH API-NEXT v1 1/1] linux-generic: queue: modular queue interface
On 06/19/17 08:00, Github ODP bot wrote: > log| 1269 > log has not be a part of patch. Maxim.
Re: [lng-odp] Need to standardize tools version
it's very hard to standardize tools and compiler version. For now to validate patches we use Linaro CI (odp-check scripts) and Travis CI which is based on some stable ubuntu version. Also we really want that all people can download odp, compile it and run. It's very rare case if different tools introduce issues but some times it happen. If such issue is found before patch submission it has to be fixed before. Maxim. On 06/21/17 22:19, Bill Fischofer wrote: > On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli > wrote: >> On 21 June 2017 at 12:23, Bill Fischofer wrote: >>> ODP is fairly open-ended in this regard because in theory we're only >>> dependent on >>> >>> - A C99-conforming compiler >>> - A platform that supports a reasonably recent Linux kernel >>> >>> Today we do test on 32 and 64 bit systems, and try to support both GCC >>> and clang, however as newer versions of these tools get released we >>> sometimes encounter problems. The same is true with older releases. We >>> try to accommodate, especially when the fix to support a wider range >>> of tools and platforms is relatively straightforward. >>> >>> It's not possible to test exhaustively on every possible combination >>> so when problems occur we open and fix bugs. However, once we fix a >>> bug we prefer to fix it only once, which means that in-flight patches >>> should be checked to see if they have a similar problem and should be >>> revised to avoid that problem as well. That way we don't fix the same >>> problem multiple times. >>> >> Agree. For anyone to submit a patch, they need to have a reference of >> what needs to be done. Scalable scheduler is an example, where we have >> been discovering at every patch that there is a new thing that needs >> to be done to accept the patch. If it was known upfront, we can work >> on them from day 1. This sets up the expectation and saves time for >> everyone, knowing that the patch works for this minimum acceptance >> criteria. For ex: I do not know how many times you have tried to >> compile the code and discovered that it does not compile. I would like >> to avoid those problems. > > That's what we're trying to do with CI and Travis. In this specific > case Petri discovered an issue that effected an older LTS level of > Ubuntu and provided a simple fix to the issue. So I don't see a > problem with propagating that fix as Brian seems to have confirmed > that the fix is good. > >> >>> >>> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli >>> wrote: Along with this, we need to standardize 32b/64b compilations and the platforms on which we run the test cases. Thanks, Honnappa On 21 June 2017 at 11:38, Honnappa Nagarahalli wrote: > Hi, >I think there is a need to identify tools and specific versions of > the tools from patch acceptance perspective. Any failures outside of > these versions should be the responsibility of the person facing the > issues, they should submit a patch for those versions and tools. > > Travis CI is a step in that direction. But I think we still allow > submissions of patches via email. So, for this case, should we > standardize the tools and versions being used in Travis CI as the > acceptance criteria? > > Thanks, > Honnappa
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
On 06/21/17 21:57, Honnappa Nagarahalli wrote: > I cannot make a decision on this topic. This is what I have been told > and I am also told that Linaro is in sync on this. I will initiate > some discussions on this internally. Bill, do you want to check in > Linaro on this? > we will check this first. > I suggest we go ahead with the patch and agree to change it when we > have a decision. > and we can not go ahead until everything is resolved. Maxim. > On 21 June 2017 at 12:37, Bill Fischofer wrote: >> It's perfectly fine to have an ARM copyright as the original >> contributor, but it also needs a Linaro copyright to be incorporated >> into ODP. See traffic_mngr.c for an example of this. >> >> On Wed, Jun 21, 2017 at 9:27 AM, Honnappa Nagarahalli >> wrote: >>> Hi Maxim, >>> This is a new file added by us. Hence the ARM copyright. >>> Thanks, >>> Honnappa >>> >>> On 21 June 2017 at 09:06, Maxim Uvarov wrote: On 06/19/17 22:12, Brian Brooks wrote: > > --- /dev/null > +++ b/platform/linux-generic/include/odp_llqueue.h > @@ -0,0 +1,309 @@ > +/* Copyright (c) 2017, ARM Limited. > + * All rights reserved. > + * > + * SPDX-License-Identifier:BSD-3-Clause > + */ > + Has to be Linaro copyright. Maxim.
Re: [lng-odp] Need to standardize tools version
On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli wrote: > On 21 June 2017 at 12:23, Bill Fischofer wrote: >> ODP is fairly open-ended in this regard because in theory we're only >> dependent on >> >> - A C99-conforming compiler >> - A platform that supports a reasonably recent Linux kernel >> >> Today we do test on 32 and 64 bit systems, and try to support both GCC >> and clang, however as newer versions of these tools get released we >> sometimes encounter problems. The same is true with older releases. We >> try to accommodate, especially when the fix to support a wider range >> of tools and platforms is relatively straightforward. >> >> It's not possible to test exhaustively on every possible combination >> so when problems occur we open and fix bugs. However, once we fix a >> bug we prefer to fix it only once, which means that in-flight patches >> should be checked to see if they have a similar problem and should be >> revised to avoid that problem as well. That way we don't fix the same >> problem multiple times. >> > Agree. For anyone to submit a patch, they need to have a reference of > what needs to be done. Scalable scheduler is an example, where we have > been discovering at every patch that there is a new thing that needs > to be done to accept the patch. If it was known upfront, we can work > on them from day 1. This sets up the expectation and saves time for > everyone, knowing that the patch works for this minimum acceptance > criteria. For ex: I do not know how many times you have tried to > compile the code and discovered that it does not compile. I would like > to avoid those problems. That's what we're trying to do with CI and Travis. In this specific case Petri discovered an issue that effected an older LTS level of Ubuntu and provided a simple fix to the issue. So I don't see a problem with propagating that fix as Brian seems to have confirmed that the fix is good. > >> >> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli >> wrote: >>> Along with this, we need to standardize 32b/64b compilations and the >>> platforms on which we run the test cases. >>> Thanks, >>> Honnappa >>> >>> On 21 June 2017 at 11:38, Honnappa Nagarahalli >>> wrote: Hi, I think there is a need to identify tools and specific versions of the tools from patch acceptance perspective. Any failures outside of these versions should be the responsibility of the person facing the issues, they should submit a patch for those versions and tools. Travis CI is a step in that direction. But I think we still allow submissions of patches via email. So, for this case, should we standardize the tools and versions being used in Travis CI as the acceptance criteria? Thanks, Honnappa
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
I cannot make a decision on this topic. This is what I have been told and I am also told that Linaro is in sync on this. I will initiate some discussions on this internally. Bill, do you want to check in Linaro on this? I suggest we go ahead with the patch and agree to change it when we have a decision. On 21 June 2017 at 12:37, Bill Fischofer wrote: > It's perfectly fine to have an ARM copyright as the original > contributor, but it also needs a Linaro copyright to be incorporated > into ODP. See traffic_mngr.c for an example of this. > > On Wed, Jun 21, 2017 at 9:27 AM, Honnappa Nagarahalli > wrote: >> Hi Maxim, >> This is a new file added by us. Hence the ARM copyright. >> Thanks, >> Honnappa >> >> On 21 June 2017 at 09:06, Maxim Uvarov wrote: >>> On 06/19/17 22:12, Brian Brooks wrote: --- /dev/null +++ b/platform/linux-generic/include/odp_llqueue.h @@ -0,0 +1,309 @@ +/* Copyright (c) 2017, ARM Limited. + * All rights reserved. + * + * SPDX-License-Identifier:BSD-3-Clause + */ + >>> >>> >>> Has to be Linaro copyright. >>> >>> Maxim.
Re: [lng-odp] [API-NEXT PATCH v4] timer: allow timer processing to run on worker cores
We have not run any performance application. In our Linaro connect meeting, we presented numbers on how it improves the timer resolution. At this point, there is enough configuration options to control the effect of calling timer in the scheduler. For applications that do not want to use the timer, there should not be any change. For applications that use timers non-frequently, the check frequency can be controlled via the provided configuration options. On 20 June 2017 at 02:34, Savolainen, Petri (Nokia - FI/Espoo) wrote: > Do you have some performance numbers? E.g. how much this slows down an > application which does not use timers (e.g. l2fwd), or an application that > uses only few, non-frequent timeouts? > > Additionally, init.h/feature.h is not yet in api-next - so this would not > build yet. > > > -Petri > > >> -Original Message- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> Honnappa Nagarahalli >> Sent: Tuesday, June 20, 2017 7:07 AM >> To: Bill Fischofer >> Cc: lng-odp-forward >> Subject: Re: [lng-odp] [API-NEXT PATCH v4] timer: allow timer processing >> to run on worker cores >> >> Are you saying we should be good to merge this now? >> >> On 19 June 2017 at 17:42, Bill Fischofer >> wrote: >> > On Mon, Jun 19, 2017 at 4:19 PM, Honnappa Nagarahalli >> > wrote: >> >> Hi Bill/Maxim, >> >> I do not see any further comments, can we merge this to api-next? >> >> >> >> Thanks, >> >> Honnappa > >
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
Thanks Brian. Is this also in clang for ARM? On Wed, Jun 14, 2017 at 4:16 PM, Brian Brooks wrote: > Reviewed-by: Brian Brooks > > ACLE [1] was added to GCC 4.9. GCC 4.8 does define __aarch64__ > so this change should be safe. > > [1] > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf > > On 06/21 14:48:36, Petri Savolainen wrote: >> Use __aarch64__ instead of __ARM_ARCH, since it's backwards >> compatible between GCC versions. >> >> Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 >> >> Signed-off-by: Petri Savolainen >> --- >> platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c >> b/platform/linux-generic/arch/arm/odp_cpu_arch.c >> index 91d439d9..fd1b3ed6 100644 >> --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c >> +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c >> @@ -68,7 +68,7 @@ int cpu_has_global_time(void) >> >> uint64_t cpu_global_time(void) >> { >> -#if __ARM_ARCH == 8 >> +#if __aarch64__ >> uint64_t cntvct; >> >> /* >> @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) >> >> uint64_t cpu_global_time_freq(void) >> { >> -#if __ARM_ARCH == 8 >> +#if __aarch64__ >> uint64_t cntfrq; >> >> __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); >> -- >> 2.13.0 >>
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
Reviewed-by: Brian Brooks ACLE [1] was added to GCC 4.9. GCC 4.8 does define __aarch64__ so this change should be safe. [1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf On 06/21 14:48:36, Petri Savolainen wrote: > Use __aarch64__ instead of __ARM_ARCH, since it's backwards > compatible between GCC versions. > > Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 > > Signed-off-by: Petri Savolainen > --- > platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c > b/platform/linux-generic/arch/arm/odp_cpu_arch.c > index 91d439d9..fd1b3ed6 100644 > --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c > +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c > @@ -68,7 +68,7 @@ int cpu_has_global_time(void) > > uint64_t cpu_global_time(void) > { > -#if __ARM_ARCH == 8 > +#if __aarch64__ > uint64_t cntvct; > > /* > @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) > > uint64_t cpu_global_time_freq(void) > { > -#if __ARM_ARCH == 8 > +#if __aarch64__ > uint64_t cntfrq; > > __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); > -- > 2.13.0 >
Re: [lng-odp] Need to standardize tools version
On 21 June 2017 at 12:23, Bill Fischofer wrote: > ODP is fairly open-ended in this regard because in theory we're only > dependent on > > - A C99-conforming compiler > - A platform that supports a reasonably recent Linux kernel > > Today we do test on 32 and 64 bit systems, and try to support both GCC > and clang, however as newer versions of these tools get released we > sometimes encounter problems. The same is true with older releases. We > try to accommodate, especially when the fix to support a wider range > of tools and platforms is relatively straightforward. > > It's not possible to test exhaustively on every possible combination > so when problems occur we open and fix bugs. However, once we fix a > bug we prefer to fix it only once, which means that in-flight patches > should be checked to see if they have a similar problem and should be > revised to avoid that problem as well. That way we don't fix the same > problem multiple times. > Agree. For anyone to submit a patch, they need to have a reference of what needs to be done. Scalable scheduler is an example, where we have been discovering at every patch that there is a new thing that needs to be done to accept the patch. If it was known upfront, we can work on them from day 1. This sets up the expectation and saves time for everyone, knowing that the patch works for this minimum acceptance criteria. For ex: I do not know how many times you have tried to compile the code and discovered that it does not compile. I would like to avoid those problems. > > On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli > wrote: >> Along with this, we need to standardize 32b/64b compilations and the >> platforms on which we run the test cases. >> Thanks, >> Honnappa >> >> On 21 June 2017 at 11:38, Honnappa Nagarahalli >> wrote: >>> Hi, >>>I think there is a need to identify tools and specific versions of >>> the tools from patch acceptance perspective. Any failures outside of >>> these versions should be the responsibility of the person facing the >>> issues, they should submit a patch for those versions and tools. >>> >>> Travis CI is a step in that direction. But I think we still allow >>> submissions of patches via email. So, for this case, should we >>> standardize the tools and versions being used in Travis CI as the >>> acceptance criteria? >>> >>> Thanks, >>> Honnappa
Re: [lng-odp] [API-NEXT PATCH v9 3/6] linux-gen: sched scalable: add a bitset
On 20/06/2017, 15:04, "Savolainen, Petri (Nokia - FI/Espoo)" wrote: > > >> +++ b/platform/linux-generic/include/odp_bitset.h >> @@ -0,0 +1,210 @@ >> +/* Copyright (c) 2017, ARM Limited >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +#ifndef _ODP_BITSET_H_ >> +#define _ODP_BITSET_H_ >> + >> +#include >> + >> +#include >> + >> >>+/*** >>* >> ** >> + * bitset abstract data type >> + >> >>* >>* >> ***/ >> +/* This could be a struct of scalars to support larger bit sets */ >> + >> +/* >> + * Size of atomic bit set. This limits the max number of threads, >> + * scheduler groups and reorder windows. On ARMv8/64-bit and x86-64, >>the >> + * (lock-free) max is 128 >> + */ >> + >> +/* Find a suitable data type that supports lock-free atomic operations >>*/ >> +#if defined(__ARM_ARCH) && __ARM_ARCH == 8 && __ARM_64BIT_STATE == 1 >>&& > >Why ifdef ARM? Why this code is not in arch directory ? Why is this car red? Because I like it like that. > >-Petri > > >> \ >> +defined(__SIZEOF_INT128__) && __SIZEOF_INT128__ == 16 >> +#define LOCKFREE16 >> +typedef __int128 bitset_t; >> +#define ATOM_BITSET_SIZE (CHAR_BIT * __SIZEOF_INT128__) >> + >> +#elif __GCC_ATOMIC_LLONG_LOCK_FREE == 2 && \ >> +__SIZEOF_LONG_LONG__ != __SIZEOF_LONG__ >> +typedef unsigned long long bitset_t; >> +#define ATOM_BITSET_SIZE (CHAR_BIT * __SIZEOF_LONG_LONG__) >> + >> +#elif __GCC_ATOMIC_LONG_LOCK_FREE == 2 && __SIZEOF_LONG__ != >> __SIZEOF_INT__ >> +typedef unsigned long bitset_t; >> +#define ATOM_BITSET_SIZE (CHAR_BIT * __SIZEOF_LONG__) >> + >> +#elif __GCC_ATOMIC_INT_LOCK_FREE == 2 >> +typedef unsigned int bitset_t; >> +#define ATOM_BITSET_SIZE (CHAR_BIT * __SIZEOF_INT__) >> + >> +#else >> +/* Target does not support lock-free atomic operations */ >> +typedef unsigned int bitset_t; >> +#define ATOM_BITSET_SIZE (CHAR_BIT * __SIZEOF_INT__) >> +#endif >> + >> +#if ATOM_BITSET_SIZE <= 32 > >
Re: [lng-odp] [API-NEXT PATCH v9 5/6] linux-gen: sched scalable: add scalable scheduler
On 20/06/2017, 15:58, "Savolainen, Petri (Nokia - FI/Espoo)" wrote: >> --- a/platform/linux-generic/include/odp_config_internal.h >> +++ b/platform/linux-generic/include/odp_config_internal.h >> @@ -7,9 +7,7 @@ >> #ifndef ODP_CONFIG_INTERNAL_H_ >> #define ODP_CONFIG_INTERNAL_H_ >> >> -#ifdef __cplusplus >> -extern "C" { >> -#endif >> +#include > >Why these configs need global visibility? This file should contain >general configuration options. > >> >> /* >> * Maximum number of pools >> @@ -22,6 +20,13 @@ extern "C" { >> #define ODP_CONFIG_QUEUES 1024 >> >> /* >> + * Maximum queue depth. Maximum number of elements that can be stored >>in >> a >> + * queue. This value is used only when the size is not explicitly >> provided >> + * during queue creation. >> + */ >> +#define CONFIG_QUEUE_SIZE 4096 >> + >> +/* >> * Maximum number of ordered locks per queue >> */ >> #define CONFIG_QUEUE_MAX_ORD_LOCKS 4 >> @@ -120,7 +125,7 @@ extern "C" { >> * >> * This the the number of separate SHM areas that can be reserved >> concurrently >> */ >> -#define ODPDRV_CONFIG_SHM_BLOCKS 48 >> +#define ODPDRV_CONFIG_SHM_BLOCKS ODP_CONFIG_SHM_BLOCKS > > >Is this change necessary? Increases driver memory usage for no reason? The scalable scheduler should have anything to do with the drivers and their shmem use. So I think this change is unnecessary and should be reverted. > > >> + >> +#endif /* ODP_SCHEDULE_SCALABLE_H */ >> diff --git >>a/platform/linux-generic/include/odp_schedule_scalable_config.h >> b/platform/linux-generic/include/odp_schedule_scalable_config.h >> new file mode 100644 >> index ..febf379b >> --- /dev/null >> +++ b/platform/linux-generic/include/odp_schedule_scalable_config.h >> @@ -0,0 +1,55 @@ >> +/* Copyright (c) 2017, ARM Limited >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +#ifndef ODP_SCHEDULE_SCALABLE_CONFIG_H_ >> +#define ODP_SCHEDULE_SCALABLE_CONFIG_H_ >> + >> +/* >> + * Default scaling factor for the scheduler group >> + * >> + * This scaling factor is used when the application creates a scheduler >> + * group with no worker threads. >> + */ >> +#define CONFIG_DEFAULT_XFACTOR 4 >> + >> +/* >> + * Default weight (in events) for WRR in scalable scheduler >> + * >> + * This controls the per-queue weight for WRR between queues of the >>same >> + * priority in the scalable scheduler >> + * A higher value improves throughput while a lower value increases >> fairness >> + * and thus likely decreases latency >> + * >> + * If WRR is undesired, set the value to ~0 which will use the largest >> possible >> + * weight >> + * >> + * Note: an API for specifying this on a per-queue basis would be >>useful >> but is >> + * not yet available >> + */ >> +#define CONFIG_WRR_WEIGHT 64 >> + >> +/* >> + * Split queue producer/consumer metadata into separate cache lines. >> + * This is beneficial on e.g. Cortex-A57 but not so much on A53. >> + */ >> +#define CONFIG_SPLIT_PRODCONS >> + >> +/* >> + * Use locks to protect queue (ring buffer) and scheduler state updates >> + * On x86, this decreases overhead noticeably. >> + */ >> +#ifndef __ARM_ARCH >> +#define CONFIG_QSCHST_LOCK >> +/* Keep all ring buffer/qschst data together when using locks */ >> +#undef CONFIG_SPLIT_PRODCONS >> +#endif >> + >> +/* >> + * Maximum number of ordered locks per queue. >> + */ >> +#define CONFIG_MAX_ORDERED_LOCKS_PER_QUEUE 2 > > >There's already CONFIG_QUEUE_MAX_ORD_LOCKS 4, in the general config file. >Should not add the same define twice (with different value). Yes it is unnecessary for the scalable scheduler to use a separate define for this. > > > >> + >> +#endif /* ODP_SCHEDULE_SCALABLE_CONFIG_H_ */ >> diff --git a/platform/linux- >> generic/include/odp_schedule_scalable_ordered.h b/platform/linux- >> generic/include/odp_schedule_scalable_ordered.h >> new file mode 100644 >> index ..9f3acf7a >> --- /dev/null >> +++ b/platform/linux-generic/include/odp_schedule_scalable_ordered.h >> @@ -0,0 +1,132 @@ >> +/* Copyright (c) 2017, ARM Limited >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +#ifndef ODP_SCHEDULE_SCALABLE_ORDERED_H >> +#define ODP_SCHEDULE_SCALABLE_ORDERED_H >> + >> +#include >> + >> +#include >> +#include >> +#include >> +#include <_ishmpool_internal.h> > >> + >> +/* Number of reorder contects in the reorder window. >> + * Should be at least one per CPU. >> + */ >> +#define RWIN_SIZE 32 >> +ODP_STATIC_ASSERT(CHECK_IS_POWER2(RWIN_SIZE), "RWIN_SIZE is not a power >> of 2"); >> + >> +#define NUM_OLOCKS 2 > >Is this the same as CONFIG_MAX_ORDERED_LOCKS_PER_QUEUE or something >different with similar name ? This is the define that is actually usedÅ There is an obvious need of a cleanup here. > > >> diff --git a/platform/linux-generic/odp_queue_if.c b/platform/linux- >> generic/odp_queue_if.c >> index c91f00eb..d7471dfc 100644 >> --- a/platform/linux-generic/odp_queue_if.c >> +++ b/pla
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
It's perfectly fine to have an ARM copyright as the original contributor, but it also needs a Linaro copyright to be incorporated into ODP. See traffic_mngr.c for an example of this. On Wed, Jun 21, 2017 at 9:27 AM, Honnappa Nagarahalli wrote: > Hi Maxim, > This is a new file added by us. Hence the ARM copyright. > Thanks, > Honnappa > > On 21 June 2017 at 09:06, Maxim Uvarov wrote: >> On 06/19/17 22:12, Brian Brooks wrote: >>> >>> --- /dev/null >>> +++ b/platform/linux-generic/include/odp_llqueue.h >>> @@ -0,0 +1,309 @@ >>> +/* Copyright (c) 2017, ARM Limited. >>> + * All rights reserved. >>> + * >>> + * SPDX-License-Identifier:BSD-3-Clause >>> + */ >>> + >> >> >> Has to be Linaro copyright. >> >> Maxim.
Re: [lng-odp] Need to standardize tools version
ODP is fairly open-ended in this regard because in theory we're only dependent on - A C99-conforming compiler - A platform that supports a reasonably recent Linux kernel Today we do test on 32 and 64 bit systems, and try to support both GCC and clang, however as newer versions of these tools get released we sometimes encounter problems. The same is true with older releases. We try to accommodate, especially when the fix to support a wider range of tools and platforms is relatively straightforward. It's not possible to test exhaustively on every possible combination so when problems occur we open and fix bugs. However, once we fix a bug we prefer to fix it only once, which means that in-flight patches should be checked to see if they have a similar problem and should be revised to avoid that problem as well. That way we don't fix the same problem multiple times. On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli wrote: > Along with this, we need to standardize 32b/64b compilations and the > platforms on which we run the test cases. > Thanks, > Honnappa > > On 21 June 2017 at 11:38, Honnappa Nagarahalli > wrote: >> Hi, >>I think there is a need to identify tools and specific versions of >> the tools from patch acceptance perspective. Any failures outside of >> these versions should be the responsibility of the person facing the >> issues, they should submit a patch for those versions and tools. >> >> Travis CI is a step in that direction. But I think we still allow >> submissions of patches via email. So, for this case, should we >> standardize the tools and versions being used in Travis CI as the >> acceptance criteria? >> >> Thanks, >> Honnappa
Re: [lng-odp] Need to standardize tools version
Along with this, we need to standardize 32b/64b compilations and the platforms on which we run the test cases. Thanks, Honnappa On 21 June 2017 at 11:38, Honnappa Nagarahalli wrote: > Hi, >I think there is a need to identify tools and specific versions of > the tools from patch acceptance perspective. Any failures outside of > these versions should be the responsibility of the person facing the > issues, they should submit a patch for those versions and tools. > > Travis CI is a step in that direction. But I think we still allow > submissions of patches via email. So, for this case, should we > standardize the tools and versions being used in Travis CI as the > acceptance criteria? > > Thanks, > Honnappa
[lng-odp] Need to standardize tools version
Hi, I think there is a need to identify tools and specific versions of the tools from patch acceptance perspective. Any failures outside of these versions should be the responsibility of the person facing the issues, they should submit a patch for those versions and tools. Travis CI is a step in that direction. But I think we still allow submissions of patches via email. So, for this case, should we standardize the tools and versions being used in Travis CI as the acceptance criteria? Thanks, Honnappa
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
On 20/06/2017, 15:12, "Savolainen, Petri (Nokia - FI/Espoo)" wrote: >> +++ b/platform/linux-generic/include/odp_llqueue.h >> @@ -0,0 +1,309 @@ >> +/* Copyright (c) 2017, ARM Limited. >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier:BSD-3-Clause >> + */ >> + >> +#ifndef ODP_LLQUEUE_H_ >> +#define ODP_LLQUEUE_H_ >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> >>+/*** >>* >> ** >> + * Linked list queues >> + >> >>* >>* >> ***/ >> + >> +struct llqueue; >> +struct llnode; >> + >> +static struct llnode *llq_head(struct llqueue *llq); >> +static void llqueue_init(struct llqueue *llq); >> +static void llq_enqueue(struct llqueue *llq, struct llnode *node); >> +static struct llnode *llq_dequeue(struct llqueue *llq); >> +static odp_bool_t llq_dequeue_cond(struct llqueue *llq, struct llnode >> *exp); >> +static odp_bool_t llq_cond_rotate(struct llqueue *llq, struct llnode >> *node); >> +static odp_bool_t llq_on_queue(struct llnode *node); >> + >> >>+/*** >>* >> ** >> + * The implementation(s) >> + >> >>* >>* >> ***/ >> + >> +#define SENTINEL ((void *)~(uintptr_t)0) >> + >> +#ifdef CONFIG_LLDSCD >> +/* Implement queue operations using double-word LL/SC */ > >> + >> +#else >> +/* Implement queue operations protected by a spin lock */ >> + > >There's a lot of ifdef'ed code in this file, basically two full parallel >implementations. This horse has been flogged before on the mailing list. > The first is built only for ARM and the second for the rest. Would there >be a way to build both always ? For ARMv7a and ARMv8a, you could build both versions. You really want to use the LL/SC version on these architectures. For architectures without double-word LL/SC, only the lock-based version can be built. > >-Petri >
Re: [lng-odp] [API-NEXT PATCH v9 2/6] linux-gen: sched scalable: add arch files
On 20/06/2017, 15:00, "Savolainen, Petri (Nokia - FI/Espoo)" wrote: > >> +#endif /* PLATFORM_LINUXGENERIC_ARCH_ARM_CPU_IDLING_H */ >> diff --git a/platform/linux-generic/arch/arm/odp_llsc.h >>b/platform/linux- >> generic/arch/arm/odp_llsc.h >> new file mode 100644 >> index ..3ab5c909 >> --- /dev/null >> +++ b/platform/linux-generic/arch/arm/odp_llsc.h >> @@ -0,0 +1,249 @@ >> +/* Copyright (c) 2017, ARM Limited >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +#ifndef PLATFORM_LINUXGENERIC_ARCH_ARM_LLSC_H >> +#define PLATFORM_LINUXGENERIC_ARCH_ARM_LLSC_H >> + >> +#ifndef PLATFORM_LINUXGENERIC_ARCH_ARM_ODP_CPU_H >> +#error This file should not be included directly, please include >> odp_cpu.h >> +#endif >> + >> +#if __ARM_ARCH == 7 || (__ARM_ARCH == 8 && __ARM_64BIT_STATE == 0) >> + > > >> + >> +#if __ARM_ARCH == 8 && __ARM_64BIT_STATE == 1 >> + > >Build broken for ARMv6? There are so many #ifdefs that it's hard to tell >which code path is built. GCC preprocessor symbols for the ARM architecture(s) is a mess (and different with different compiler versions I think) but that¹s not our fault. > Maybe it would make sense to explicitly document/report an error when >building for a non-supported ARM target. E.g. the original raspberry pi >is ARMv6, it's possible that someone is building odp-linux for that... Different versions of the ARM architecture are actually more or less different architectures from an ODP perspective. Perhaps the architecture recognition should be more specific and identify ARMv7a and ARMv8a (32-bit and 64-bit) and treat everything else as "default². I think ODP should use the default (aka generic) arch implementation when the architecture is not recognised/supported. > >-Petri > >
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
I think we have talked about this earlier. We have been directed from our executives that we should use ARM copyright if a member has done this work and Linaro/LNG/FF/Bill are in sync on this. Thanks, Honnappa On 21 June 2017 at 10:10, Maxim Uvarov wrote: > On 06/21/17 17:27, Honnappa Nagarahalli wrote: >> >> Hi Maxim, >> This is a new file added by us. Hence the ARM copyright. >> Thanks, >> Honnappa >> > > Was this work done as Linaro member/assignee? If yes - it has to have Linaro > copyright as I know. > > Maxim. > > >> On 21 June 2017 at 09:06, Maxim Uvarov wrote: >>> >>> On 06/19/17 22:12, Brian Brooks wrote: --- /dev/null +++ b/platform/linux-generic/include/odp_llqueue.h @@ -0,0 +1,309 @@ +/* Copyright (c) 2017, ARM Limited. + * All rights reserved. + * + * SPDX-License-Identifier:BSD-3-Clause + */ + >>> >>> >>> >>> Has to be Linaro copyright. >>> >>> Maxim. > >
[lng-odp] [Linaro/odp] 4bcd15: linux-gen: queue: clean up after modular interface
Branch: refs/heads/api-next Home: https://github.com/Linaro/odp Commit: 4bcd15e2bfb839ac0ef6419aa9e7b720958638f7 https://github.com/Linaro/odp/commit/4bcd15e2bfb839ac0ef6419aa9e7b720958638f7 Author: Petri Savolainen Date: 2017-06-21 (Wed, 21 Jun 2017) Changed paths: M platform/linux-generic/include/odp_queue_if.h M platform/linux-generic/include/odp_queue_internal.h M platform/linux-generic/include/odp_schedule_if.h M platform/linux-generic/odp_queue.c M platform/linux-generic/odp_schedule.c M platform/linux-generic/odp_schedule_iquery.c M platform/linux-generic/odp_schedule_sp.c Log Message: --- linux-gen: queue: clean up after modular interface Clean up function and parameter naming after modular interface patch. Queue_t type is referred as "queue internal": queue_int or q_int. Term "handle" is reserved for API level handles (e.g. odp_queue_t, odp_pktio_t, etc) through out linux-gen implementation. Signed-off-by: Petri Savolainen Reviewed-and-tested-by: Bill Fischofer Signed-off-by: Maxim Uvarov
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
On 06/21/17 17:27, Honnappa Nagarahalli wrote: Hi Maxim, This is a new file added by us. Hence the ARM copyright. Thanks, Honnappa Was this work done as Linaro member/assignee? If yes - it has to have Linaro copyright as I know. Maxim. On 21 June 2017 at 09:06, Maxim Uvarov wrote: On 06/19/17 22:12, Brian Brooks wrote: --- /dev/null +++ b/platform/linux-generic/include/odp_llqueue.h @@ -0,0 +1,309 @@ +/* Copyright (c) 2017, ARM Limited. + * All rights reserved. + * + * SPDX-License-Identifier:BSD-3-Clause + */ + Has to be Linaro copyright. Maxim.
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
On 06/19/17 22:12, Brian Brooks wrote: Signed-off-by: Ola Liljedahl Reviewed-by: Brian Brooks --- platform/linux-generic/Makefile.am | 1 + platform/linux-generic/include/odp_llqueue.h | 309 +++ 2 files changed, 310 insertions(+) create mode 100644 platform/linux-generic/include/odp_llqueue.h diff --git a/platform/linux-generic/Makefile.am b/platform/linux-generic/Makefile.am index b869fd4b..90cc4ca6 100644 --- a/platform/linux-generic/Makefile.am +++ b/platform/linux-generic/Makefile.am @@ -157,6 +157,7 @@ noinst_HEADERS = \ ${srcdir}/include/odp_errno_define.h \ ${srcdir}/include/odp_forward_typedefs_internal.h \ ${srcdir}/include/odp_internal.h \ + ${srcdir}/include/odp_llqueue.h \ ${srcdir}/include/odp_name_table_internal.h \ ${srcdir}/include/odp_packet_internal.h \ ${srcdir}/include/odp_packet_io_internal.h \ diff --git a/platform/linux-generic/include/odp_llqueue.h b/platform/linux-generic/include/odp_llqueue.h new file mode 100644 index ..758af490 --- /dev/null +++ b/platform/linux-generic/include/odp_llqueue.h @@ -0,0 +1,309 @@ +/* Copyright (c) 2017, ARM Limited. + * All rights reserved. + * + * SPDX-License-Identifier:BSD-3-Clause + */ + +#ifndef ODP_LLQUEUE_H_ +#define ODP_LLQUEUE_H_ + +#include +#include +#include + +#include +#include +#include + +#include +#include + +/** + * Linked list queues + */ + +struct llqueue; +struct llnode; + +static struct llnode *llq_head(struct llqueue *llq); +static void llqueue_init(struct llqueue *llq); +static void llq_enqueue(struct llqueue *llq, struct llnode *node); +static struct llnode *llq_dequeue(struct llqueue *llq); +static odp_bool_t llq_dequeue_cond(struct llqueue *llq, struct llnode *exp); +static odp_bool_t llq_cond_rotate(struct llqueue *llq, struct llnode *node); +static odp_bool_t llq_on_queue(struct llnode *node); + +/** + * The implementation(s) + */ + +#define SENTINEL ((void *)~(uintptr_t)0) + +#ifdef CONFIG_LLDSCD +/* Implement queue operations using double-word LL/SC */ + +/* The scalar equivalent of a double pointer */ +#if __SIZEOF_PTRDIFF_T__ == 4 +typedef uint64_t dintptr_t; +#endif +#if __SIZEOF_PTRDIFF_T__ == 8 +typedef __int128 dintptr_t; +#endif + +struct llnode { + struct llnode *next; +}; + +union llht { + struct { + struct llnode *head, *tail; + } st; + dintptr_t ui; you use dintptr_t only once. It's here. No need for typedef. Remove ifdef above. Place it here and change to #else if. And code will be 2 times smaller. +}; + +struct llqueue { + union llht u; +}; that looks not clear for me. 'struct llqueue' and 'union llht' is the same thing. After that you reference to it that as 'struct llqueue' in function arguments and 'union llht' inside the function. Like bellow... + +static inline struct llnode *llq_head(struct llqueue *llq) +{ + return __atomic_load_n(&llq->u.st.head, __ATOMIC_RELAXED); +} + +static inline void llqueue_init(struct llqueue *llq) +{ + llq->u.st.head = NULL; + llq->u.st.tail = NULL; +} + +static inline void llq_enqueue(struct llqueue *llq, struct llnode *node) +{ + union llht old, neu; + here. btw neu has to be new, right? + ODP_ASSERT(node->next == NULL); + node->next = SENTINEL; + do { + old.ui = lld(&llq->u.ui, __ATOMIC_RELAXED); + neu.st.head = old.st.head == NULL ? node : old.st.head; + neu.st.tail = node; + } while (odp_unlikely(scd(&llq->u.ui, neu.ui, __ATOMIC_RELEASE))); + if (old.st.tail != NULL) { + /* List was not empty */ + ODP_ASSERT(old.st.tail->next == SENTINEL); + old.st.tail->next = node; + } +} + +static inline struct llnode *llq_dequeue(struct llqueue *llq) +{ + struct llnode *head; + union llht old, neu; + + /* llq_dequeue() may be used in a busy-waiting fashion +* Read head using plain load to avoid disturbing remote LL/SC +*/ + head = __atomic_load_n(&llq->u.st.head, __ATOMIC_ACQUIRE); + if (head == NULL) + return NULL; + /* Read head->next before LL to minimize cache miss latency +* in LL/SC below +*/ + (void)__atomic_load_n(&head->next, __ATOMIC_RELAXED); + + do { + old.ui = lld(&llq->u.ui, __ATOMIC_RELAXED); + if (odp_unlikely(old.st.head == NULL)) { + /* Empty list */ + return NULL; + } else if (odp_unlikel
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
Hi Maxim, This is a new file added by us. Hence the ARM copyright. Thanks, Honnappa On 21 June 2017 at 09:06, Maxim Uvarov wrote: > On 06/19/17 22:12, Brian Brooks wrote: >> >> --- /dev/null >> +++ b/platform/linux-generic/include/odp_llqueue.h >> @@ -0,0 +1,309 @@ >> +/* Copyright (c) 2017, ARM Limited. >> + * All rights reserved. >> + * >> + * SPDX-License-Identifier:BSD-3-Clause >> + */ >> + > > > Has to be Linaro copyright. > > Maxim.
Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event
On 16 June 2017 at 13:49, Petri Savolainen wrote: > Applies on top of: "[API-NEXT PATCH v2 0/2] IPsec API update" > > Input and output of IPSEC operations are packets. Parameter and > result structures are cleaner when packet arrays are direct > parameters to functions. Also API is more flexible for > application or API pipelining when output is packets with > additional metadata. Application or API pipeline stages which > do not care about IPSEC results may work on basic packet metadata. For the whole series: Reviewed-by: Dmitry Eremin-Solenikov -- With best wishes Dmitry
Re: [lng-odp] [API-NEXT PATCH v9 4/6] linux-gen: sched scalable: add a concurrent queue
On 06/19/17 22:12, Brian Brooks wrote: --- /dev/null +++ b/platform/linux-generic/include/odp_llqueue.h @@ -0,0 +1,309 @@ +/* Copyright (c) 2017, ARM Limited. + * All rights reserved. + * + * SPDX-License-Identifier:BSD-3-Clause + */ + Has to be Linaro copyright. Maxim.
Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event
For the series: Reviewed-by: Nikhil Agarwal -Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala Manoharan Sent: Wednesday, June 21, 2017 6:58 PM To: Petri Savolainen Cc: lng-odp-forward Subject: Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event For the series: Reviewed-by: Balasubramanian Manoharan On 16 June 2017 at 16:19, Petri Savolainen wrote: > Applies on top of: "[API-NEXT PATCH v2 0/2] IPsec API update" > > Input and output of IPSEC operations are packets. Parameter and result > structures are cleaner when packet arrays are direct parameters to > functions. Also API is more flexible for application or API pipelining > when output is packets with additional metadata. Application or API > pipeline stages which do not care about IPSEC results may work on > basic packet metadata. > > v3: > * typo corrected (Bill) > > v2: > * Introduce event subtype > * event type "packet" is the same for all packets > * event subtype "packet_ipsec" indicates that a packet contain > IPSEC results > * Added output packet format description, which was accidentally left out > from previous version (moved text from deleted result type to > odp_ipsec_in() / odp_ipsec_out() documentation) > > > Petri Savolainen (3): > api: event: add subtype to expand event type > api: ipsec: change IPSEC result to packet > api: ipsec: disable event is the last event > > include/odp/api/spec/event.h | 80 +++- > include/odp/api/spec/ipsec.h | 417 > - > include/odp/arch/default/api/abi/event.h | 9 +- > .../include/odp/api/plat/event_types.h | 8 +- > platform/linux-generic/odp_ipsec.c | 67 +++- > 5 files changed, 372 insertions(+), 209 deletions(-) > > -- > 2.13.0 > >
Re: [lng-odp] [API-NEXT PATCH v3 0/3] IPSEC packet event
For the series: Reviewed-by: Balasubramanian Manoharan On 16 June 2017 at 16:19, Petri Savolainen wrote: > Applies on top of: "[API-NEXT PATCH v2 0/2] IPsec API update" > > Input and output of IPSEC operations are packets. Parameter and > result structures are cleaner when packet arrays are direct > parameters to functions. Also API is more flexible for > application or API pipelining when output is packets with > additional metadata. Application or API pipeline stages which > do not care about IPSEC results may work on basic packet metadata. > > v3: > * typo corrected (Bill) > > v2: > * Introduce event subtype > * event type "packet" is the same for all packets > * event subtype "packet_ipsec" indicates that a packet contain IPSEC > results > * Added output packet format description, which was accidentally left out > from previous version (moved text from deleted result type to > odp_ipsec_in() / odp_ipsec_out() documentation) > > > Petri Savolainen (3): > api: event: add subtype to expand event type > api: ipsec: change IPSEC result to packet > api: ipsec: disable event is the last event > > include/odp/api/spec/event.h | 80 +++- > include/odp/api/spec/ipsec.h | 417 > - > include/odp/arch/default/api/abi/event.h | 9 +- > .../include/odp/api/plat/event_types.h | 8 +- > platform/linux-generic/odp_ipsec.c | 67 +++- > 5 files changed, 372 insertions(+), 209 deletions(-) > > -- > 2.13.0 > >
Re: [lng-odp] [PATCH v4] example: add IPv4 fragmentation/reassembly example
On 06/13/17 17:44, Joe Savage wrote: Any progress on this, Maxim? Merged! Maxim.
Re: [lng-odp] [PATCH v3 3/3] travis: enable tests when make distcheck
On 06/21/17 11:00, Github ODP bot wrote: From: Yi He Make distcheck with all test configurations to confirm test programs installation in odp distribution package. Signed-off-by: Yi He --- /** Email created from pull request 35 (heyi-linaro:install-check) ** https://github.com/Linaro/odp/pull/35 ** Patch: https://github.com/Linaro/odp/pull/35.patch ** Base sha: 0d24adacfe17c8e0e1348f19cd8b75b64cb13ccf ** Merge commit sha: 98a29bbfe0330710e92fce70c7b3243bee460257 **/ .travis.yml | 2 +- Makefile.am | 9 ++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 50b3b9c2..95f30fee 100644 --- a/.travis.yml +++ b/.travis.yml @@ -136,7 +136,7 @@ jobs: compiler: gcc script: - ./bootstrap - - ./configure + - ./configure --prefix=$HOME/odp-install --enable-test-cpp --enable-test-vald --enable-test-helper --enable-test-perf --enable-user-guides --enable-test-perf-proc --enable-test-example - sudo LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" make distcheck - stage: test env: TEST=doxygen diff --git a/Makefile.am b/Makefile.am index daa49788..b43d1be6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,8 +1,11 @@ ACLOCAL_AMFLAGS=-I m4 AUTOMAKE_OPTIONS = foreign -AM_DISTCHECK_CONFIGURE_FLAGS = --enable-test-cpp \ - --enable-test-perf \ - --enable-test-vald \ +AM_DISTCHECK_CONFIGURE_FLAGS = --enable-test-cpp \ + --enable-test-perf \ + --enable-test-vald \ + --enable-test-helper \ + --enable-test-example\ + --enable-test-perf-proc \ --with-testdir I think that is good to test all options for distribution. Only 2 comments: 1. travis changes better to do separate. 2. please do alphabetical order of that list. does configure; make distcheck without options still work after that changes? Maxim. #@with_platform@ works alone in subdir but not as part of a path???
[lng-odp] [Linaro/odp] ebbd83: api: ipsec: refine packet order specification
Branch: refs/heads/api-next Home: https://github.com/Linaro/odp Commit: ebbd8301f396e3f2f106ed94ce5c3970ec8bacce https://github.com/Linaro/odp/commit/ebbd8301f396e3f2f106ed94ce5c3970ec8bacce Author: Petri Savolainen Date: 2017-06-20 (Tue, 20 Jun 2017) Changed paths: M include/odp/api/spec/ipsec.h Log Message: --- api: ipsec: refine packet order specification State more explicitly that async ipsec operations maintain packet order the same way as odp_queue_enq_multi(). Signed-off-by: Petri Savolainen Reviewed-by: Bill Fischofer Reviewed-by: Balasubramanian Manoharan Signed-off-by: Maxim Uvarov Commit: 58a8ec90b57eae43be6461d1ae407e70a87c65d2 https://github.com/Linaro/odp/commit/58a8ec90b57eae43be6461d1ae407e70a87c65d2 Author: Petri Savolainen Date: 2017-06-20 (Tue, 20 Jun 2017) Changed paths: M include/odp/api/spec/ipsec.h Log Message: --- api: ipsec: add max number of cos capability Added capability for maximum number of different CoS in CLS pipelining. Signed-off-by: Petri Savolainen Reviewed-by: Bill Fischofer Reviewed-by: Balasubramanian Manoharan Signed-off-by: Maxim Uvarov Compare: https://github.com/Linaro/odp/compare/a5ef33a6f257...58a8ec90b57e
[lng-odp] [Linaro/odp] f43379: example: add IPv4 fragmentation/reassembly example
Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: f4337956ee3be1e783e2389eb5a5ceecb4b0b0ca https://github.com/Linaro/odp/commit/f4337956ee3be1e783e2389eb5a5ceecb4b0b0ca Author: Joe Savage Date: 2017-06-21 (Wed, 21 Jun 2017) Changed paths: M doc/application-api-guide/examples.dox M example/Makefile.am A example/ipfragreass/.gitignore A example/ipfragreass/Makefile.am A example/ipfragreass/odp_ipfragreass.c A example/ipfragreass/odp_ipfragreass_atomics.h A example/ipfragreass/odp_ipfragreass_atomics_arm.h A example/ipfragreass/odp_ipfragreass_fragment.c A example/ipfragreass/odp_ipfragreass_fragment.h A example/ipfragreass/odp_ipfragreass_helpers.c A example/ipfragreass/odp_ipfragreass_helpers.h A example/ipfragreass/odp_ipfragreass_ip.h A example/ipfragreass/odp_ipfragreass_reassemble.c A example/ipfragreass/odp_ipfragreass_reassemble.h M example/m4/configure.m4 Log Message: --- example: add IPv4 fragmentation/reassembly example Add an example application implementing lock-free IPv4 fragmentation and reassembly functionality using ODP's packet "concat" and "split". Signed-off-by: Joe Savage Reviewed-and-tested-by: Bill Fischofer Signed-off-by: Maxim Uvarov
[lng-odp] [Linaro/odp] cd1f18: linux-gen: improve conversion between buf_hdr_t an...
Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: cd1f187d33d65cb54781b5a3c0864229b19c11c3 https://github.com/Linaro/odp/commit/cd1f187d33d65cb54781b5a3c0864229b19c11c3 Author: Joyce Kong Date: 2017-06-20 (Tue, 20 Jun 2017) Changed paths: M platform/linux-generic/include/odp_packet_internal.h M platform/linux-generic/odp_packet_io.c M platform/linux-generic/pktio/loop.c Log Message: --- linux-gen: improve conversion between buf_hdr_t and packet_t Signed-off-by: Joyce Kong Reviewed-and-tested-by: Bill Fischofer Reviewed-by: Brian Brooks Signed-off-by: Maxim Uvarov
Re: [lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
I've confirmed this is benign on x86. Brian: Please review for ARM. On Wed, Jun 21, 2017 at 6:48 AM, Petri Savolainen wrote: > Use __aarch64__ instead of __ARM_ARCH, since it's backwards > compatible between GCC versions. > > Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 > > Signed-off-by: Petri Savolainen > --- > platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c > b/platform/linux-generic/arch/arm/odp_cpu_arch.c > index 91d439d9..fd1b3ed6 100644 > --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c > +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c > @@ -68,7 +68,7 @@ int cpu_has_global_time(void) > > uint64_t cpu_global_time(void) > { > -#if __ARM_ARCH == 8 > +#if __aarch64__ > uint64_t cntvct; > > /* > @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) > > uint64_t cpu_global_time_freq(void) > { > -#if __ARM_ARCH == 8 > +#if __aarch64__ > uint64_t cntfrq; > > __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); > -- > 2.13.0 >
Re: [lng-odp] [RFC API-NEXT] api: crypto: change crypto result to packet
On 21.06.2017 14:48, Dmitry Eremin-Solenikov wrote: > Input and output of crypto operations are packets. API is more flexible > for application and API pipelining when output is packet with additional > metadata. Application or API pipeline stages which do not care about > crypto results may work on basic packet metadata. > > Crypto result event type changes from ODP_EVENT_CRYPTO_COMPL to > ODP_EVENT_PACKET. Event subtype (ODP_EVENT_PACKET_CRYPTO) can be > used to identify packets with crypto metadata. > > Signed-off-by: Dmitry Eremin-Solenikov > --- > This depends on all previous patches related to IPsec and event types. This RFC was posted mostly to consult wrt: - split single API call to two for SYNC and ASYNC operation This is to follow IPsec lead. - behaviour wrt in_place decoding: Currently we have per-operation option of specifying output packet (and allocating from pool if INVALID packet was provided). This patch provides same behaviour for SYNC operation and always reuses packet for ASYNC operation. Another option can be: allocate new packet if pool was provided, reuse packet if no pool was provided. To provide fine-grained control, it might be feasible to move pool to crypto_op_param instead of crypto_session_param. -- With best wishes Dmitry
Re: [lng-odp] [RFC API-NEXT] api: crypto: change crypto result to packet
On Wed, Jun 21, 2017 at 6:48 AM, Dmitry Eremin-Solenikov wrote: > Input and output of crypto operations are packets. API is more flexible > for application and API pipelining when output is packet with additional > metadata. Application or API pipeline stages which do not care about > crypto results may work on basic packet metadata. > > Crypto result event type changes from ODP_EVENT_CRYPTO_COMPL to > ODP_EVENT_PACKET. Event subtype (ODP_EVENT_PACKET_CRYPTO) can be > used to identify packets with crypto metadata. > > Signed-off-by: Dmitry Eremin-Solenikov > --- > This depends on all previous patches related to IPsec and event types. > > include/odp/api/spec/crypto.h | 120 > + > include/odp/api/spec/event.h | 2 - > include/odp/arch/default/api/abi/crypto.h | 1 - > include/odp/arch/default/api/abi/event.h | 6 +- > .../include/odp/api/plat/crypto_types.h| 1 - > .../include/odp/api/plat/event_types.h | 6 +- > 6 files changed, 54 insertions(+), 82 deletions(-) > > diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h > index 470cba05066f..fc2a3b8f0b97 100644 > --- a/include/odp/api/spec/crypto.h > +++ b/include/odp/api/spec/crypto.h > @@ -39,11 +39,6 @@ extern "C" { > */ > > /** > - * @typedef odp_crypto_compl_t > -* Crypto API completion event (platform dependent). > -*/ > - > -/** > * Crypto API operation mode > */ > typedef enum { > @@ -337,28 +332,6 @@ typedef struct odp_crypto_op_param_t { > /** User context */ > void *ctx; > > - /** Input packet > -* > -* Specifies the input packet for the crypto operation. When the > -* 'out_pkt' variable is set to ODP_PACKET_INVALID (indicating a new > -* packet should be allocated for the resulting packet). > -*/ > - odp_packet_t pkt; > - > - /** Output packet > -* > -* Both "in place" (the original packet 'pkt' is modified) and > -* "copy" (the packet is replicated to a new packet which contains > -* the modified data) modes are supported. The "in place" mode of > -* operation is indicated by setting 'out_pkt' equal to 'pkt'. > -* For the copy mode of operation, setting 'out_pkt' to a valid > packet > -* value indicates the caller wishes to specify the destination > packet. > -* Setting 'out_pkt' to ODP_PACKET_INVALID indicates the caller > wishes > -* the destination packet be allocated from the output pool specified > -* during session creation. > -*/ > - odp_packet_t out_pkt; > - > /** Override session IV pointer */ > uint8_t *override_iv_ptr; > > @@ -438,14 +411,14 @@ typedef enum { > /** > * Cryto API per packet operation completion status > */ > -typedef struct odp_crypto_compl_status { > +typedef struct odp_crypto_op_status { > /** Algorithm specific return code */ > odp_crypto_alg_err_t alg_err; > > /** Hardware specific return code */ > odp_crypto_hw_err_t hw_err; > > -} odp_crypto_compl_status_t; > +} odp_crypto_op_status_t; > > /** > * Crypto API operation result > @@ -457,14 +430,11 @@ typedef struct odp_crypto_op_result { > /** User context from request */ > void *ctx; > > - /** Output packet */ > - odp_packet_t pkt; > - > /** Cipher status */ > - odp_crypto_compl_status_t cipher_status; > + odp_crypto_op_status_t cipher_status; > > /** Authentication status */ > - odp_crypto_compl_status_t auth_status; > + odp_crypto_op_status_t auth_status; > > } odp_crypto_op_result_t; > > @@ -609,61 +579,80 @@ int > odp_crypto_session_create(odp_crypto_session_param_t *param, > int odp_crypto_session_destroy(odp_crypto_session_t session); > > /** > - * Return crypto completion handle that is associated with event > + * Return crypto processed packet that is associated with event > + * > + * Get packet handle to an crypto processed packet event. Event subtype must > be > + * ODP_EVENT_CRYPTO_PACKET. Crypto operation results can be examined with ODP_EVENT_PACKET_CRYPTO > + * odp_crypto_result(). > * > * Note: any invalid parameters will cause undefined behavior and may cause > * the application to abort or crash. > * > - * @param ev An event of type ODP_EVENT_CRYPTO_COMPL > + * @param ev Event handle > * > - * @return crypto completion handle > + * @return Packet handle > */ > -odp_crypto_compl_t odp_crypto_compl_from_event(odp_event_t ev); > +odp_packet_t odp_crypto_packet_from_event(odp_event_t ev); > > /** > - * Convert crypto completion handle to event handle > + * Convert crypto packet handle to event > + * > + * The packet handle must be an output of an crypto operation. > * > - * @param completion_event Completion event to convert to generic event > + * @param pkt Packet han
Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v2 0/2] IPsec API update
+1 Now that api-next has been re-sync'd with master we need to clear out the reviewed patches that were pending the release of v1.15. On Wed, Jun 21, 2017 at 7:00 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > > Ping. This was reviewed two weeks ago. The "IPSEC packet event" patch set > goes on top of this. > > > >> -Original Message- >> From: Savolainen, Petri (Nokia - FI/Espoo) >> Sent: Thursday, June 15, 2017 10:52 AM >> To: Maxim Uvarov >> Cc: lng-odp-forward >> Subject: RE: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec >> API update >> >> Ping. >> >> > -Original Message- >> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> > Savolainen, Petri (Nokia - FI/Espoo) >> > Sent: Thursday, June 08, 2017 4:07 PM >> > To: Bill Fischofer >> > Cc: lng-odp-forward >> > Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec >> API >> > update >> > >> > Ping. Next IPSec patch will be on top of this. >> > >> > > -Original Message- >> > > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] >> > > Sent: Tuesday, June 06, 2017 3:00 AM >> > > To: Petri Savolainen >> > > Cc: lng-odp-forward >> > > Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec API update >> > > >> > > For v2: >> > > >> > > Reviewed-by: Bill Fischofer >> > > >> > > On Fri, Jun 2, 2017 at 4:38 AM, Petri Savolainen >> > > wrote: >> > > > Bill has reviewed v1. >> > > > >> > > > v2 >> > > > * rebase >> > > > * removed "api: ipsec: add capability for max packets per result >> > event" >> > > from >> > > > the set while we decide if result event are changed to packets >> > > > * updated max_cls_cos documentation with CLS capability (Bill) >> > > > >> > > > Petri Savolainen (2): >> > > > api: ipsec: refine packet order specification >> > > > api: ipsec: add max number of cos capability >> > > > >> > > > include/odp/api/spec/ipsec.h | 49 ++--- >> -- >> > -- >> > > --- >> > > > 1 file changed, 34 insertions(+), 15 deletions(-) >> > > > >> > > > -- >> > > > 2.11.0 >> > > >
Re: [lng-odp] Suspected SPAM - Re: [API-NEXT PATCH v2 0/2] IPsec API update
Ping. This was reviewed two weeks ago. The "IPSEC packet event" patch set goes on top of this. > -Original Message- > From: Savolainen, Petri (Nokia - FI/Espoo) > Sent: Thursday, June 15, 2017 10:52 AM > To: Maxim Uvarov > Cc: lng-odp-forward > Subject: RE: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec > API update > > Ping. > > > -Original Message- > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > > Savolainen, Petri (Nokia - FI/Espoo) > > Sent: Thursday, June 08, 2017 4:07 PM > > To: Bill Fischofer > > Cc: lng-odp-forward > > Subject: Suspected SPAM - Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec > API > > update > > > > Ping. Next IPSec patch will be on top of this. > > > > > -Original Message- > > > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > > > Sent: Tuesday, June 06, 2017 3:00 AM > > > To: Petri Savolainen > > > Cc: lng-odp-forward > > > Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec API update > > > > > > For v2: > > > > > > Reviewed-by: Bill Fischofer > > > > > > On Fri, Jun 2, 2017 at 4:38 AM, Petri Savolainen > > > wrote: > > > > Bill has reviewed v1. > > > > > > > > v2 > > > > * rebase > > > > * removed "api: ipsec: add capability for max packets per result > > event" > > > from > > > > the set while we decide if result event are changed to packets > > > > * updated max_cls_cos documentation with CLS capability (Bill) > > > > > > > > Petri Savolainen (2): > > > > api: ipsec: refine packet order specification > > > > api: ipsec: add max number of cos capability > > > > > > > > include/odp/api/spec/ipsec.h | 49 ++--- > -- > > -- > > > --- > > > > 1 file changed, 34 insertions(+), 15 deletions(-) > > > > > > > > -- > > > > 2.11.0 > > > >
[lng-odp] [PATCH] linux-gen: time: fix ARM compile for GCC 4.8
Use __aarch64__ instead of __ARM_ARCH, since it's backwards compatible between GCC versions. Fixes bug https://bugs.linaro.org/show_bug.cgi?id=3066 Signed-off-by: Petri Savolainen --- platform/linux-generic/arch/arm/odp_cpu_arch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/platform/linux-generic/arch/arm/odp_cpu_arch.c b/platform/linux-generic/arch/arm/odp_cpu_arch.c index 91d439d9..fd1b3ed6 100644 --- a/platform/linux-generic/arch/arm/odp_cpu_arch.c +++ b/platform/linux-generic/arch/arm/odp_cpu_arch.c @@ -68,7 +68,7 @@ int cpu_has_global_time(void) uint64_t cpu_global_time(void) { -#if __ARM_ARCH == 8 +#if __aarch64__ uint64_t cntvct; /* @@ -88,7 +88,7 @@ uint64_t cpu_global_time(void) uint64_t cpu_global_time_freq(void) { -#if __ARM_ARCH == 8 +#if __aarch64__ uint64_t cntfrq; __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(cntfrq) : : ); -- 2.13.0
[lng-odp] [RFC API-NEXT] api: crypto: change crypto result to packet
Input and output of crypto operations are packets. API is more flexible for application and API pipelining when output is packet with additional metadata. Application or API pipeline stages which do not care about crypto results may work on basic packet metadata. Crypto result event type changes from ODP_EVENT_CRYPTO_COMPL to ODP_EVENT_PACKET. Event subtype (ODP_EVENT_PACKET_CRYPTO) can be used to identify packets with crypto metadata. Signed-off-by: Dmitry Eremin-Solenikov --- This depends on all previous patches related to IPsec and event types. include/odp/api/spec/crypto.h | 120 + include/odp/api/spec/event.h | 2 - include/odp/arch/default/api/abi/crypto.h | 1 - include/odp/arch/default/api/abi/event.h | 6 +- .../include/odp/api/plat/crypto_types.h| 1 - .../include/odp/api/plat/event_types.h | 6 +- 6 files changed, 54 insertions(+), 82 deletions(-) diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h index 470cba05066f..fc2a3b8f0b97 100644 --- a/include/odp/api/spec/crypto.h +++ b/include/odp/api/spec/crypto.h @@ -39,11 +39,6 @@ extern "C" { */ /** - * @typedef odp_crypto_compl_t -* Crypto API completion event (platform dependent). -*/ - -/** * Crypto API operation mode */ typedef enum { @@ -337,28 +332,6 @@ typedef struct odp_crypto_op_param_t { /** User context */ void *ctx; - /** Input packet -* -* Specifies the input packet for the crypto operation. When the -* 'out_pkt' variable is set to ODP_PACKET_INVALID (indicating a new -* packet should be allocated for the resulting packet). -*/ - odp_packet_t pkt; - - /** Output packet -* -* Both "in place" (the original packet 'pkt' is modified) and -* "copy" (the packet is replicated to a new packet which contains -* the modified data) modes are supported. The "in place" mode of -* operation is indicated by setting 'out_pkt' equal to 'pkt'. -* For the copy mode of operation, setting 'out_pkt' to a valid packet -* value indicates the caller wishes to specify the destination packet. -* Setting 'out_pkt' to ODP_PACKET_INVALID indicates the caller wishes -* the destination packet be allocated from the output pool specified -* during session creation. -*/ - odp_packet_t out_pkt; - /** Override session IV pointer */ uint8_t *override_iv_ptr; @@ -438,14 +411,14 @@ typedef enum { /** * Cryto API per packet operation completion status */ -typedef struct odp_crypto_compl_status { +typedef struct odp_crypto_op_status { /** Algorithm specific return code */ odp_crypto_alg_err_t alg_err; /** Hardware specific return code */ odp_crypto_hw_err_t hw_err; -} odp_crypto_compl_status_t; +} odp_crypto_op_status_t; /** * Crypto API operation result @@ -457,14 +430,11 @@ typedef struct odp_crypto_op_result { /** User context from request */ void *ctx; - /** Output packet */ - odp_packet_t pkt; - /** Cipher status */ - odp_crypto_compl_status_t cipher_status; + odp_crypto_op_status_t cipher_status; /** Authentication status */ - odp_crypto_compl_status_t auth_status; + odp_crypto_op_status_t auth_status; } odp_crypto_op_result_t; @@ -609,61 +579,80 @@ int odp_crypto_session_create(odp_crypto_session_param_t *param, int odp_crypto_session_destroy(odp_crypto_session_t session); /** - * Return crypto completion handle that is associated with event + * Return crypto processed packet that is associated with event + * + * Get packet handle to an crypto processed packet event. Event subtype must be + * ODP_EVENT_CRYPTO_PACKET. Crypto operation results can be examined with + * odp_crypto_result(). * * Note: any invalid parameters will cause undefined behavior and may cause * the application to abort or crash. * - * @param ev An event of type ODP_EVENT_CRYPTO_COMPL + * @param ev Event handle * - * @return crypto completion handle + * @return Packet handle */ -odp_crypto_compl_t odp_crypto_compl_from_event(odp_event_t ev); +odp_packet_t odp_crypto_packet_from_event(odp_event_t ev); /** - * Convert crypto completion handle to event handle + * Convert crypto packet handle to event + * + * The packet handle must be an output of an crypto operation. * - * @param completion_event Completion event to convert to generic event + * @param pkt Packet handle from crypto operation * * @return Event handle */ -odp_event_t odp_crypto_compl_to_event(odp_crypto_compl_t completion_event); +odp_event_t odp_crypto_packet_to_event(odp_packet_t pkt); /** - * Release crypto completion event + * Crypto per packet operation + * + * Performs the SYNC cryptographic operations specified during ses
[lng-odp] [Bug 3066] New: Cross compile broken for ARMv8
https://bugs.linaro.org/show_bug.cgi?id=3066 Bug ID: 3066 Summary: Cross compile broken for ARMv8 Product: OpenDataPlane - linux- generic reference Version: master Hardware: Other OS: Linux Status: UNCONFIRMED Severity: blocker Priority: --- Component: Build system Assignee: maxim.uva...@linaro.org Reporter: petri.savolai...@linaro.org CC: lng-odp@lists.linaro.org Target Milestone: --- Latest commit (arch: arm: add CPU global time) broke build for ARM. CC arch/arm/odp_cpu_arch.lo arch/arm/odp_cpu_arch.c: In function \u2018cpu_global_time\u2019: arch/arm/odp_cpu_arch.c:71:5: error: "__ARM_ARCH" is not defined [-Werror=undef] #if __ARM_ARCH == 8 Compiler version: aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4 It seems that __ARM_ARCH is not supported by GCC 4.8, but __aarch64__ would be. I think we should change to: #if __aarch64__ -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Linaro/odp]
Branch: refs/heads/revert-47-fix-devio-race Home: https://github.com/Linaro/odp
[lng-odp] [Linaro/odp] f0e099: Revert "drv: driver: fix devio registration race"
Branch: refs/heads/revert-47-fix-devio-race Home: https://github.com/Linaro/odp Commit: f0e09934c1519dc7c5f34ddbd174eed03de418c8 https://github.com/Linaro/odp/commit/f0e09934c1519dc7c5f34ddbd174eed03de418c8 Author: He Yi Date: 2017-06-21 (Wed, 21 Jun 2017) Changed paths: M platform/linux-generic/drv_driver.c Log Message: --- Revert "drv: driver: fix devio registration race" This reverts commit 76edf89deaf0fa126f34b6cd58f4373d211f0c33.
[lng-odp] [CLOUD-DEV] ddf: examples: add ddf module skeleton and ddf application
Signed-off-by: Bogdan Pricope --- example/Makefile.am | 4 +- example/ddf_app/Makefile.am | 10 example/ddf_app/odp_ddf_app.c | 49 +++ example/ddf_ifs/Makefile.am | 26 ++ example/ddf_ifs/ddf_ifs.c | 28 +++ example/ddf_ifs/ddf_ifs.h | 18 +++ example/ddf_ifs/ddf_ifs_api.h | 25 ++ example/ddf_ifs/ddf_ifs_dev_dpdk.c | 25 ++ example/ddf_ifs/ddf_ifs_dev_dpdk.h | 24 + example/ddf_ifs/ddf_ifs_devio_direct.c | 51 +++ example/ddf_ifs/ddf_ifs_devio_direct.h | 20 example/ddf_ifs/ddf_ifs_driver.c| 69 ++ example/ddf_ifs/ddf_ifs_driver.h| 20 example/ddf_ifs/ddf_ifs_enumr_class.c | 47 ++ example/ddf_ifs/ddf_ifs_enumr_class.h | 20 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 + example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++ example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 example/ddf_ifs/odp.conf| 4 ++ example/m4/configure.m4 | 2 + 21 files changed, 624 insertions(+), 1 deletion(-) create mode 100644 example/ddf_app/Makefile.am create mode 100644 example/ddf_app/odp_ddf_app.c create mode 100644 example/ddf_ifs/Makefile.am create mode 100644 example/ddf_ifs/ddf_ifs.c create mode 100644 example/ddf_ifs/ddf_ifs.h create mode 100644 example/ddf_ifs/ddf_ifs_api.h create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h create mode 100644 example/ddf_ifs/ddf_ifs_driver.c create mode 100644 example/ddf_ifs/ddf_ifs_driver.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h create mode 100644 example/ddf_ifs/odp.conf diff --git a/example/Makefile.am b/example/Makefile.am index dfc07b6..b209585 100644 --- a/example/Makefile.am +++ b/example/Makefile.am @@ -8,4 +8,6 @@ SUBDIRS = classifier \ switch \ time \ timer \ - traffic_mgmt + traffic_mgmt \ + ddf_ifs \ + ddf_app diff --git a/example/ddf_app/Makefile.am b/example/ddf_app/Makefile.am new file mode 100644 index 000..e654202 --- /dev/null +++ b/example/ddf_app/Makefile.am @@ -0,0 +1,10 @@ +include $(top_srcdir)/example/Makefile.inc + +bin_PROGRAMS = odp_ddf_app$(EXEEXT) +odp_ddf_app_LDFLAGS = $(AM_LDFLAGS) -shared +odp_ddf_app_CFLAGS = $(AM_CFLAGS) -I${top_srcdir}/example + +noinst_HEADERS = \ + $(top_srcdir)/example/example_debug.h + +dist_odp_ddf_app_SOURCES = odp_ddf_app.c diff --git a/example/ddf_app/odp_ddf_app.c b/example/ddf_app/odp_ddf_app.c new file mode 100644 index 000..c2d7abf --- /dev/null +++ b/example/ddf_app/odp_ddf_app.c @@ -0,0 +1,49 @@ +/* Copyright (c) 2014, Linaro Limited + * All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +/** enable strtok */ +#ifndef _GNU_SOURCE +#define _GNU_SOURCE +#endif + +#include +#include + +#include +#include +#include +#include + +int main(int argc, char *argv[]) +{ + odp_instance_t instance; + + (void)argc; + (void)argv; + + EXAMPLE_DBG("Start DDF Application...\n"); + + /* Initialize ODP before calling anything else */ + if (odp_init_global(&instance, NULL, NULL)) { + EXAMPLE_ERR("Error: ODP global init failed.\n"); + exit(EXIT_FAILURE); + } + + if (odp_init_local(instance, ODP_THREAD_CONTROL)) { + EXAMPLE_ERR("Error: ODP local init failed.\n"); + exit(EXIT_FAILURE); + } + + /* Print ddf objects*/ + odpdrv_print_all(); + + /* Terminate ODP */ + odp_term_local(); + odp_term_global(instance); + + EXAMPLE_DBG("Exit DDF Application.\n"); + return 0; +} diff --git a/example/ddf_ifs/Makefile.am b/example/ddf_ifs/Makefile.am new file mode 100644 index 000..b11cf3d --- /dev/null +++ b/example/ddf_ifs/Makefile.am @@ -0,0 +1,26 @@ +LIB = $(top_builddir)/lib + +AM_CPPFLAGS += -I$(srcdir) \ + -I$(top_srcdir)/include \ + -I$(top_srcdir)/platform/@with_platform@/include \ + -I$(top_srcdir)/platform/@with_platform@/arch/@ARCH_DIR@ + +lib_LTLIBRARIES = $(LIB)/libddf_ifs.la + +noinst_HEADERS = \ +$(srcdir)/ddf_ifs.h \ +$(srcdir)/ddf_ifs_enumr_class.h \ +$(srcdir)/ddf_ifs_enumr_dpdk
[lng-odp] [CLOUD-DEV] ddf: examples: ddf module skeleton
This patch contains a ddf module skeleton (example) and a ddf model application. Was designed to highlight (print) DDF operations/steps. Module is loaded at init_global time through odp configuration file (modules section). Usage: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/odp/lib/.libs ODP_SYSCONFIG_FILE=/home/odp/example/ddf_ifs/odp.conf ./example/ddf_app/odp_ddf_app Bogdan Pricope (1): ddf: examples: add ddf module skeleton and ddf application example/Makefile.am | 4 +- example/ddf_app/Makefile.am | 10 example/ddf_app/odp_ddf_app.c | 49 +++ example/ddf_ifs/Makefile.am | 26 ++ example/ddf_ifs/ddf_ifs.c | 28 +++ example/ddf_ifs/ddf_ifs.h | 18 +++ example/ddf_ifs/ddf_ifs_api.h | 25 ++ example/ddf_ifs/ddf_ifs_dev_dpdk.c | 25 ++ example/ddf_ifs/ddf_ifs_dev_dpdk.h | 24 + example/ddf_ifs/ddf_ifs_devio_direct.c | 51 +++ example/ddf_ifs/ddf_ifs_devio_direct.h | 20 example/ddf_ifs/ddf_ifs_driver.c| 69 ++ example/ddf_ifs/ddf_ifs_driver.h| 20 example/ddf_ifs/ddf_ifs_enumr_class.c | 47 ++ example/ddf_ifs/ddf_ifs_enumr_class.h | 20 example/ddf_ifs/ddf_ifs_enumr_dpdk.c| 86 + example/ddf_ifs/ddf_ifs_enumr_dpdk.h| 20 example/ddf_ifs/ddf_ifs_enumr_generic.c | 57 ++ example/ddf_ifs/ddf_ifs_enumr_generic.h | 20 example/ddf_ifs/odp.conf| 4 ++ example/m4/configure.m4 | 2 + 21 files changed, 624 insertions(+), 1 deletion(-) create mode 100644 example/ddf_app/Makefile.am create mode 100644 example/ddf_app/odp_ddf_app.c create mode 100644 example/ddf_ifs/Makefile.am create mode 100644 example/ddf_ifs/ddf_ifs.c create mode 100644 example/ddf_ifs/ddf_ifs.h create mode 100644 example/ddf_ifs/ddf_ifs_api.h create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.c create mode 100644 example/ddf_ifs/ddf_ifs_dev_dpdk.h create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.c create mode 100644 example/ddf_ifs/ddf_ifs_devio_direct.h create mode 100644 example/ddf_ifs/ddf_ifs_driver.c create mode 100644 example/ddf_ifs/ddf_ifs_driver.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_class.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_dpdk.h create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.c create mode 100644 example/ddf_ifs/ddf_ifs_enumr_generic.h create mode 100644 example/ddf_ifs/odp.conf -- 1.9.1
[lng-odp] [PATCH v3 3/3] travis: enable tests when make distcheck
From: Yi He Make distcheck with all test configurations to confirm test programs installation in odp distribution package. Signed-off-by: Yi He --- /** Email created from pull request 35 (heyi-linaro:install-check) ** https://github.com/Linaro/odp/pull/35 ** Patch: https://github.com/Linaro/odp/pull/35.patch ** Base sha: 0d24adacfe17c8e0e1348f19cd8b75b64cb13ccf ** Merge commit sha: 98a29bbfe0330710e92fce70c7b3243bee460257 **/ .travis.yml | 2 +- Makefile.am | 9 ++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 50b3b9c2..95f30fee 100644 --- a/.travis.yml +++ b/.travis.yml @@ -136,7 +136,7 @@ jobs: compiler: gcc script: - ./bootstrap - - ./configure + - ./configure --prefix=$HOME/odp-install --enable-test-cpp --enable-test-vald --enable-test-helper --enable-test-perf --enable-user-guides --enable-test-perf-proc --enable-test-example - sudo LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" make distcheck - stage: test env: TEST=doxygen diff --git a/Makefile.am b/Makefile.am index daa49788..b43d1be6 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,8 +1,11 @@ ACLOCAL_AMFLAGS=-I m4 AUTOMAKE_OPTIONS = foreign -AM_DISTCHECK_CONFIGURE_FLAGS = --enable-test-cpp \ - --enable-test-perf \ - --enable-test-vald \ +AM_DISTCHECK_CONFIGURE_FLAGS = --enable-test-cpp \ + --enable-test-perf \ + --enable-test-vald \ + --enable-test-helper \ + --enable-test-example\ + --enable-test-perf-proc \ --with-testdir #@with_platform@ works alone in subdir but not as part of a path???
[lng-odp] [PATCH v3 1/3] test: traffic_mngr: fix distcheck failure
From: Yi He When configured odp with --enable-test-vald, make distcheck will fail by not being able to find the traffic_mngr test binary and script in the distribution. This patch installs traffic_mngr test_PROGRAMS and test_SCRIPTS in distribution build. Signed-off-by: Yi He --- /** Email created from pull request 35 (heyi-linaro:install-check) ** https://github.com/Linaro/odp/pull/35 ** Patch: https://github.com/Linaro/odp/pull/35.patch ** Base sha: 0d24adacfe17c8e0e1348f19cd8b75b64cb13ccf ** Merge commit sha: 98a29bbfe0330710e92fce70c7b3243bee460257 **/ test/common_plat/validation/api/traffic_mngr/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/test/common_plat/validation/api/traffic_mngr/Makefile.am b/test/common_plat/validation/api/traffic_mngr/Makefile.am index a012c1b3..44d50a91 100644 --- a/test/common_plat/validation/api/traffic_mngr/Makefile.am +++ b/test/common_plat/validation/api/traffic_mngr/Makefile.am @@ -10,9 +10,10 @@ TESTS = $(TESTSCRIPTS) noinst_LTLIBRARIES = libtesttraffic_mngr.la libtesttraffic_mngr_la_SOURCES = traffic_mngr.c -bin_PROGRAMS = traffic_mngr_main$(EXEEXT) +test_PROGRAMS = traffic_mngr_main$(EXEEXT) dist_traffic_mngr_main_SOURCES = traffic_mngr_main.c traffic_mngr_main_LDADD = libtesttraffic_mngr.la -lm $(LIBCUNIT_COMMON) $(LIBODP) EXTRA_DIST = traffic_mngr.h $(TESTSCRIPTS) dist_check_SCRIPTS = $(TESTSCRIPTS) +test_SCRIPTS = $(dist_check_SCRIPTS)
[lng-odp] [PATCH v3 0/3] test: fix distcheck failures when configured ODP with tests enabled
make install-check failed by not able to find traffic_mngr test binary and script in the installation. this patch changes Makefile.am to install test_PROGRAMS and test_SCRIPTS. Signed-off-by: Yi He yi...@linaro.org github /** Email created from pull request 35 (heyi-linaro:install-check) ** https://github.com/Linaro/odp/pull/35 ** Patch: https://github.com/Linaro/odp/pull/35.patch ** Base sha: 0d24adacfe17c8e0e1348f19cd8b75b64cb13ccf ** Merge commit sha: 98a29bbfe0330710e92fce70c7b3243bee460257 **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 11 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. total: 0 errors, 0 warnings, 0 checks, 4 lines checked to_send-p-001.patch has no obvious style problems and is ready for submission. total: 0 errors, 0 warnings, 0 checks, 22 lines checked to_send-p-002.patch has no obvious style problems and is ready for submission. /checkpatch.pl
[lng-odp] [PATCH v3 2/3] test: time: fix distcheck failure
From: Yi He When configured odp with --enable-test-vald, make distcheck will fail by not being able to find the test script time.sh in the distribution. This patch installs time test_SCRIPTS in distribution build. Signed-off-by: Yi He --- /** Email created from pull request 35 (heyi-linaro:install-check) ** https://github.com/Linaro/odp/pull/35 ** Patch: https://github.com/Linaro/odp/pull/35.patch ** Base sha: 0d24adacfe17c8e0e1348f19cd8b75b64cb13ccf ** Merge commit sha: 98a29bbfe0330710e92fce70c7b3243bee460257 **/ test/common_plat/validation/api/time/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/test/common_plat/validation/api/time/Makefile.am b/test/common_plat/validation/api/time/Makefile.am index 82682dfc..ca9c0562 100644 --- a/test/common_plat/validation/api/time/Makefile.am +++ b/test/common_plat/validation/api/time/Makefile.am @@ -16,3 +16,4 @@ time_main_LDADD = libtesttime.la $(LIBCUNIT_COMMON) $(LIBODP) EXTRA_DIST = time_test.h $(TESTSCRIPTS) dist_check_SCRIPTS = $(TESTSCRIPTS) +test_SCRIPTS = $(dist_check_SCRIPTS)
[lng-odp] [Linaro/odp] 76edf8: drv: driver: fix devio registration race
Branch: refs/heads/cloud-dev Home: https://github.com/Linaro/odp Commit: 76edf89deaf0fa126f34b6cd58f4373d211f0c33 https://github.com/Linaro/odp/commit/76edf89deaf0fa126f34b6cd58f4373d211f0c33 Author: Josep Puigdemont Date: 2017-06-21 (Wed, 21 Jun 2017) Changed paths: M platform/linux-generic/drv_driver.c Log Message: --- drv: driver: fix devio registration race This fixes a race condition that could arise when registering a devio. Signed-off-by: Josep Puigdemont