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 5983BA0093 for ; Tue, 19 May 2020 15:12:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 36BC71D72B; Tue, 19 May 2020 15:12:09 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 6BE7B1D702 for ; Tue, 19 May 2020 15:12:08 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id t8so730021wmi.0 for ; Tue, 19 May 2020 06:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=IW6LWknCCGhdddVe++0fHxO0Wz6AwmB/q8OThXdJ+O0=; b=dAurro8W5JGkWE6ijTCDPzDSUrtNKvYWo4nvRXfJykqWaFnwk/lEbrqCf4fDLuyXEK 4E37IZJm6kJ+wwJiyRgHDER7nfG7rSn8sjXQnhHyfmnPgY+gAO3xJMRnI3TMoLHGRr12 2fY3cIawlH/HLPvVWmJthzjZq9oIp1qDIZJT/AxskAe9DUTXBun/nrTDl69Q2hr9o7eC 6EHtBjoCiMmvwQMVfAKJqrCLbQvENllct7p+9qdlb/+SMBXb1C7bGIZZKloGLHVRhR6n XXDEmuYfaWN1ymAEqKsT9YlBp0OveUFT5qFQ4DCUTsAfDf/UiR+TOGW4td5VEZa/10/i yzmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=IW6LWknCCGhdddVe++0fHxO0Wz6AwmB/q8OThXdJ+O0=; b=bZZVwsmHd+uSSBHFYL0OWnDng7q2uaS6EW/rhtQQQTqOBlDVsSaJt7pdlYObjDSbsH NQr7N8vX2LQw+kvTt5OmS5v1mLVsiXUTsAymO39AHGlW319BFbBimHfm7Mtkkh8D74oN 5z2aO2q8p9FEKn+e+vVA2YvnkH9dZvkfoyPFW1e9YR6U0ovDixqsTZeWsctH6+KJx3+X 1mc/7nEujKUHNvVypiUo2Yd6TDHf8RUz2ES818OqEXxmM1vzDJOT7IdqrpTpu4DwUkzX 54mx9TIAYD/lBSTbZ3JOLuVUYbsbZxPfo7sib0L61MTgZSxfl4GsxsypBbKizqt27i8A by2w== X-Gm-Message-State: AOAM530dc/68V3CBa1oda++DIe+89o94RI5lj0ovQ/5uJlDI7W2x9rrv dntYDiygE+scSsP7dMpEV30Uu/LtSYqLucnx X-Google-Smtp-Source: ABdhPJyfAnrH+ZP0F2ZqxDwqFkhGvL9mriH/JAiR1WWIDVpFyeqpMe1mMhw49WrNd+nsLy+JJOlrlA== X-Received: by 2002:a1c:8148:: with SMTP id c69mr5639316wmd.144.1589893928121; Tue, 19 May 2020 06:12:08 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id m3sm20818102wrn.96.2020.05.19.06.12.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 06:12:07 -0700 (PDT) From: luca.boccassi@gmail.com To: Stephen Hemminger Cc: dpdk stable Date: Tue, 19 May 2020 14:04:15 +0100 Message-Id: <20200519130549.112823-120-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200519130549.112823-1-luca.boccassi@gmail.com> References: <20200519125804.104349-1-luca.boccassi@gmail.com> <20200519130549.112823-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'eal: fix comments spelling' has been queued to stable release 19.11.3 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 stable release 19.11.3 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/21/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. Thanks. Luca Boccassi --- >From 6be8fba61669dbf57b055c85b8d0b401acffa9bb 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/common/eal_common_fbarray.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 +- lib/librte_eal/freebsd/eal/eal_memory.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) 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 @@ -1337,7 +1337,7 @@ 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. */ rte_rwlock_read_lock(&arr->rwlock); 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 @@ -57,7 +57,7 @@ __rte_rdtsc_syscall(void) * asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r"(29)); * 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 __rte_rdtsc_pmccntr(void) 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 @@ -55,7 +55,7 @@ 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 * as the destination. From their experiments 128B(2 cache lines) below diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 885d00424b..51cdfc5d59 100644 --- a/lib/librte_eal/common/malloc_elem.c +++ b/lib/librte_eal/common/malloc_elem.c @@ -171,7 +171,7 @@ malloc_elem_insert(struct malloc_elem *elem) next_elem = NULL; 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; dist_from_end = RTE_PTR_DIFF(heap->last, elem); diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c index a97d8f0f0c..5bc2da160c 100644 --- a/lib/librte_eal/freebsd/eal/eal_memory.c +++ b/lib/librte_eal/freebsd/eal/eal_memory.c @@ -449,7 +449,7 @@ 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. */ avail_segs = (hpi->num_pages[0] * 2) - 1; -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-05-19 14:04:49.355478389 +0100 +++ 0120-eal-fix-comments-spelling.patch 2020-05-19 14:04:44.392651562 +0100 @@ -1,8 +1,10 @@ -From a9aa14d9aa755472ab4e2aae62524feed7e8731f Mon Sep 17 00:00:00 2001 +From 6be8fba61669dbf57b055c85b8d0b401acffa9bb 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 @@ -14,30 +16,16 @@ 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") -Cc: stable@dpdk.org Signed-off-by: Stephen Hemminger --- - 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 +- + lib/librte_eal/common/eal_common_fbarray.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 +- + lib/librte_eal/freebsd/eal/eal_memory.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) -diff --git a/lib/librte_eal/arm/include/rte_cycles_32.h b/lib/librte_eal/arm/include/rte_cycles_32.h -index 859b09748c..f79718ce8c 100644 ---- a/lib/librte_eal/arm/include/rte_cycles_32.h -+++ b/lib/librte_eal/arm/include/rte_cycles_32.h -@@ -57,7 +57,7 @@ __rte_rdtsc_syscall(void) - * asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r"(29)); - * 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 - __rte_rdtsc_pmccntr(void) 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 @@ -51,6 +39,32 @@ * read-locking the fbarray, so read lock here is OK. */ rte_rwlock_read_lock(&arr->rwlock); +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 +@@ -57,7 +57,7 @@ __rte_rdtsc_syscall(void) + * asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r"(29)); + * 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 + __rte_rdtsc_pmccntr(void) +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 +@@ -55,7 +55,7 @@ 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 + * as the destination. From their experiments 128B(2 cache lines) below diff --git a/lib/librte_eal/common/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c index 885d00424b..51cdfc5d59 100644 --- a/lib/librte_eal/common/malloc_elem.c @@ -64,10 +78,10 @@ uint64_t dist_from_start, dist_from_end; dist_from_end = RTE_PTR_DIFF(heap->last, elem); -diff --git a/lib/librte_eal/freebsd/eal_memory.c b/lib/librte_eal/freebsd/eal_memory.c +diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c index a97d8f0f0c..5bc2da160c 100644 ---- a/lib/librte_eal/freebsd/eal_memory.c -+++ b/lib/librte_eal/freebsd/eal_memory.c +--- a/lib/librte_eal/freebsd/eal/eal_memory.c ++++ b/lib/librte_eal/freebsd/eal/eal_memory.c @@ -449,7 +449,7 @@ memseg_primary_init(void) * * we need (N*2)-1 segments because we cannot guarantee that @@ -77,19 +91,6 @@ * that are non-contiguous. */ avail_segs = (hpi->num_pages[0] * 2) - 1; -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 -@@ -55,7 +55,7 @@ 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 - * as the destination. From their experiments 128B(2 cache lines) below -- 2.20.1