| Message ID | 1551303948-19746-1-git-send-email-ian.stokes@intel.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5FCF0322C; Wed, 27 Feb 2019 22:45:54 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 343612C52 for <dev@dpdk.org>; Wed, 27 Feb 2019 22:45:52 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2019 13:45:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,420,1544515200"; d="scan'208";a="127759216" Received: from sivswdev08.ir.intel.com (HELO localhost.localdomain) ([10.237.217.47]) by fmsmga008.fm.intel.com with ESMTP; 27 Feb 2019 13:45:49 -0800 From: Ian Stokes <ian.stokes@intel.com> To: dev@dpdk.org Cc: stephen@networkplumber.org, Ian Stokes <ian.stokes@intel.com> Date: Wed, 27 Feb 2019 21:45:42 +0000 Message-Id: <1551303948-19746-1-git-send-email-ian.stokes@intel.com> X-Mailer: git-send-email 1.7.0.7 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series |
ethdev: add min/max MTU to device info
|
|
Message
Ian Stokes
Feb. 27, 2019, 9:45 p.m. UTC
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 doc/guides/rel_notes/deprecation.rst | 12 ------------ doc/guides/rel_notes/release_19_05.rst | 8 +++++++- drivers/net/e1000/e1000_ethdev.h | 6 ++++++ drivers/net/e1000/igb_ethdev.c | 7 +++++-- drivers/net/i40e/i40e_ethdev.c | 2 ++ drivers/net/i40e/i40e_ethdev_vf.c | 2 ++ drivers/net/ixgbe/ixgbe_ethdev.c | 7 +++++-- drivers/net/ixgbe/ixgbe_ethdev.h | 3 +++ lib/librte_ethdev/Makefile | 2 +- lib/librte_ethdev/meson.build | 2 +- lib/librte_ethdev/rte_ethdev.c | 7 +++++++ lib/librte_ethdev/rte_ethdev.h | 2 ++ 12 files changed, 41 insertions(+), 19 deletions(-)
Comments
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? 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? In long term all vendors can run this unit test against their HW and verify ehtdev API implementation of their...
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... >
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
On 3/22/2019 1:05 PM, Ian Stokes wrote: > 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 for checking it, I believe it is not a blocker but I thought it may be a good start for verifying ethdev APIs, we can pursue this goal later.