From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 5309EA0096
for <public@inbox.dpdk.org>; Thu, 14 Mar 2019 10:28:12 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 3762F2C17;
Thu, 14 Mar 2019 10:28:12 +0100 (CET)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id CFEA1239
for <dev@dpdk.org>; Thu, 14 Mar 2019 10:28:10 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga001.jf.intel.com ([10.7.209.18])
by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
14 Mar 2019 02:28:10 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,478,1544515200"; d="scan'208";a="214064335"
Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.46])
([10.237.221.46])
by orsmga001.jf.intel.com with ESMTP; 14 Mar 2019 02:28:08 -0700
To: Liron Himi <lironh@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Alan Winkowski <walan@marvell.com>
References: <1550738855-11107-1-git-send-email-lironh@marvell.com>
<1550952885-2395-1-git-send-email-lironh@marvell.com>
<MN2PR18MB2398E9E498C268B34EA12BB9C67A0@MN2PR18MB2398.namprd18.prod.outlook.com>
<MN2PR18MB23986A05550B1DBCAC8710C1C64F0@MN2PR18MB2398.namprd18.prod.outlook.com>
<f7fde4ed-f8e4-bc8d-4016-d153ed0f8e97@intel.com>
<MN2PR18MB23980328B47E7272F4F51D17C64B0@MN2PR18MB2398.namprd18.prod.outlook.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
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: <a64dff8f-9955-385e-8a50-06a431346333@intel.com>
Date: Thu, 14 Mar 2019 09:28:07 +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: <MN2PR18MB23980328B47E7272F4F51D17C64B0@MN2PR18MB2398.namprd18.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Message-ID: <20190314092807.A7QBOWQ7CjnntCkPmTrH4Me3QCO0reH-35GaAE0Yx64@z>
On 3/14/2019 6:37 AM, Liron Himi wrote:
>
>
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, March 13, 2019 18:58
> To: Liron Himi <lironh@marvell.com>
> Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com>
> Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool
>
> 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 <lironh@marvell.com>; Liron Himi
>> <lironh@marvell.com>
>> 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 <lironh@marvell.com>
>> Sent: Saturday, February 23, 2019 22:15
>> To: ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; Liron Himi <lironh@marvell.com>
>> Subject: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool
>>
>> From: Liron Himi <lironh@marvell.com>
>>
>> - 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?
> [L.H.] correct
>
> By providing larger mbuf buffer, it should be possible to send larger (jumbo) packets?
> [L.H.] correct
>
> 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?
> [L.H.] I suggest to first go with this patch, and then prepare multi-segment patch if possible
Yes, I was hoping both can go in a same patchset, can it be possible?
> Multi segment support already exists in userspace to kernel path, but otherway around is missing.
>
>>
>> Signed-off-by: Liron Himi <lironh@marvell.com>
>> ---
>> 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.
> [L.H.] okay
>
>> 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.
> [L.H.] okay
>
> Another question, for the case mbuf size < ETHER_MTU, should we keep MTU ETHER_MTU, what do you think?
> [L.H.] in any case we need to set the MTU according to the mbuf-size until multi-segment support will be available, right?
Right.
>
>>
>> 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?
> [L.H.] 'max_mtu' is set by default to '1500', so in order to be able to modify the interface MTU to support jumbo (or even any size > 1500) the 'max_mtu' must be updated to the larger supported value.
I missed that it set by default to '1500', I was thinking it is zero by default.
Can you please point where its default value set in Linux?