DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] eal: fix spelling errors
@ 2020-03-10 16:32 Stephen Hemminger
  2020-03-10 16:35 ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2020-03-10 16:32 UTC (permalink / raw)
  To: dev; +Cc: Stephen Hemminger

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/

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 lib/librte_eal/common/eal_common_fbarray.c             | 2 +-
 lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 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 +-
 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 1312f936b833..4f8f1af73cd6 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_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 859ae129d8d1..b6c725074f62 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -87,7 +87,7 @@ rte_atomic128_cmp_exchange(rte_int128_t *dst, rte_int128_t *exp,
 		const rte_int128_t *src, unsigned int weak, int success,
 		int failure)
 {
-	/* Always do strong CAS */
+	/* Always do strong CASE */
 	RTE_SET_USED(weak);
 	/* Ignore memory ordering for failure, memory order for
 	 * success must be stronger or equal
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 859b09748c56..f79718ce8ca7 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 148398f50ab7..b9dcd30aba9a 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 885d00424bd4..51cdfc5d599b 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);
-- 
2.20.1


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-04-24 16:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-10 16:32 [dpdk-dev] [PATCH] eal: fix spelling errors Stephen Hemminger
2020-03-10 16:35 ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
2020-04-24 16:28   ` Thomas Monjalon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).