From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 55F232BC5 for ; Tue, 6 Dec 2016 17:28:16 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id f82so132386074wmf.1 for ; Tue, 06 Dec 2016 08:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=GKSKE8fYok179Z6DIje51qgn427M8hDvYVbv+s7YEmE=; b=MsICck3+ETEtMWCIDhMUrXI/gj0BakLbbp65orBufdOkGXWSWpKT4NuZ7HMEkGl73p 7kmc/LGvRtI+nyf8HpWeJ57m5b44+9LrGOCsNKQ95sUMBgXnqIdT3UuTJDkpc3rlU3jQ 5XTPXQZZ3Q4NiF6AtzZSamFb7BLChWCQV7sWbu343BWspcEjavjz9px9VKyg7/ArhUry B6uj52/OXgrzTv09h5zxAQ0y8aYUyGDjtODdKANSFz1n6KxKbZZORVJCe+7bkT8ffit4 quBksZ10gP/K44JjUcefF70FVEz4PTXLQMg7ZHWMZ3JIqb9aVfiS72D4fY9gYhL6xNHi Y+WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=GKSKE8fYok179Z6DIje51qgn427M8hDvYVbv+s7YEmE=; b=b9ftloQXabHAZQbOC3vXDcf+iaBO/kNAU+/iFvSazpUqtCQ9qcGsxs4j4f67LDqpkz aYGGYuyH0xVBf7B5PT1Givxzv6nD3nGMHXuvYh6B59Izj9hcw1kHQY0pm8SbCKk3RKjN tYVh78or/t8A5gv4fumjq1ppCoNREEjWKre/YUTFwx8dMjdqB4CjCgoQ3L+pnCqXm21u lComJgJFKI490/mzgHFjf24mWY4oLKPxK/OXxT6n7TGVyOvP0Jn96AV+bbyCY8vWVDeB DevGCa07XrSqzQmN7SYSX62Hj4w9j21c9mvFqwbHJWedVi3noIeKwoNjyFgL8dslo4Lz t5Ug== X-Gm-Message-State: AKaTC02c4/hp08sGL8D1sxBxlHhLKhsqUakDaPoDQ7rbmqrS5bL7hutPEU/uyFIkZMvIgQJf X-Received: by 10.28.0.210 with SMTP id 201mr2618120wma.49.1481041696078; Tue, 06 Dec 2016 08:28:16 -0800 (PST) Received: from autoinstall.dev.6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id f76sm4805599wmd.15.2016.12.06.08.28.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 08:28:15 -0800 (PST) Date: Tue, 6 Dec 2016 17:28:07 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: "Wiles, Keith" , "Ananyev, Konstantin" , "Richardson, Bruce" , dev@dpdk.org, Olivier Matz , "Lu, Wenzhuo" , Adrien Mazarguil Message-ID: <20161206162807.GS21794@autoinstall.dev.6wind.com> References: <2601191342CEEE43887BDE71AB9772583F0E3F68@irsmsx105.ger.corp.intel.com> <20161205120603.GL21794@autoinstall.dev.6wind.com> <2601191342CEEE43887BDE71AB9772583F0E4632@irsmsx105.ger.corp.intel.com> <20161206115502.GA12224@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0E46DC@irsmsx105.ger.corp.intel.com> <20161206133427.GB15416@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0E47E1@irsmsx105.ger.corp.intel.com> <7E1BBBA1-F384-4235-8A82-4B0D6DC0889C@intel.com> <98CBD80474FA8B44BF855DF32C47DC359EAA47@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EAA47@smartserver.smartshare.dk> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Tue, 06 Dec 2016 16:28:16 -0000 Hi all, On Tue, Dec 06, 2016 at 04:34:07PM +0100, Morten Brørup wrote: > Hi all, > > Being a big fan of strong typing, I really like the concept of > explicit endian types. Especially if type mismatches can be caught at > compile time. +1, > However, I think it is too late! That train left the station when the > rest of the world - including libraries and headers that might be > linked with a DPDK application - decided to use implicit big endian > types for network protocols, and has been doing so for decades. And, > with all respect, I don't think the DPDK community has the momentum > required to change this tradition outside the community. I don't think, those types can be use from now on to help new API to expose explicitly the type they are handling. For older ones, it can come in a second step, even if there are not so numerous. Only few of them touches the network types. > Furthermore: If not enforced throughout DPDK (and beyond), it might > confuse more than it helps. The current situation is more confusing, nobody at any layer can rely on a precise information, at each function entry we need to verify if the callee has already handled the job. The only solution is to browse the code to have this information. Think about any function manipulating network headers (like flow director or rte_flow) from the API down to the PMD, it may take a lot of time to know at the end if the data is CPU or network ordered, with those types it takes less than a second. Regards, -- Nélio Laranjeiro 6WIND