diff mbox series

eal: fix spelling errors

Message ID 20200310163202.8565-1-stephen@networkplumber.org (mailing list archive)
State Superseded, archived
Headers show
Series eal: fix spelling errors | expand

Checks

Context Check Description
ci/Intel-compilation success Compilation OK
ci/travis-robot warning Travis build: failed
ci/checkpatch success coding style OK

Commit Message

Stephen Hemminger March 10, 2020, 4:32 p.m. UTC
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 mbox series

Patch

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);