From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <3chas3@gmail.com> Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by dpdk.org (Postfix) with ESMTP id CB81A594B for ; Wed, 2 Dec 2015 11:18:56 +0100 (CET) Received: by qgec40 with SMTP id c40so28702381qge.2 for ; Wed, 02 Dec 2015 02:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=EGQpPeHPt8dMjYQ8gm7biIvE3Xx4ZtH/SPlcMM9PRk4=; b=Y1XzcG2msTAm+GST1vEjtngYyM9/bMudyvws5DvWap9GNjzf4NbkoFYLJLfVUxQTbr 9r3aeNdGoY4LrCHU42mBOLOpvrmimaZiX3YTFhOAePk4bKVPUvEmHwx0kGkU+CowWhNh A4NAa56zKt2K5Pwn9rv4D7adMOGgTG/na8HKRUs3kMuzwo/7dffiKJdh03XblZsI4l5F Rx3wlx8Wjo5aDX4Pn7ZrE/6f/U4Muycc96eI0fa3bDJ4FeShzOASFEmpWmNIUWdChZkx 7s1xxTZlJwdfw/N2lzkCxvOLfOCSn/WGhWLGnDM5jW3Nyud4uRP/qCCudg+zcheFxSH3 BZdg== X-Received: by 10.140.30.180 with SMTP id d49mr2772288qgd.48.1449051536368; Wed, 02 Dec 2015 02:18:56 -0800 (PST) Received: from foobar.home (pool-71-163-182-126.washdc.fios.verizon.net. [71.163.182.126]) by smtp.googlemail.com with ESMTPSA id y200sm895715qka.48.2015.12.02.02.18.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 02:18:55 -0800 (PST) Message-ID: <1449051535.2645.49.camel@gmail.com> From: "Charles (Chas) Williams" <3chas3@gmail.com> To: Thomas Monjalon Date: Wed, 02 Dec 2015 05:18:55 -0500 In-Reply-To: <1462827.BQfOhHUEb5@xps13> References: <1446571576-28399-1-git-send-email-3chas3@gmail.com> <3362628.iLARgdqr6m@xps13> <1449014294.2645.42.camel@gmail.com> <1462827.BQfOhHUEb5@xps13> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] bnx2x: tx_start_bd->vlan_or_ethertype is le16 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 10:18:57 -0000 On Wed, 2015-12-02 at 02:04 +0100, Thomas Monjalon wrote: > 2015-12-01 18:58, Charles Williams: > > On Wed, 2015-12-02 at 00:34 +0100, Thomas Monjalon wrote: > > > 2015-12-01 14:37, Stephen Hemminger: > > > > Harish Patil wrote: > > > > > >2015-11-03 12:26, Chas Williams: > > > > > >> --- a/drivers/net/bnx2x/bnx2x.c > > > > > >> +++ b/drivers/net/bnx2x/bnx2x.c > > > > > >> - tx_start_bd->vlan_or_ethertype = eh->ether_type; > > > > > >> + tx_start_bd->vlan_or_ethertype > > > > > >> + = rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); > > > > > > > > > > Minor question - any specific reason to use rte_be_to_cpu_16() on > > > > > ether_type alone before converting from native order to le16? > > > > > > > > ether_type is in network byte order (big endian) > > > > and hardware wants little endian. On x86 the second step is a nop. > > > > > > Doesn't it deserve a macro rte_ntole16()? > > > It may be in lib/librte_eal/common/include/generic/rte_byteorder.h. > > > > I looked I didn't see anything. This value, according to the linux > > driver, wants to be little endian regardless of the host endian. > > Yes, that's why I suggest to create some macros to do this kind of conversion. > Example: rte_ntole16 means "network to little endian 16-bit". > Do you think it would be clearer to use? This is the only example of this kind of conversion in the source code so it would be a macro for one user. If you create rte_ntole16() you might feel obligated to create the various permutations for which there are no consumers.