From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 98E3DA0C43; Tue, 17 Aug 2021 19:00:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D79F40DF5; Tue, 17 Aug 2021 19:00:46 +0200 (CEST) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id AC2994014E for ; Tue, 17 Aug 2021 19:00:44 +0200 (CEST) Received: by mail-pl1-f170.google.com with SMTP id w6so18548794plg.9 for ; Tue, 17 Aug 2021 10:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Nv2EJBNF0rYm00Pz3inaP6WWUfTvhjtSPGqmnlsiujc=; b=gPNPxRaNBG8x5uk+S+5ddN59fdOhRrKnVrktwM4QVNuyYMkb4+MtrnYn56YKmOXvGV pWN919tvkjTufwQToX0K0S1WpmpYF+G2m+NQB60Ds/Hj7cmMPLs8gmOCA67RhsUoaSW0 I9IF7R633orywrJ6Z7FGZWJPTOEhf1KPgj7s+Zku9WGlAbLdNPRuDTioO+srdR3pBaNb XIEK8TE8YVOuphh0ee6tb/y8/frK44tXvLb+eqP668M5WKCQikAWlUG7GnrGRWSS2+Ra 39H3AP1cY3pltITXgbG9dvsqCiClxt46bOe1Ufkj2K+4/AvqKEqUEjzFWH3+iW3tm67G wZfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Nv2EJBNF0rYm00Pz3inaP6WWUfTvhjtSPGqmnlsiujc=; b=nCh7ubkQY2FGkqDz5u1RJfCDv3Fde6FTmRtem8UWc9SDX9464Et/3V60itcD+xfMCF 5yIJHg7ts6x7YvWPdwbDL1zpPuKHgOWp9D8zQHONeyiHEHJYzJ88RFkY7sSIIizuJCXo VzQbZt6b28IKxvzyfeNZCb/UOIu3z7jeS+poNe/5eOR279BwrWbht7SIhAvmy/ZoVdvY ztFmqkfTtDg4Ugk+C8mdQAfOU7WfYuDqu53KkQXggriB8v7ySRFPracZd8EX8LeYIyX+ M/MbkDQ4Y9sDqZHOYy4MpgZnb1/C9HFSj6f39c3Xb4uqbJH8JiaUpyFnmax4gtaDrOkc 0/oQ== X-Gm-Message-State: AOAM533lnNtvecOg/jBdx+79pOaGYihxGsaUBl24WEcfV2Z4FOwpE+pP Vgkh3ycsNtH59Qeyraa3msx6Xw== X-Google-Smtp-Source: ABdhPJx9ZAvaoeQKFnjRU2X8q5QC7zw/+5IZjroxjJPqsG1ZEurz3+K0yIICy/z1FhWFxsPK2DKXuw== X-Received: by 2002:a17:90a:db09:: with SMTP id g9mr4509736pjv.205.1629219643688; Tue, 17 Aug 2021 10:00:43 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id b6sm3507232pgs.94.2021.08.17.10.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 10:00:43 -0700 (PDT) Date: Tue, 17 Aug 2021 10:00:40 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Aman Singh , , Andrew Rybchenko Message-ID: <20210817100040.08518200@hermes.local> In-Reply-To: <31c1c42e-317d-d10f-ebe0-8d5058c09f75@intel.com> References: <20210816095728.17193-1-aman.deep.singh@intel.com> <20210816095728.17193-3-aman.deep.singh@intel.com> <20210816160347.0a35723a@hermes.local> <8b0c151c-fc49-59f2-863c-233f419f4d40@intel.com> <20210817082543.21ae2483@hermes.local> <31c1c42e-317d-d10f-ebe0-8d5058c09f75@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 2/2] net: added macro to extract MAC address bytes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Tue, 17 Aug 2021 17:44:51 +0100 Ferruh Yigit wrote: > On 8/17/2021 4:25 PM, Stephen Hemminger wrote: > > On Tue, 17 Aug 2021 09:11:17 +0100 > > Ferruh Yigit wrote: > > > >> On 8/17/2021 12:03 AM, Stephen Hemminger wrote: > >>> On Mon, 16 Aug 2021 15:27:28 +0530 > >>> Aman Singh wrote: > >>> > >>>> Added macros to simplify print of MAC address. > >>>> The six bytes of a MAC address are extracted in > >>>> a macro here, to improve code readablity. > >>>> > >>>> Signed-off-by: Aman Singh > >>>> Reviewed-by: Ferruh Yigit > >>>> --- > >>>> The change in the document will be done in seperate patch. > >>>> To ensure document has direct reference of the code as shown in > >>>> commit 413c75c33c40 ("doc: show how to include code in guides"). > >>> > >>> NAK > >>> The DPDK already has rte_ether_format_addr() > >>> why does so much code not use it? > >>> > >> > >> 'rte_ether_format_addr()' formats string to a buffer, but most of the times the > >> need is just to log and having a buffer for it is unnecessary. > >> > >> Both macros look useful to me. > > > > Yes, but it would be good if same format was used everywhere. > > > > Agree, and 'RTE_ETHER_ADDR_PRT_FMT' macro helps to unify the format without > forcing to create the buffer. > > We can use 'RTE_ETHER_ADDR_PRT_FMT' in the 'rte_ether_format_addr()' to unify > all output, the downside is it may change the output of the API, which may cause > trouble for some customers. > Other option is define 'RTE_ETHER_ADDR_PRT_FMT' as whatever > 'rte_ether_format_addr()' has, to not cause a change in the API, what do you think? Why change the format using spaces between parts is not standard. The standard ways of printing ether addresses on Linux is 00:01:02:03:04:05 (and on Windows 00-01-02-03-04-05).