From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Liron Himi <lironh@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Alan Winkowski <walan@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool
Date: Wed, 20 Mar 2019 19:48:46 +0000 [thread overview]
Message-ID: <65c26a3b-6617-b74f-0eb4-69c0f056bedb@intel.com> (raw)
Message-ID: <20190320194846.awMlM2sr5rEs-yxmQzpodXPmXNad8aX5B0TCfW-G-FY@z> (raw)
In-Reply-To: <MN2PR18MB239852126D77B14172C06F9EC6460@MN2PR18MB2398.namprd18.prod.outlook.com>
On 3/17/2019 9:43 AM, Liron Himi wrote:
>
>
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, March 15, 2019 19:59
> 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/15/2019 5:02 PM, Liron Himi wrote:
>>
>>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Thursday, March 14, 2019 11:28
>> 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/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?
>> [L.H.] I'm on tight schedule right now, I prefer to continue with this patch as is, multi-segment support can be pushed later on.
>
> OK
>
>>
>>> 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
> [L.H.] I have made the following change, but I'm not sure to which document to mark the adding of this new feature.
> Is it release notes? If yes, which exact one?
I think feature is big enough to add to release notes, the one for current
release is: "doc/guides/rel_notes/release_19_05.rst".
>
> Should I mark it as Jumbo support? Or just specify that the mtu and mbuf are based on the given pool?
I was thinking "doc/guides/prog_guide/kernel_nic_interface.rst" instead of kni
PMD doc.
In that doc, in "KNI Creation and Deletion" section, there is a paragraph about
"struct rte_kni_conf", I think appending a single sentences to that paragraph to
say by default mtu is set as mbuf buffer length is good.
>
>
> diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
> index 204fbd5..a66c595 100644
> --- a/doc/guides/nics/kni.rst
> +++ b/doc/guides/nics/kni.rst
> @@ -55,7 +55,8 @@ configuration:
>
> Interface name: kni#
> force bind kernel thread to a core : NO
> - mbuf size: MAX_PACKET_SZ
> + mbuf size: (rte_pktmbuf_data_room_size(pktmbuf_pool) - RTE_PKTMBUF_HEADROOM)
> + mtu: (conf.mbuf_size - ETHER_HDR_LEN)
>>>
>>>> 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?
>> [L.H.] I also thought that a zero value will make more sense to provide backwards compatibility, but this is not the case.
>> Here is the code snipped from net/ethernet/eth.c :
>> void ether_setup(struct net_device *dev) {
>> dev->header_ops = ð_header_ops;
>> dev->type = ARPHRD_ETHER;
>> dev->hard_header_len = ETH_HLEN;
>> dev->min_header_len = ETH_HLEN;
>> dev->mtu = ETH_DATA_LEN;
>> dev->min_mtu = ETH_MIN_MTU;
>> dev->max_mtu = ETH_DATA_LEN;
>>
>
> You are right, thanks for the pointer, please go with this update.
>
next prev parent reply other threads:[~2019-03-20 19:48 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 8:47 [dpdk-dev] [PATCH] " lironh
2019-02-23 20:14 ` [dpdk-dev] [PATCH v2] " lironh
2019-02-25 11:29 ` Liron Himi
2019-03-10 14:27 ` Liron Himi
2019-03-13 16:57 ` Ferruh Yigit
2019-03-14 6:37 ` Liron Himi
2019-03-14 6:37 ` Liron Himi
2019-03-14 9:28 ` Ferruh Yigit
2019-03-14 9:28 ` Ferruh Yigit
2019-03-15 17:02 ` Liron Himi
2019-03-15 17:02 ` Liron Himi
2019-03-15 17:59 ` Ferruh Yigit
2019-03-15 17:59 ` Ferruh Yigit
2019-03-17 9:43 ` Liron Himi
2019-03-17 9:43 ` Liron Himi
2019-03-20 19:48 ` Ferruh Yigit [this message]
2019-03-20 19:48 ` Ferruh Yigit
2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh
2019-03-22 18:12 ` lironh
2019-03-23 21:48 ` Rami Rosen
2019-03-23 21:48 ` Rami Rosen
2019-03-24 10:05 ` [dpdk-dev] [EXT] " Liron Himi
2019-03-24 10:05 ` Liron Himi
2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh
2019-03-24 12:15 ` lironh
2019-03-25 15:44 ` Ferruh Yigit
2019-03-25 15:44 ` Ferruh Yigit
2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh
2019-03-25 20:48 ` lironh
2019-03-25 21:11 ` Ferruh Yigit
2019-03-25 21:11 ` Ferruh Yigit
2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh
2019-03-26 17:59 ` Ferruh Yigit
2019-03-26 17:59 ` Ferruh Yigit
2019-03-30 0:00 ` Thomas Monjalon
2019-03-30 0:00 ` Thomas Monjalon
2019-03-26 18:40 ` lironh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65c26a3b-6617-b74f-0eb4-69c0f056bedb@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=lironh@marvell.com \
--cc=walan@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).