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 1B90FA0C4C; Wed, 18 Aug 2021 18:47:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 002A3411C7; Wed, 18 Aug 2021 18:47:57 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 5C76F41134 for ; Wed, 18 Aug 2021 18:47:57 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id j12-20020a17090aeb0c00b00179530520b3so9353203pjz.0 for ; Wed, 18 Aug 2021 09:47:57 -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=mrg0dwkJgFaGpiMS0K/UQWWoyMxjeaC/wWgHr7vxMcg=; b=dNV3BPjkBrf+S4+M5+sRdlhIj5eyLNifTPAux5spEmoarxFJfrKad0XEfWkNu9Osl0 MuUQ0bDrL3xgZbJ7cSFh7FBIeyxKFyTwLfRo6pcAmfc1GPYh0NBpgRH1EzK+LtJDPFqU aPiE8KDAxpveSq4LUWowg5n/ttSdS/rW3ZTrDxLMng48knrfMfkSAb3OvxfFUpKJVhaf aMJVmBAzRo+mK/iVxIWR802FYPztucUrhRsXJ7EgoocKRodTiGNETivWIKbC2E2ojwKC EFVDo1nl8dH0yziBxiLSSgPXoCM9MBAwTMYHd5sJRl+YaM0NCwuUc9qZhzuxIen41P2l AcuA== 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=mrg0dwkJgFaGpiMS0K/UQWWoyMxjeaC/wWgHr7vxMcg=; b=pBvzT4yqFLY4LF4cta1/kYCWT2K4B7CxlXpa5VH0T+z1p4wSKUo/2sSGFXOt7YCqJo wRghakbzvVs1MZTKlO7nuxPeLmzZ9rbCVgX0WacUFZfaP9KqtiNVY0WRkhNx2y1w6HyY sNGX8YClo7mURzJScqNt26SAivXiG1Kv3EfmTg7ty7yWgj+GiMQjXR314z6oeiQLOz61 Li6uOdMcLRUi1gP7Xj413Z+BC8iiMI7vXEwe/51zmoYfvHjn+Vu/mWPGWhUxG169Z3mG IBged7W9oLYU2ChmuLJ6Mpu5p8maWggElKgWz+KLpWnd8vg/IMTFRIQRxTMKaegex9LE rRsA== X-Gm-Message-State: AOAM533pAUXN/cRUMUdLpluHX+fMenODcehygZp4fkJ991rdL33nesSl JaBCbJD77I3GaUyiN6MefgUVdQ== X-Google-Smtp-Source: ABdhPJzFuJ2ZpRXMtbKUzoTjUlotpyMhHJEKiFtNBKPf9zMQyeYLsDu09GqNwQ93zJDrUFSHOY+0iQ== X-Received: by 2002:a17:902:b20e:b029:12b:fd6f:44c3 with SMTP id t14-20020a170902b20eb029012bfd6f44c3mr7961870plr.36.1629305276466; Wed, 18 Aug 2021 09:47:56 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id k197sm280694pfd.190.2021.08.18.09.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 09:47:56 -0700 (PDT) Date: Wed, 18 Aug 2021 09:47:53 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Aman Singh , , Andrew Rybchenko Message-ID: <20210818094753.375fe50a@hermes.local> In-Reply-To: <4d013531-152c-d282-25ea-78786d314f47@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> <20210817100040.08518200@hermes.local> <4d013531-152c-d282-25ea-78786d314f47@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 Wed, 18 Aug 2021 09:23:09 +0100 Ferruh Yigit wrote: > On 8/17/2021 6:00 PM, Stephen Hemminger wrote: > > 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). > > > > It is not changing the format in a way to use spaces, macro is: > #define RTE_ETHER_ADDR_PRT_FMT "%02x:%02x:%02x:%02x:%02x:%02x" > > API is 'rte_ether_format_addr()': "%02X:%02X:%02X:%02X:%02X:%02X" > > So only case changes (if we update 'rte_ether_format_addr()'). > Ok, case should not matter