From patchwork Tue Mar 10 16:32:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 66512 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E3E2BA0566; Tue, 10 Mar 2020 17:32:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BCD0C1C00D; Tue, 10 Mar 2020 17:32:09 +0100 (CET) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 6180D1BFFF for ; Tue, 10 Mar 2020 17:32:08 +0100 (CET) Received: by mail-pg1-f196.google.com with SMTP id b1so6529179pgm.8 for ; Tue, 10 Mar 2020 09:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=r9LkExIOl+P+eQGyxCQaUj+Q6xlU7cNkQMJu9elq5VE=; b=CjsP+yBPRvlQBW9GAFpaFOwGjQZS40UOyaU7jNeKl9vIyQ/Br3dQoFiavJxS+QamxL jTMGP+Jxfdz0XtDdagnhteKCwF7c3qNjIDXP8xLMkBb+1emWR8sG5itjpMYwTEgGHnAd lOL5ta64roYAIZT3YWU2+IKvBW7ZtWorfuw+uIFY2k/mjwwrPZ0JZyQ6hK5qVj1BCcQB pMV4qhXD15VVaTnpJH23pZ4R0mMC8MFaiT6FZ3N9nY7TS2KHqoGU0tyqP1oUkYHHfL9p 9OqZHS8tWHqCTEGt1rszfjoCCOcgtUnh9DfbvApoKCTDixw5z/nfLd/8jGZJ5Bey/Oxp jGTw== 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:mime-version :content-transfer-encoding; bh=r9LkExIOl+P+eQGyxCQaUj+Q6xlU7cNkQMJu9elq5VE=; b=hY+VGFZ5GpXda2GEEC+XQG7cihubIJ20yZnjgMmRdozgFlZ60GctxQHNsJ7cmwgn0e I59z8QyvDMl2v8Yfei4ohwabRsQWTzODAKbkqtjjxe82ytBmXS+abmtmV2T7QEZYbmMm 2fcLPAON3+ZaKNq3KnDHGq9kNIXWxApKJz1uQW7/bR/0jF218X5Xb6CgpVs3V0Xz5IIP BGrX5NitTK07QQP/v03k8xzuh+by8FzLBDQXVSKSVobQs+dfC7XPuwduhnSNtSj3RrgA dvEYvHiJePMCiTo9TfcR6BQBFJXHrzkhaVcMdJMGc/Br8voMxHTHui+L9G53WqaZJjXu Dbcw== X-Gm-Message-State: ANhLgQ24fvptILfnPJhfwhySiHobiP/igOU6e0SxqOmGiE06F8to9wxo n1/u9zOH0XOkCoMVBgg+5slRty7bF6I= X-Google-Smtp-Source: ADFU+vs8ddPeFWP8xweQ9L+w8FMuqFp+VRYMgf6Da4hEjJTgtatIyTcXsLthtobw1i5V5aRvouwSzg== X-Received: by 2002:a63:f243:: with SMTP id d3mr14277696pgk.254.1583857926925; Tue, 10 Mar 2020 09:32:06 -0700 (PDT) Received: from hermes.corp.microsoft.com (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id v67sm4009730pfc.120.2020.03.10.09.32.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 09:32:05 -0700 (PDT) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger Date: Tue, 10 Mar 2020 09:32:02 -0700 Message-Id: <20200310163202.8565-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [dpdk-dev] [PATCH] eal: fix spelling errors X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 --- 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);