On 10/16/2019 3:47 PM, David Marchand wrote: > On Wed, Oct 16, 2019 at 12:55 PM David Marchand > <david.march...@redhat.com> wrote: >> >> On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit <ferruh.yi...@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.yi...@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 <iryz...@nfware.com> >>>>> >>>>> Acked-by: Ferruh Yigit <ferruh.yi...@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. >