From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id B161B377A for ; Wed, 9 Nov 2016 12:27:59 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 09 Nov 2016 03:27:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,614,1473145200"; d="scan'208";a="1713272" Received: from rmitura-mobl1.ger.corp.intel.com (HELO [10.252.24.154]) ([10.252.24.154]) by orsmga002.jf.intel.com with ESMTP; 09 Nov 2016 03:27:38 -0800 To: "Ananyev, Konstantin" , "dev@dpdk.org" , "Zhang, Helin" References: <20161109082341.19825-1-bjorn.topel@intel.com> <2601191342CEEE43887BDE71AB9772583F0D2F6C@irsmsx105.ger.corp.intel.com> <5ad83b54-f13b-787e-c056-958f5cb8bd61@intel.com> <2601191342CEEE43887BDE71AB9772583F0D2FD9@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: Date: Wed, 9 Nov 2016 12:27:37 +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: <2601191342CEEE43887BDE71AB9772583F0D2FD9@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 11:28:00 -0000 >> 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. >> > > Fine by me, but then it means that the fix haw to include changes > for all apps plus ixgbe and igb PMDs, correct? :) Ugh. Correct, I guess. :-) As for ixgbe and igb - they need a patch changing from silent ignore to explicit error. Regarding the apps, I guess all the apps that rely on that disabling CRC stripping always work, need some work. Or should all the example applications have CRC stripping *enabled* by default? I'd assume that all DPDK supported NICs has support for CRC stripping and I guess this is the rational for having it on by default for Intel VFs. In general, for the example applications, if an application relies on a property for a port, that the hardware doesn't support -- what would be the desired behavior? Or is it implied that the example applications only use a common, minimal set of features that are know to be supported by all DPDK supported hardware? Isn't it perfectly valid that some example applications wont run for all hardware? Finally, why doesn't l3fwd have the CRC stripped? Björn