[dpdk-dev] [PATCH] kni: add ability to set min/max MTU
Ferruh Yigit
ferruh.yigit at intel.com
Wed Oct 16 16:59:01 CEST 2019
On 10/16/2019 3:47 PM, David Marchand wrote:
> On Wed, Oct 16, 2019 at 12:55 PM David Marchand
> <david.marchand at redhat.com> wrote:
>>
>> On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>>>
>>> On 10/16/2019 7:40 AM, David Marchand wrote:
>>>> On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>>>>>
>>>>> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
>>>>>> Starting with kernel version 4.10, there are new min/max MTU values in
>>>>>> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
>>>>>> default. We should be able to change these values to allow MTU more than
>>>>>> 1500 to be set on KNI.
>>>>>>
>>>>>> Signed-off-by: Igor Ryzhov <iryzhov at nfware.com>
>>>>>
>>>>> Acked-by: Ferruh Yigit <ferruh.yigit at intel.com>
>>>>
>>>> I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
>>>> Does it sound ok to you?
>>>
>>> I am not quite sure it is a fix, this patch enables application to pass min/max
>>> MTU values for kni netdev but existing code is not doing anything wrong.
>>
>> To me, starting 4.10, we can't set the mtu to something greater than
>> 1500 on a kni netdev, since netdev uses the ETH_DATA_LEN default value
>> and will refuse a bigger mtu before even calling the change mtu ndo.
>> Did I understand something wrong?
>
> - As discussed on irc and after looking deeper into the code.
> The support for jumbo frames was already present and should be working
> with the current code.
> So I agree this does not qualify as a fix, sorry for the noise.
>
> - On the other hand, we could refactor this patch to make use of/merge
> with the existing HAVE_MAX_MTU_PARAM pre-existing macro without
> introducing a new one.
+1 to this, I missed the existing HAVE_MAX_MTU_PARAM macro
>
> - The commit title/log is still a bit cryptic to me, in which case
> would an application pass a min_mtu/max_mtu?
>
>
> Thanks.
>
More information about the dev
mailing list