From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CA195A3168 for ; Wed, 16 Oct 2019 16:47:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B9781E933; Wed, 16 Oct 2019 16:47:25 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id CA3B31E8E2 for ; Wed, 16 Oct 2019 16:47:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571237243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xA96RbCy6+cwEvlamxCZ5/Y03u6yWuF7mXEBXpXPDP0=; b=gU9nEjQGhcWYSVesbo5ZPTwQOqsTxxQt7rKYevhMSQEaTLXekIp8w1AmMak81tA/OI/3b7 gA02fi0qXfkVQcr6jKAwvvKUyJiJVHBJMOYQeJIeLDfB+wlZEcK8tVBxz1v3sp4ddXsuS9 /qzYCUK7wdH+WmiSqZ4sa1uMI5SoP94= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-298-uTdev2pQMk2Mzd-TkNgrUQ-1; Wed, 16 Oct 2019 10:47:22 -0400 Received: by mail-vk1-f199.google.com with SMTP id d64so9770116vke.6 for ; Wed, 16 Oct 2019 07:47:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKyQnaUEIBqcK0GCEk1EBJ0uhhM7wS9eRzQfjAlLIU8=; b=jj5Z424Lq+ksPcJ0bQvURZ4oELo5jJtN13UPrQTsVzqocCH6QnIweXdn8/bVb4SZxu PdvOQv2aZbs5J9rfUt5znB9BHKbsMAkEkkA5lhX5ZgKjw/K05uo/AjGgdkixJNF+Bm1a g/Vjoawz/1hSfHKMeCmuL8hTtygiWmDosc3Bo5Yj3kR1BiYQy2HYMztqQ8G4pF6+d+pY l4s4ozLV3aC9Z1kjDAWOSkgbLPRhSzZbe/ZsaeqzYFq3HNKpcuSmOTEWtxp+J0OlWJHb 6h2iCIsun6jPL5aBmQT4uBsaNj6yI6vYUajJ6ycjSY1dPnT0hr44+6Hi+a5dEa83+mxK O/Ag== X-Gm-Message-State: APjAAAXlNEB7PBdRvV2P9fsJiMK3FMCLJ9iIgwCGfia7PQQEVlUIEnu9 isdip1q3Jj9WEudLw4VYgFrohE1Mz4ryozXb0TySsgkUYsPRKUQjChhUNUjd4j8aSfJuZOx8Knj 2O5zu/BvFP7wMSrqddxU= X-Received: by 2002:a05:6102:387:: with SMTP id m7mr79773vsq.105.1571237241773; Wed, 16 Oct 2019 07:47:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqzftHdt0XygeMFezgzqJWaW+MJNv/yU61AdZKqnM3nTIG2CN1j1wKCZ+PYKMd64v3edjMVp7/UEqyHi3Zz97ds= X-Received: by 2002:a05:6102:387:: with SMTP id m7mr79747vsq.105.1571237241364; Wed, 16 Oct 2019 07:47:21 -0700 (PDT) MIME-Version: 1.0 References: <20190919112257.85337-1-iryzhov@nfware.com> <6c6e0326-46fa-8454-2f40-8173fee96858@intel.com> In-Reply-To: From: David Marchand Date: Wed, 16 Oct 2019 16:47:10 +0200 Message-ID: To: Ferruh Yigit , Igor Ryzhov Cc: dev X-MC-Unique: uTdev2pQMk2Mzd-TkNgrUQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] kni: add ability to set min/max MTU X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Oct 16, 2019 at 12:55 PM David Marchand wrote: > > On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit wr= ote: > > > > On 10/16/2019 7:40 AM, David Marchand wrote: > > > On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit = 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 > > >> > > >> Acked-by: Ferruh Yigit > > > > > > I intend to change the title as "kni: fix mtu setting with kernels >= =3D 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. --=20 David Marchand