[dpdk-dev] [PATCH v1 0/6] ethdev: add min/max MTU to device info

[Ian Stokes]

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