From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E4E9E9E7 for ; Wed, 9 Nov 2016 11:06:07 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP; 09 Nov 2016 02:06:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,465,1473145200"; d="scan'208";a="1057277441" Received: from rmitura-mobl1.ger.corp.intel.com (HELO [10.252.24.154]) ([10.252.24.154]) by orsmga001.jf.intel.com with ESMTP; 09 Nov 2016 02:06:02 -0800 To: "Ananyev, Konstantin" , "dev@dpdk.org" , helin.zhang@intel.com References: <20161109082341.19825-1-bjorn.topel@intel.com> <2601191342CEEE43887BDE71AB9772583F0D2F6C@irsmsx105.ger.corp.intel.com> Cc: "Xu, Qian Q" , "Yao, Lei A" , "Wu, Jingjing" , "thomas.monjalon@6wind.com" From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Message-ID: <5ad83b54-f13b-787e-c056-958f5cb8bd61@intel.com> Date: Wed, 9 Nov 2016 11:05:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0D2F6C@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping for i40evf 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, 09 Nov 2016 10:06:08 -0000 Adding Helin to the conversation. > That's a common problem across Intel VF devices. Bothe igb and ixgbe > overcomes that problem just by forcing ' rxmode.hw_strip_crc = 1;' at > PMD itself: [...] > Wonder, can't i40e VF do the same? Right, however, and this (silent failure) approach was rejected by the maintainers. Please, refer to this thread: http://dpdk.org/ml/archives/dev/2016-April/037523.html > BTW, all other examples would experience same problem too, right? Correct, so the broader question would be "what is the correct behavior for an example application, when a port configuration isn't supported by the hardware?". My stand, FWIW, is that igb and ixgbe should have the same semantics as i40e currently has, i.e. return an error to the user if the port is mis-configured, NOT changing the setting behind the users back. Björn