eal: fix comments spelling

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")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

diff --git a/lib/librte_eal/arm/include/rte_cycles_32.h b/lib/librte_eal/arm/include/rte_cycles_32.h
index 859b097..f79718c 100644 (file)
--- 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 1312f93..4f8f1af 100644 (file)
--- 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/malloc_elem.c b/lib/librte_eal/common/malloc_elem.c
index 885d004..51cdfc5 100644 (file)
--- 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_memory.c b/lib/librte_eal/freebsd/eal_memory.c
index a97d8f0..5bc2da1 100644 (file)
--- a/lib/librte_eal/freebsd/eal_memory.c
+++ b/lib/librte_eal/freebsd/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;

diff --git a/lib/librte_eal/x86/include/rte_atomic.h b/lib/librte_eal/x86/include/rte_atomic.h
index 148398f..b9dcd30 100644 (file)
--- 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