From patchwork Tue Mar 10 16:35:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 66513 X-Patchwork-Delegate: thomas@monjalon.net 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 3D0B2A0566; Tue, 10 Mar 2020 17:35:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 23D771C010; Tue, 10 Mar 2020 17:35:27 +0100 (CET) Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by dpdk.org (Postfix) with ESMTP id 4A63E1BFF8 for ; Tue, 10 Mar 2020 17:35:25 +0100 (CET) Received: by mail-pj1-f67.google.com with SMTP id a16so652128pju.3 for ; Tue, 10 Mar 2020 09:35:25 -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:in-reply-to:references :mime-version:content-transfer-encoding; bh=z8bvs4CNY0CiXGvJYktlMtEwOhC3/iDAxjvdV74Miz0=; b=YnS83IsVeoAS5x+f6oe35l02GN/vw06YjZHx3NsUbumo5arrOL3z4bkfFxwEymlcra HnLbHSMqONIsqSYs3KK+lvZQXCAmVgAryVnzdw8ogmVhgZUpNvL2ANfiWz1OvgCb5hTA dNQTGn0pL08mS6g1157cbZxVIexrUiWj/o68xF6wY4k71azB7qUCuu0IL5SIXi1fFBgh ozNJZr/Ajn2C0W7sS7h4UEsIsjIZOEwC6wRS4T2ZEGFJKTGmIpSGJKge/Lyw54q8ShIu /kC3FGWKOu4i6TBQg29DCN46QQ/KXIwizYF8wEvUcMqNsNnu7WNFS0Xo7wO+GQlr5IrR 5Wqg== 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=z8bvs4CNY0CiXGvJYktlMtEwOhC3/iDAxjvdV74Miz0=; b=Zl+tsTC+K0X6r/IDgx/Yc6TyewlS0shFJpEWsOnZ5wpss38dii0F2Ndf5xL5VlcTVJ HxrcjdO0uPE4OBQypuS2UBQxg/rNW0jQYEgOURu47wBrdRHBNEXDE2t8iD3sfElKtNOq ddt3bNzf2V5bVB6PlJUET4zp76yPJG09fQSm93jGy2DU9NR6DNyrUuVE9/aMPxSSP57x LQBgE4dpv8NsllSDdsG0zenAXmOc9mOx9ge/oopbXilW/9QuGVwX6xiyKXdnO71c/+H3 7ylFWXz4VR5saypvarbCZHhDMVgIh89gl2H249xJYz/Cjk+ZzihgdK7xo8JBbQGiHWbG Q2ww== X-Gm-Message-State: ANhLgQ0ThgorRe7Lmfc39rfNwgtrOwaDyQNaLQbFPUPD5vBgIMMMHlm6 dottGDr9uC12cxsSu55LbM8X1XfvfRk= X-Google-Smtp-Source: ADFU+vs9JpbRb8Ct5r4rNtr6gMBLm02E85mj4Ikd9/CZ90B5rcInRE/ow4ft0WrjYv/EqWk2FqEm8A== X-Received: by 2002:a17:902:7c8e:: with SMTP id y14mr20503092pll.139.1583858123931; Tue, 10 Mar 2020 09:35:23 -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 w25sm47501519pfi.106.2020.03.10.09.35.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 09:35:23 -0700 (PDT) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger Date: Tue, 10 Mar 2020 09:35:20 -0700 Message-Id: <20200310163520.9009-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200310163202.8565-1-stephen@networkplumber.org> References: <20200310163202.8565-1-stephen@networkplumber.org> MIME-Version: 1.0 Subject: [dpdk-dev] [PATCH v2] 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 --- v2 - drop mistaken fix to arm/rte_atomic_64.h 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 +- 4 files changed, 4 insertions(+), 4 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_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);