From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 37E2AA00E6 for ; Fri, 22 Mar 2019 14:05:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4B7401B5BF; Fri, 22 Mar 2019 14:05:40 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 3F37C1B57B for ; Fri, 22 Mar 2019 14:05:38 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2019 06:05:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,256,1549958400"; d="scan'208";a="142926257" Received: from istokes-mobl1.ger.corp.intel.com (HELO [10.252.13.209]) ([10.252.13.209]) by FMSMGA003.fm.intel.com with ESMTP; 22 Mar 2019 06:05:35 -0700 From: Ian Stokes To: Ferruh Yigit , dev@dpdk.org Cc: stephen@networkplumber.org, Thomas Monjalon , Andrew Rybchenko References: <1551303948-19746-1-git-send-email-ian.stokes@intel.com> <5e86db4c-215d-ffea-29ee-df026c894627@intel.com> Message-ID: <1cce752b-09e4-abf1-3f1e-3afc6a4418fe@intel.com> Date: Fri, 22 Mar 2019 13:05:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v1 0/6] ethdev: add min/max MTU to device info 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190322130535.vtcrfSWuPKQZ4FCJ07t87_hBW-Z4zqKkj-F1NMIxPvw@z> On 3/21/2019 1:03 PM, Ian Stokes wrote: > On 3/19/2019 4:30 PM, Ferruh Yigit wrote: >> On 2/27/2019 9:45 PM, Ian Stokes wrote: >>> Building upon the discussion around [1], this series introduces MTU min >>> and MTU max variables. It also provides updates to PMD implementations >>> for ixgbe, i40e and IGB devices so that these variables are populated >>> for use when retrieving device info. >>> >>> This series was tested with OVS DPDK and functions as expected for the >>> drivers listed below. But a wider selection of PMD drivers would have to >>> adopt this to ensure jumbo frames functionality remains for drivers not >>> modified in the series. >>> >>> There is also ongoing discussion in [2] regarding overhead to be >>> considered with MTU and how this may change from device to device, this >>> series uses existing overhead assumptions. >>> >>> This series was previously posted as an RFC in [3], this revision >>> removes RFC status and implements changes received in feedback. >>> >>> [1] http://mails.dpdk.org/archives/dev/2018-September/110959.html >>> [2] http://mails.dpdk.org/archives/dev/2019-February/124457.html >>> [3] http://mails.dpdk.org/archives/dev/2019-February/124938.html >>> >>> Ian Stokes (5): >>>    net/i40e: set min and max MTU for i40e devices >>>    net/i40e: set min and max MTU for i40e VF devices >>>    net/ixgbe: set min and max MTU for ixgbe devices >>>    net/ixgbe: set min and max MTU for ixgbe VF devices >>>    net/e1000: set min and max MTU for igb devices >>> >>> Stephen Hemminger (1): >>>    ethdev: add min/max MTU to device info >> >> Hi Ian, Stephen, >> >> API and driver updates are included in the patchset, but I believe it >> would be >> good to have some application code that uses it as well, I assume testpmd >> already has some code to set MTU, can you please update it too >> accordingly? >> > > Thanks Ferruh, sure I had looked at this but held off in the v1 as I > wasn't sure what best practice was, i.e.  introduce the change to sample > app now or wait unitl all PMDs were on board. If it's preferred to > introduce usage in a sample app then I can do this in the v2. > >> Also, what do you think starting a unit test (which has a long term >> target to >> verify all ethdev APIs) that tests 'rte_eth_dev_set_mtu()' API with >> various values? >> > > Sounds useful, I can take a look for the v2, first steps  might be basic > but can look into it. > > Ian >> In long term all vendors can run this unit test against their HW and >> verify >> ehtdev API implementation of their... >> > Hi Ferruh, I've posted a v2 of the patchset based on the feedback. http://mails.dpdk.org/archives/dev/2019-March/127344.html Unfortunately I did not have time to look at implementing the unit test aspect. I don't think I'll have the bandwidth before the rc1 window next week to implement this aspect but would be happy to look at it possibly in the next 19.08 release if this is acceptable, is the unit test a blocker for the rest of this work? Thanks Ian