From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 468162C17 for ; Wed, 13 Mar 2019 17:57:38 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2019 09:57:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,474,1544515200"; d="scan'208";a="140477788" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.46]) ([10.237.221.46]) by FMSMGA003.fm.intel.com with ESMTP; 13 Mar 2019 09:57:36 -0700 To: Liron Himi Cc: "dev@dpdk.org" , Alan Winkowski References: <1550738855-11107-1-git-send-email-lironh@marvell.com> <1550952885-2395-1-git-send-email-lironh@marvell.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJVBBMBAgA/AhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgBYhBNI2U4dCLsKE45mBx/kz60PfE2EfBQJbughWBQkHwjOGAAoJEPkz60Pf E2Eft84QAIbKWqhgqRfoiw/BbXbA1+qm2o4UgkCRQ0yJgt9QsnbpOmPKydHH0ixCliNz1J8e mRXCkMini1bTpnzp7spOjQGLeAFkNFz6BMq8YF2mVWbGEDE9WgnAxZdi0eLY7ZQnHbE6AxKL SXmpe9INb6z3ztseFt7mqje/W/6DWYIMnH3Yz9KzxujFWDcq8UCAvPkxVQXLTMpauhFgYeEx Nub5HbvhxTfUkapLwRQsSd/HbywzqZ3s/bbYMjj5JO3tgMiM9g9HOjv1G2f1dQjHi5YQiTZl 1eIIqQ3pTic6ROaiZqNmQFXPsoOOFfXF8nN2zg8kl/sSdoXWHhama5hbwwtl1vdaygQYlmdK H2ueiFh/UvT3WG3waNv2eZiEbHV8Rk52Xyn2w1G90lV0fYC6Ket1Xjoch7kjwbx793Kz/RfQ rmBY8/S4DTGn3oq3dMdQY+b6+7VMUeLMMh2CXYO9ErkOq+qNTD1IY+cBAkXnaDbQfz0zbste ZGWH74FAZ9nCpDOqbRTrBL42aMGhfOWEyeA1x7+hl6JZfabBWAuf4nnCXuorKHzBXTrf7u7p fXsKQClWRW77PF1VmzrtKNVSytQAmlCWApQIw20AarFipXmVdIjHmJPU611WoyxZPb4JTOxx 5cv9B+nr/RIB+v5dcStyHCCwO1be7nBDdCgd4F6kTQPLuQINBFfWTL4BEACnNA29e8TarUsB L5n6eLZHXcFvVwNLVlirWOClHXf44o2KnN3ww+eBEmKVfEFo9MSuGDNHS8Zw1NiGMYxLIUgd U6gGrVVs/VrQWL82pbMk6jCj98N+BXIri+6K1z+AImz7ax7iF1kDgRAnFWU0znWWBgM2mM8Y gDjcxfXk4sCKnvf6Gjo08Ey5zmqx7dekAKU2EEp8Q1EJY3jbymLdZWRP4AFFMTS1rGMk0/tt v71NBg1GobCcbNfn9chK/jhqxYhAJqq86RdJQkt3/9x1U1Oq0vXCt4JVVHmkxePtUiuWTTt+ aYlUAsKYZsWvncExvw77x2ArYDmaK0yfjh37wp0lY7DOJHFxoyT8tyWZlLci/VMRG2Ja33xj 0CN4C1yBg+QDeV3QFxQo42iA/ykdXPUR3ezmsND3XKvVLTC4DNb3V/EZQ7jBj64+bEK0VW4G B31VP00ApNQvSoczsIOAKdk97RNbpmPw6q10ILIB+9T1xbnFYzshzGF17oC0/GENIHATx8vZ masOZoDiOZQpeneLgnFE9JfzhLTxv6wNZcc/HLXRQVTkDsQr8ERtkAoHCf1E5+b5Yr7pfnE4 YuhET746o25S53ELUYPIs49qoJsEJL34/oexMfPGyPIlrbufiNyty5jc/1MRwUlhJlJ5IOHy ZUa+6CLR7GdImusFkPJUJwARAQABiQI8BBgBAgAmAhsMFiEE0jZTh0IuwoTjmYHH+TPrQ98T YR8FAlu6CHAFCQXE7zIACgkQ+TPrQ98TYR9nXxAAqNBgkYNyGuWUuy0GwDQCbu3iiMyH1+D7 llafPcK4NYy1Z4AYuVwC9nmLaoj+ozdqS3ncRo57ncRsKEJC46nDJJZYZ5LSJVn63Y3NBF86 lxQAgjj2oyZEwaLKtKbAFsXL43jv1pUGgSvWwYtDwHITXXFQto9rZEuUDRFSx4sg9OR+Q6/6 LY+nQQ3OdHlBkflzYMPcWgDcvcTAO6yasLEUf7UcYoSWTyMYjLB4QuNlXzTswzGVMssJF/vo V8lD1eqqaSUWG3STF6GVLQOr1NLvN5+kUBiEStHFxBpgSCvYY9sNV8FS6N24CAWMBl+10W+D 2h1yiiP5dOdPcBDYKsgqDD91/sP0WdyMJkwdQJtD49f9f+lYloxHnSAxMleOpyscg1pldw+i mPaUY1bmIknLhhkqfMmjywQOXpac5LRMibAAYkcB8v7y3kwELnt8mhqqZy6LUsqcWygNbH/W K3GGt5tRpeIXeJ25x8gg5EBQ0Jnvp/IbBYQfPLtXH0Myq2QuAhk/1q2yEIbVjS+7iowEZNyE 56K63WBJxsJPB2mvmLgn98GqB4G6GufP1ndS0XDti/2K0o8rep9xoY/JDGi0n0L0tk9BHyoP Y7kaEpu7UyY3nVdRLe5H1/MnFG8hdJ97WqnPS0buYZlrbTV0nRFL/NI2VABl18vEEXvNQiO+ vM8= Message-ID: Date: Wed, 13 Mar 2019 16:57:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 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: , X-List-Received-Date: Wed, 13 Mar 2019 16:57:38 -0000 On 3/10/2019 2:27 PM, Liron Himi wrote: > Adding Alan. > > -----Original Message----- > From: Liron Himi > Sent: Monday, February 25, 2019 13:30 > To: ferruh.yigit@intel.com > Cc: dev@dpdk.org; Liron Himi ; Liron Himi > Subject: RE: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool > > Hi, > > Kind reminder Sorry for late response. > > Regards, > Liron > > -----Original Message----- > From: lironh@marvell.com > Sent: Saturday, February 23, 2019 22:15 > To: ferruh.yigit@intel.com > Cc: dev@dpdk.org; Liron Himi > Subject: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool > > From: Liron Himi > > - mbuf_size and mtu are now being calculated according to the given mb-pool. +1 to have dynamic size instead of fixed "MAX_PACKET_SZ" > > - max_mtu is now being set according to the given mtu > > the above two changes provide the ability to work with jumbo frames >>From kernel -> userspace, if the data length is bigger than mbuf->buffer_len (- headroom) the packet is dropped. I guess you are trying to solve that issue? By providing larger mbuf buffer, it should be possible to send larger (jumbo) packets? Another option can be adding multi segment send support, that also lets sending large packets from kernel to userspace, and it can co-exits with your patch. What do you think, can you work on that support? Multi segment support already exists in userspace to kernel path, but otherway around is missing. > > Signed-off-by: Liron Himi > --- > drivers/net/kni/rte_eth_kni.c | 10 +++++++--- > kernel/linux/kni/compat.h | 4 ++++ > kernel/linux/kni/kni_misc.c | 3 +++ It can be good to update release notes / kni documentation to document new feature. > 3 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c index a1e9970..5e02224 100644 > --- a/drivers/net/kni/rte_eth_kni.c > +++ b/drivers/net/kni/rte_eth_kni.c > @@ -16,9 +16,11 @@ > /* Only single queue supported */ > #define KNI_MAX_QUEUE_PER_PORT 1 > > -#define MAX_PACKET_SZ 2048 > #define MAX_KNI_PORTS 8 > > +#define KNI_ETHER_MTU(mbuf_size) \ > + ((mbuf_size) - ETHER_HDR_LEN) /**< Ethernet MTU. */ > + > #define ETH_KNI_NO_REQUEST_THREAD_ARG "no_request_thread" > static const char * const valid_arguments[] = { > ETH_KNI_NO_REQUEST_THREAD_ARG, > @@ -123,11 +125,13 @@ eth_kni_start(struct rte_eth_dev *dev) > struct rte_kni_conf conf; > const char *name = dev->device->name + 4; /* remove net_ */ > > + mb_pool = internals->rx_queues[0].mb_pool; > snprintf(conf.name, RTE_KNI_NAMESIZE, "%s", name); > conf.force_bind = 0; > conf.group_id = port_id; > - conf.mbuf_size = MAX_PACKET_SZ; > - mb_pool = internals->rx_queues[0].mb_pool; > + conf.mbuf_size = > + rte_pktmbuf_data_room_size(mb_pool) - RTE_PKTMBUF_HEADROOM; > + conf.mtu = KNI_ETHER_MTU(conf.mbuf_size); Can you please do "conf.mbuf_size" changes also to kni sample application? kni sample application gets mtu from physical device, so I believe better to not change that but I think mbuf_size can be dynamic instead of hardcoded. Another question, for the case mbuf size < ETHER_MTU, should we keep MTU ETHER_MTU, what do you think? > > internals->kni = rte_kni_alloc(mb_pool, &conf, NULL); > if (internals->kni == NULL) { > diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h index 3c575c7..b9f9a6f 100644 > --- a/kernel/linux/kni/compat.h > +++ b/kernel/linux/kni/compat.h > @@ -117,3 +117,7 @@ > #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0) #define HAVE_SIGNAL_FUNCTIONS_OWN_HEADER #endif > + > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0) #define > +HAVE_MAX_MTU_PARAM #endif > diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c index 522ae23..04c78eb 100644 > --- a/kernel/linux/kni/kni_misc.c > +++ b/kernel/linux/kni/kni_misc.c > @@ -459,6 +459,9 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num, > > if (dev_info.mtu) > net_dev->mtu = dev_info.mtu; > +#ifdef HAVE_MAX_MTU_PARAM > + net_dev->max_mtu = net_dev->mtu; > +#endif Do we need to set 'max_mtu'? I guess this is not really required for large packet support, if so what do you think making this separate patch?