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. - The commit title/log is still a bit cryptic to me, in which case would an application pass a min_mtu/max_mtu? Thanks. -- David Marchand
