DPDK patches and discussions
 help / color / mirror / Atom feed
From: Liron Himi <lironh@marvell.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Alan Winkowski <walan@marvell.com>,
	"Liron Himi" <lironh@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool
Date: Thu, 14 Mar 2019 06:37:19 +0000	[thread overview]
Message-ID: <MN2PR18MB23980328B47E7272F4F51D17C64B0@MN2PR18MB2398.namprd18.prod.outlook.com> (raw)
Message-ID: <20190314063719.VGKL84zwHDxYX1AiS8HvxQ3D1dIAE5sXsApxU46J9xs@z> (raw)
In-Reply-To: <f7fde4ed-f8e4-bc8d-4016-d153ed0f8e97@intel.com>



-----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
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?

>  
>  	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.

  reply	other threads:[~2019-03-14  6:37 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 [this message]
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
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=MN2PR18MB23980328B47E7272F4F51D17C64B0@MN2PR18MB2398.namprd18.prod.outlook.com \
    --to=lironh@marvell.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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).