From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id ED339A0093 for ; Thu, 28 May 2020 18:26:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99F111DC13; Thu, 28 May 2020 18:26:41 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 7DA2C1DC13 for ; Thu, 28 May 2020 18:26:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590683197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hJvmnC4vtIcir3+dyMOLbphzSYWo4XJjQrwTLPENQcc=; b=TMcjmkDh5huyJG5LGb282z3rxAXcSCRu7w5UzSpAlkQK+6WHhJ8JXUBnyFtE0cHIc9GLPd wQsenP8g2jUEAp70XbYC70MWE2PMUI9XmaYYeV0xpzFrk/8+sEQKhigUumwW/gouaLhMe3 8rj3RTpHfz7epwRjG/c5ngrUSZYdi+0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-_ydVqw18NImlwZ55Vo0TyQ-1; Thu, 28 May 2020 12:26:20 -0400 X-MC-Unique: _ydVqw18NImlwZ55Vo0TyQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B7BF080183C; Thu, 28 May 2020 16:26:19 +0000 (UTC) Received: from rh.redhat.com (unknown [10.33.36.235]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096FF60C05; Thu, 28 May 2020 16:26:18 +0000 (UTC) From: Kevin Traynor To: Stephen Hemminger Cc: dpdk stable Date: Thu, 28 May 2020 17:23:18 +0100 Message-Id: <20200528162322.7863-91-ktraynor@redhat.com> In-Reply-To: <20200528162322.7863-1-ktraynor@redhat.com> References: <20200528162322.7863-1-ktraynor@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'eal: fix comments spelling' has been queued to LTS release 18.11.9 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, FYI, your patch has been queued to LTS release 18.11.9 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 06/03/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/kevintraynor/dpdk-stable-queue This queued commit can be viewed at: https://github.com/kevintraynor/dpdk-stable-queue/commit/b1f89a7d56b25797b12586c8e352bf93dff59272 Thanks. Kevin. --- >From b1f89a7d56b25797b12586c8e352bf93dff59272 Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Tue, 10 Mar 2020 09:35:20 -0700 Subject: [PATCH] eal: fix comments spelling [ upstream commit a9aa14d9aa755472ab4e2aae62524feed7e8731f ] Fix spelling errors in comments (found with codespell). Note that "inbetween" is not correct in English and should either be two words or better yet, the in can be dropped. https://www.grammarly.com/blog/in-between-or-inbetween/ Fixes: 12f45fa7e29b ("eal/arm: read timer from PMU if enabled") Fixes: 096ffd811fe2 ("eal/x86: use lock-prefixed instructions for SMP barrier") Fixes: 1d406458db47 ("mem: make segment preallocation OS-specific") Fixes: bb372060dad4 ("malloc: make heap a doubly-linked list") Fixes: 7353ee7344b4 ("fbarray: add API to find biggest used or free chunks") Signed-off-by: Stephen Hemminger --- lib/librte_eal/bsdapp/eal/eal_memory.c | 2 +- lib/librte_eal/common/include/arch/arm/rte_cycles_32.h | 2 +- lib/librte_eal/common/include/arch/x86/rte_atomic.h | 2 +- lib/librte_eal/common/malloc_elem.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c b/lib/librte_eal/bsdapp/eal/eal_memory.c index 4b092e1f21..418c4bb0aa 100644 --- a/lib/librte_eal/bsdapp/eal/eal_memory.c +++ b/lib/librte_eal/bsdapp/eal/eal_memory.c @@ -436,5 +436,5 @@ memseg_primary_init(void) * we need (N*2)-1 segments because we cannot guarantee that * each segment will be IOVA-contiguous with the previous one, - * so we will allocate more and put spaces inbetween segments + * so we will allocate more and put spaces between segments * that are non-contiguous. */ diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h index 859b09748c..f79718ce8c 100644 --- a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h +++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h @@ -58,5 +58,5 @@ __rte_rdtsc_syscall(void) * asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r"(0x8000000f)); * - * which is possible only from the priviledged mode (kernel space). + * which is possible only from the privileged mode (kernel space). */ static inline uint64_t diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic.h b/lib/librte_eal/common/include/arch/x86/rte_atomic.h index 148398f50a..b9dcd30aba 100644 --- a/lib/librte_eal/common/include/arch/x86/rte_atomic.h +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic.h @@ -56,5 +56,5 @@ extern "C" { * As pointed by Java guys, that makes possible to use lock-prefixed * instructions to get the same effect as mfence and on most modern HW - * that gives a better perfomance then using mfence: + * that gives a better performance then using mfence: * https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ * Basic idea is to use lock prefixed add with some dummy memory location diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 24e1eb55f3..69ff063883 100644 --- a/lib/librte_eal/common/malloc_elem.c +++ b/lib/librte_eal/common/malloc_elem.c @@ -158,5 +158,5 @@ malloc_elem_insert(struct malloc_elem *elem) heap->last = elem; } else { - /* the new memory is somewhere inbetween start and end */ + /* the new memory is somewhere between start and end */ uint64_t dist_from_start, dist_from_end; -- 2.21.3 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-05-28 17:13:03.815722601 +0100 +++ 0091-eal-fix-comments-spelling.patch 2020-05-28 17:12:59.187554454 +0100 @@ -1 +1 @@ -From a9aa14d9aa755472ab4e2aae62524feed7e8731f Mon Sep 17 00:00:00 2001 +From b1f89a7d56b25797b12586c8e352bf93dff59272 Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit a9aa14d9aa755472ab4e2aae62524feed7e8731f ] + @@ -17 +18,0 @@ -Cc: stable@dpdk.org @@ -21,6 +22,5 @@ - lib/librte_eal/arm/include/rte_cycles_32.h | 2 +- - lib/librte_eal/common/eal_common_fbarray.c | 2 +- - lib/librte_eal/common/malloc_elem.c | 2 +- - lib/librte_eal/freebsd/eal_memory.c | 2 +- - lib/librte_eal/x86/include/rte_atomic.h | 2 +- - 5 files changed, 5 insertions(+), 5 deletions(-) + lib/librte_eal/bsdapp/eal/eal_memory.c | 2 +- + lib/librte_eal/common/include/arch/arm/rte_cycles_32.h | 2 +- + lib/librte_eal/common/include/arch/x86/rte_atomic.h | 2 +- + lib/librte_eal/common/malloc_elem.c | 2 +- + 4 files changed, 4 insertions(+), 4 deletions(-) @@ -28 +28,12 @@ -diff --git a/lib/librte_eal/arm/include/rte_cycles_32.h b/lib/librte_eal/arm/include/rte_cycles_32.h +diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c b/lib/librte_eal/bsdapp/eal/eal_memory.c +index 4b092e1f21..418c4bb0aa 100644 +--- a/lib/librte_eal/bsdapp/eal/eal_memory.c ++++ b/lib/librte_eal/bsdapp/eal/eal_memory.c +@@ -436,5 +436,5 @@ memseg_primary_init(void) + * we need (N*2)-1 segments because we cannot guarantee that + * each segment will be IOVA-contiguous with the previous one, +- * so we will allocate more and put spaces inbetween segments ++ * so we will allocate more and put spaces between segments + * that are non-contiguous. + */ +diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h @@ -30,2 +41,2 @@ ---- a/lib/librte_eal/arm/include/rte_cycles_32.h -+++ b/lib/librte_eal/arm/include/rte_cycles_32.h +--- a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h ++++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h @@ -39,11 +50,11 @@ -diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c -index 1312f936b8..4f8f1af73c 100644 ---- a/lib/librte_eal/common/eal_common_fbarray.c -+++ b/lib/librte_eal/common/eal_common_fbarray.c -@@ -1338,5 +1338,5 @@ fbarray_find_biggest(struct rte_fbarray *arr, unsigned int start, bool used, - - /* the API's called are thread-safe, but something may still happen -- * inbetween the API calls, so lock the fbarray. all other API's are -+ * between the API calls, so lock the fbarray. all other API's are - * read-locking the fbarray, so read lock here is OK. - */ +diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic.h b/lib/librte_eal/common/include/arch/x86/rte_atomic.h +index 148398f50a..b9dcd30aba 100644 +--- a/lib/librte_eal/common/include/arch/x86/rte_atomic.h ++++ b/lib/librte_eal/common/include/arch/x86/rte_atomic.h +@@ -56,5 +56,5 @@ extern "C" { + * As pointed by Java guys, that makes possible to use lock-prefixed + * instructions to get the same effect as mfence and on most modern HW +- * that gives a better perfomance then using mfence: ++ * that gives a better performance then using mfence: + * https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ + * Basic idea is to use lock prefixed add with some dummy memory location @@ -51 +62 @@ -index 885d00424b..51cdfc5d59 100644 +index 24e1eb55f3..69ff063883 100644 @@ -54 +65 @@ -@@ -172,5 +172,5 @@ malloc_elem_insert(struct malloc_elem *elem) +@@ -158,5 +158,5 @@ malloc_elem_insert(struct malloc_elem *elem) @@ -61,22 +71,0 @@ -diff --git a/lib/librte_eal/freebsd/eal_memory.c b/lib/librte_eal/freebsd/eal_memory.c -index a97d8f0f0c..5bc2da160c 100644 ---- a/lib/librte_eal/freebsd/eal_memory.c -+++ b/lib/librte_eal/freebsd/eal_memory.c -@@ -450,5 +450,5 @@ memseg_primary_init(void) - * we need (N*2)-1 segments because we cannot guarantee that - * each segment will be IOVA-contiguous with the previous one, -- * so we will allocate more and put spaces inbetween segments -+ * so we will allocate more and put spaces between segments - * that are non-contiguous. - */ -diff --git a/lib/librte_eal/x86/include/rte_atomic.h b/lib/librte_eal/x86/include/rte_atomic.h -index 148398f50a..b9dcd30aba 100644 ---- a/lib/librte_eal/x86/include/rte_atomic.h -+++ b/lib/librte_eal/x86/include/rte_atomic.h -@@ -56,5 +56,5 @@ extern "C" { - * As pointed by Java guys, that makes possible to use lock-prefixed - * instructions to get the same effect as mfence and on most modern HW -- * that gives a better perfomance then using mfence: -+ * that gives a better performance then using mfence: - * https://shipilev.net/blog/2014/on-the-fence-with-dependencies/ - * Basic idea is to use lock prefixed add with some dummy memory location