From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 81F812A5E for ; Thu, 8 Dec 2016 16:07:38 +0100 (CET) Received: from cpe-2606-a000-111b-40ed-7aac-c0ff-fec2-933b.dyn6.twc.com ([2606:a000:111b:40ed:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1cF0ID-0007h4-2F; Thu, 08 Dec 2016 10:07:34 -0500 Date: Thu, 8 Dec 2016 10:07:21 -0500 From: Neil Horman To: =?iso-8859-1?Q?N=E9lio?= Laranjeiro Cc: dev@dpdk.org, "Ananyev, Konstantin" , Bruce Richardson , "Wiles, Keith" , Morten =?iso-8859-1?Q?Br=F8rup?= , wenzhuo.lu@intel.com, Olivier Matz Message-ID: <20161208150721.GB4657@hmsreliant.think-freely.org> References: <20161208093005.GD21794@autoinstall.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161208093005.GD21794@autoinstall.dev.6wind.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types 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: , X-List-Received-Date: Thu, 08 Dec 2016 15:07:38 -0000 On Thu, Dec 08, 2016 at 10:30:05AM +0100, Nélio Laranjeiro wrote: > Hi all, > > Following previous discussions, I would like to gather requirements for > v2, currently we have: > > 1. Introduction of new typedefs. > 2. Modification of network headers. > 3. Modification of rte_*_to_*() functions. > > Point 1. seems not to be an issue, everyone seems to agree on the fact > having those types could help to document some parts of the code. > No objection here > Point 2. does not cause any ABI change as it is only a documentation > commit, not sure if anyone disagrees about this. > I have an objection here, and I think it was stated by others previously. While its fine to offer endian encoded types so that developers can use them expediently, I don't like the idea of coding them into network headers specifically. I assert that because network headers represent multiple views of network data (both network byte order if the data is taken off the wire and cpu byte order if its translated. To implement such a network header change efficiently what you would need is something like the following: struct rte_ip_network_hdr { rte_le_u32 dst; rte_le_u32 src; ... }; struct rte_ip_cpu_hdr { rte_cpu_u32 dst; rte_cpu_u32 src; ... }; where rte_cpu_* is defined to a big endian or little endian type based on the cpu being targeted. Then of course you need to define translation macros to do all the appropriate conversions convieniently (or you need to do specific translations on the network byte order as needed, which may lead to lots of repeated conversions). Regardless, this seems to be unscalable. Endian types are the sort of thing that you should only use sparingly, not by default. > Point 3. documentation commit most people are uncomfortable with. > I propose to drop it from v2. > > Any objection to this plan? > > -- > Nélio Laranjeiro > 6WIND >