[dpdk-dev] [PATCH] net/kni: calc mbuf&mtu according to given mb_pool

[dpdk-dev] [PATCH] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 drivers/net/kni/rte_eth_kni.c | 10 +++++++---
 kernel/linux/kni/kni_misc.c   |  1 +
 2 files changed, 8 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);
 
 	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
 	if (internals->kni == NULL) {
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 522ae23..9dac16d 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -459,6 +459,7 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
 
 	if (dev_info.mtu)
 		net_dev->mtu = dev_info.mtu;
+	net_dev->max_mtu = net_dev->mtu;
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

[dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

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 +++
 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);
 
 	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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

Hi,

Kind reminder

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.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

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 +++
 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);
 
 	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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
--
2.7.4

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

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.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

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 +++
 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);
 
 	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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
--
2.7.4

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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?

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

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

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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?

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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?

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

> 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?
[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		= &eth_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;

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

> 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?
[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		= &eth_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;

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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
>>
>>>  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		= &eth_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.

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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
>>
>>>  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		= &eth_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.

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

Should I mark it as Jumbo support? Or just specify that the mtu and mbuf are based on the given pool?


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		= &eth_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.

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

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

Should I mark it as Jumbo support? Or just specify that the mtu and mbuf are based on the given pool?


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		= &eth_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.

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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		= &eth_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.
> 

Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

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		= &eth_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.
> 

[dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 examples/kni/main.c                            |  3 ++-
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 7 files changed, 28 insertions(+), 5 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..412769f 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the mtu is derived from the mbuf buffer length.
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..c8a1559 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -91,6 +91,15 @@ New Features
 
   * Added promiscuous mode support.
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  th given mb-pool. This provide the ability to pass jumbo frames
+  if the bm-pool contains suitable buffers' size.
+
 
 Removed Items
 -------------
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);
 
 	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
 	if (internals->kni == NULL) {
diff --git a/examples/kni/main.c b/examples/kni/main.c
index a58774a..50cb771 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
 			snprintf(conf.name, RTE_KNI_NAMESIZE,
 						"vEth%u", port_id);
 		conf.group_id = port_id;
-		conf.mbuf_size = MAX_PACKET_SZ;
+		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
+			RTE_PKTMBUF_HEADROOM;
 		/*
 		 * The first KNI device associated to a port
 		 * is the master, for multiple kernel thread
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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

[dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 examples/kni/main.c                            |  3 ++-
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 7 files changed, 28 insertions(+), 5 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..412769f 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the mtu is derived from the mbuf buffer length.
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..c8a1559 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -91,6 +91,15 @@ New Features
 
   * Added promiscuous mode support.
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  th given mb-pool. This provide the ability to pass jumbo frames
+  if the bm-pool contains suitable buffers' size.
+
 
 Removed Items
 -------------
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);
 
 	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
 	if (internals->kni == NULL) {
diff --git a/examples/kni/main.c b/examples/kni/main.c
index a58774a..50cb771 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
 			snprintf(conf.name, RTE_KNI_NAMESIZE,
 						"vEth%u", port_id);
 		conf.group_id = port_id;
-		conf.mbuf_size = MAX_PACKET_SZ;
+		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
+			RTE_PKTMBUF_HEADROOM;
 		/*
 		 * The first KNI device associated to a port
 		 * is the master, for multiple kernel thread
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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[Rami Rosen]

<lironh@marvell.com>:

> From: Liron Himi <lironh@marvell.com>
>
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
>
> - max_mtu is now being set according to the given mtu
>
> the above two changes provide the ability to work with jumbo frames
>
> Signed-off-by: Liron Himi <lironh@marvell.com>


Minors:
without it-> Without it
th given-> the given
if the bm-pool -> if the mb-pool

>
> +* **Updated KNI kernel module, KNI PMD driver.**
> +
> +  Updated the KNI kernel module to set the max_mtu according to the given
> +  initial mtu size. without it, the maximum mtu was 1500.
> +
> +  Updated the KNI PMD driver to set the mbuf_size and mtu based on
> +  th given mb-pool. This provide the ability to pass jumbo frames
> +  if the bm-pool contains suitable buffers' size.
> +
>

Reviewd-by: Rami Rosen <ramirose@gmail.com>

Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[Rami Rosen]

<lironh@marvell.com>:

> From: Liron Himi <lironh@marvell.com>
>
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
>
> - max_mtu is now being set according to the given mtu
>
> the above two changes provide the ability to work with jumbo frames
>
> Signed-off-by: Liron Himi <lironh@marvell.com>


Minors:
without it-> Without it
th given-> the given
if the bm-pool -> if the mb-pool

>
> +* **Updated KNI kernel module, KNI PMD driver.**
> +
> +  Updated the KNI kernel module to set the max_mtu according to the given
> +  initial mtu size. without it, the maximum mtu was 1500.
> +
> +  Updated the KNI PMD driver to set the mbuf_size and mtu based on
> +  th given mb-pool. This provide the ability to pass jumbo frames
> +  if the bm-pool contains suitable buffers' size.
> +
>

Reviewd-by: Rami Rosen <ramirose@gmail.com>

Re: [dpdk-dev] [EXT] Re: [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

Fixed. thanks

From: Rami Rosen <ramirose@gmail.com>
Sent: Saturday, March 23, 2019 23:49
To: Liron Himi <lironh@marvell.com>
Cc: ferruh.yigit@intel.com; dev@dpdk.org; Alan Winkowski <walan@marvell.com>
Subject: [EXT] Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

External Email
________________________________

<lironh@marvell.com<mailto:lironh@marvell.com>>:
From: Liron Himi <lironh@marvell.com<mailto:lironh@marvell.com>>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com<mailto:lironh@marvell.com>>

Minors:
without it-> Without it
th given-> the given
if the bm-pool -> if the mb-pool

+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  th given mb-pool. This provide the ability to pass jumbo frames
+  if the bm-pool contains suitable buffers' size.
+

Reviewd-by: Rami Rosen <ramirose@gmail.com<mailto:ramirose@gmail.com>>

Re: [dpdk-dev] [EXT] Re: [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

[Liron Himi]

Fixed. thanks

From: Rami Rosen <ramirose@gmail.com>
Sent: Saturday, March 23, 2019 23:49
To: Liron Himi <lironh@marvell.com>
Cc: ferruh.yigit@intel.com; dev@dpdk.org; Alan Winkowski <walan@marvell.com>
Subject: [EXT] Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool

External Email
________________________________

<lironh@marvell.com<mailto:lironh@marvell.com>>:
From: Liron Himi <lironh@marvell.com<mailto:lironh@marvell.com>>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com<mailto:lironh@marvell.com>>

Minors:
without it-> Without it
th given-> the given
if the bm-pool -> if the mb-pool

+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  th given mb-pool. This provide the ability to pass jumbo frames
+  if the bm-pool contains suitable buffers' size.
+

Reviewd-by: Rami Rosen <ramirose@gmail.com<mailto:ramirose@gmail.com>>

[dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 examples/kni/main.c                            |  3 ++-
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 7 files changed, 28 insertions(+), 5 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..412769f 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the mtu is derived from the mbuf buffer length.
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..74a838b 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -91,6 +91,15 @@ New Features
 
   * Added promiscuous mode support.
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 
 Removed Items
 -------------
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);
 
 	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
 	if (internals->kni == NULL) {
diff --git a/examples/kni/main.c b/examples/kni/main.c
index a58774a..50cb771 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
 			snprintf(conf.name, RTE_KNI_NAMESIZE,
 						"vEth%u", port_id);
 		conf.group_id = port_id;
-		conf.mbuf_size = MAX_PACKET_SZ;
+		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
+			RTE_PKTMBUF_HEADROOM;
 		/*
 		 * The first KNI device associated to a port
 		 * is the master, for multiple kernel thread
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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

[dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 examples/kni/main.c                            |  3 ++-
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 7 files changed, 28 insertions(+), 5 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..412769f 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the mtu is derived from the mbuf buffer length.
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..74a838b 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -91,6 +91,15 @@ New Features
 
   * Added promiscuous mode support.
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 
 Removed Items
 -------------
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);
 
 	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
 	if (internals->kni == NULL) {
diff --git a/examples/kni/main.c b/examples/kni/main.c
index a58774a..50cb771 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
 			snprintf(conf.name, RTE_KNI_NAMESIZE,
 						"vEth%u", port_id);
 		conf.group_id = port_id;
-		conf.mbuf_size = MAX_PACKET_SZ;
+		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
+			RTE_PKTMBUF_HEADROOM;
 		/*
 		 * The first KNI device associated to a port
 		 * is the master, for multiple kernel thread
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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/24/2019 12:15 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>
> ---
>  doc/guides/nics/kni.rst                        |  3 ++-
>  doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
>  doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
>  drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
>  examples/kni/main.c                            |  3 ++-
>  kernel/linux/kni/compat.h                      |  4 ++++
>  kernel/linux/kni/kni_misc.c                    |  3 +++
>  7 files changed, 28 insertions(+), 5 deletions(-)
> 
> 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)
>  
>  KNI control path is not supported with the PMD, since there is no physical
>  backend device by default.
> diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
> index 33ea980..412769f 100644
> --- a/doc/guides/prog_guide/kernel_nic_interface.rst
> +++ b/doc/guides/prog_guide/kernel_nic_interface.rst
> @@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
>  user to specify the interface name, set the MTU size, set an explicit or
>  random MAC address and control the affinity of the kernel Rx thread(s)
>  (both single and multi-threaded modes).
> +By default the mtu is derived from the mbuf buffer length.

This seems slightly different for kni sample and PMD, by default kni sample gets
mtu from matching device, and for kni pmd it is derived from mbuf buffer length,
can you please reflect this?

>  
>  The ``struct rte_kni_ops`` structure contains pointers to functions to
>  handle requests from the ``rte_kni`` kernel module.  These functions
> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
> index 61a2c73..74a838b 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -91,6 +91,15 @@ New Features
>  
>    * Added promiscuous mode support.
>  
> +* **Updated KNI kernel module, KNI PMD driver.**
> +
> +  Updated the KNI kernel module to set the max_mtu according to the given
> +  initial mtu size. Without it, the maximum mtu was 1500.
> +
> +  Updated the KNI PMD driver to set the mbuf_size and mtu based on
> +  the given mb-pool. This provide the ability to pass jumbo frames
> +  if the mb-pool contains suitable buffers' size.
> +

Minor issue, kni is considered as core library, so can you please move the
release note update above the PMD updates.

>  
>  Removed Items
>  -------------
> 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);
>  
>  	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
>  	if (internals->kni == NULL) {
> diff --git a/examples/kni/main.c b/examples/kni/main.c
> index a58774a..50cb771 100644
> --- a/examples/kni/main.c
> +++ b/examples/kni/main.c
> @@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
>  			snprintf(conf.name, RTE_KNI_NAMESIZE,
>  						"vEth%u", port_id);
>  		conf.group_id = port_id;
> -		conf.mbuf_size = MAX_PACKET_SZ;
> +		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
> +			RTE_PKTMBUF_HEADROOM;

I overlooked this part, 'MAX_PACKET_SZ' is used to create mempool, so always
MAX_PACKET_SZ == rte_pktmbuf_data_room_size(pktmbuf_pool) - RTE_PKTMBUF_HEADROOM

Technically above code makes no difference with existing logic, perhaps we can
drop it, sorry for redundant work.

>  		/*
>  		 * The first KNI device associated to a port
>  		 * is the master, for multiple kernel thread
> 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

Minor nit, trying to keep order based on kernel version check, can you please
move this above the 4.11 check?

> 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
>  
>  	ret = register_netdev(net_dev);
>  	if (ret) {
> 

Re: [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/24/2019 12:15 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>
> ---
>  doc/guides/nics/kni.rst                        |  3 ++-
>  doc/guides/prog_guide/kernel_nic_interface.rst |  1 +
>  doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
>  drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
>  examples/kni/main.c                            |  3 ++-
>  kernel/linux/kni/compat.h                      |  4 ++++
>  kernel/linux/kni/kni_misc.c                    |  3 +++
>  7 files changed, 28 insertions(+), 5 deletions(-)
> 
> 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)
>  
>  KNI control path is not supported with the PMD, since there is no physical
>  backend device by default.
> diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
> index 33ea980..412769f 100644
> --- a/doc/guides/prog_guide/kernel_nic_interface.rst
> +++ b/doc/guides/prog_guide/kernel_nic_interface.rst
> @@ -187,6 +187,7 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
>  user to specify the interface name, set the MTU size, set an explicit or
>  random MAC address and control the affinity of the kernel Rx thread(s)
>  (both single and multi-threaded modes).
> +By default the mtu is derived from the mbuf buffer length.

This seems slightly different for kni sample and PMD, by default kni sample gets
mtu from matching device, and for kni pmd it is derived from mbuf buffer length,
can you please reflect this?

>  
>  The ``struct rte_kni_ops`` structure contains pointers to functions to
>  handle requests from the ``rte_kni`` kernel module.  These functions
> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
> index 61a2c73..74a838b 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -91,6 +91,15 @@ New Features
>  
>    * Added promiscuous mode support.
>  
> +* **Updated KNI kernel module, KNI PMD driver.**
> +
> +  Updated the KNI kernel module to set the max_mtu according to the given
> +  initial mtu size. Without it, the maximum mtu was 1500.
> +
> +  Updated the KNI PMD driver to set the mbuf_size and mtu based on
> +  the given mb-pool. This provide the ability to pass jumbo frames
> +  if the mb-pool contains suitable buffers' size.
> +

Minor issue, kni is considered as core library, so can you please move the
release note update above the PMD updates.

>  
>  Removed Items
>  -------------
> 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);
>  
>  	internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
>  	if (internals->kni == NULL) {
> diff --git a/examples/kni/main.c b/examples/kni/main.c
> index a58774a..50cb771 100644
> --- a/examples/kni/main.c
> +++ b/examples/kni/main.c
> @@ -888,7 +888,8 @@ kni_alloc(uint16_t port_id)
>  			snprintf(conf.name, RTE_KNI_NAMESIZE,
>  						"vEth%u", port_id);
>  		conf.group_id = port_id;
> -		conf.mbuf_size = MAX_PACKET_SZ;
> +		conf.mbuf_size = rte_pktmbuf_data_room_size(pktmbuf_pool) -
> +			RTE_PKTMBUF_HEADROOM;

I overlooked this part, 'MAX_PACKET_SZ' is used to create mempool, so always
MAX_PACKET_SZ == rte_pktmbuf_data_room_size(pktmbuf_pool) - RTE_PKTMBUF_HEADROOM

Technically above code makes no difference with existing logic, perhaps we can
drop it, sorry for redundant work.

>  		/*
>  		 * The first KNI device associated to a port
>  		 * is the master, for multiple kernel thread
> 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

Minor nit, trying to keep order based on kernel version check, can you please
move this above the 4.11 check?

> 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
>  
>  	ret = register_netdev(net_dev);
>  	if (ret) {
> 

[dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  2 ++
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 6 files changed, 27 insertions(+), 4 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..bf7f1ea 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+by default kni sample gets mtu from matching device, and for kni pmd it
+is derived from mbuf buffer length,
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..dceca50 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,6 +54,15 @@ New Features
      Also, make sure to start the actual text at the margin.
      =========================================================
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 * **Updated Solarflare network PMD.**
 
   Updated the sfc_efx driver including the following changes:
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);
 
 	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..562d8bf 100644
--- a/kernel/linux/kni/compat.h
+++ b/kernel/linux/kni/compat.h
@@ -114,6 +114,10 @@
 #define ndo_change_mtu ndo_change_mtu_rh74
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)
+#define HAVE_MAX_MTU_PARAM
+#endif
+
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
 #define HAVE_SIGNAL_FUNCTIONS_OWN_HEADER
 #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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

[dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  2 ++
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 6 files changed, 27 insertions(+), 4 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..bf7f1ea 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+by default kni sample gets mtu from matching device, and for kni pmd it
+is derived from mbuf buffer length,
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..dceca50 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,6 +54,15 @@ New Features
      Also, make sure to start the actual text at the margin.
      =========================================================
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 * **Updated Solarflare network PMD.**
 
   Updated the sfc_efx driver including the following changes:
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);
 
 	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..562d8bf 100644
--- a/kernel/linux/kni/compat.h
+++ b/kernel/linux/kni/compat.h
@@ -114,6 +114,10 @@
 #define ndo_change_mtu ndo_change_mtu_rh74
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)
+#define HAVE_MAX_MTU_PARAM
+#endif
+
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
 #define HAVE_SIGNAL_FUNCTIONS_OWN_HEADER
 #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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/25/2019 8:48 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>
> ---

<...>

> @@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
>  user to specify the interface name, set the MTU size, set an explicit or
>  random MAC address and control the affinity of the kernel Rx thread(s)
>  (both single and multi-threaded modes).
> +by default kni sample gets mtu from matching device, and for kni pmd it
> +is derived from mbuf buffer length,

Hi Liron,

I can see you copy/pasted the comment to the doc, but the intention was not to
use it exactly. This is a public documentation, can you please correct the
wording, cases and punctuation, please make it something documentation quality.

Re: [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/25/2019 8:48 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>
> ---

<...>

> @@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
>  user to specify the interface name, set the MTU size, set an explicit or
>  random MAC address and control the affinity of the kernel Rx thread(s)
>  (both single and multi-threaded modes).
> +by default kni sample gets mtu from matching device, and for kni pmd it
> +is derived from mbuf buffer length,

Hi Liron,

I can see you copy/pasted the comment to the doc, but the intention was not to
use it exactly. This is a public documentation, can you please correct the
wording, cases and punctuation, please make it something documentation quality.

Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/26/2019 6:40 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>

Suggested title:
kni: calculate MTU from mbuf buffer size

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[Ferruh Yigit]

On 3/26/2019 6:40 PM, lironh@marvell.com wrote:
> From: Liron Himi <lironh@marvell.com>
> 
> - mbuf_size and mtu are now being calculated according
> to the given mb-pool.
> 
> - max_mtu is now being set according to the given mtu
> 
> the above two changes provide the ability to work with jumbo frames
> 
> Signed-off-by: Liron Himi <lironh@marvell.com>

Suggested title:
kni: calculate MTU from mbuf buffer size

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

[dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  2 ++
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 6 files changed, 27 insertions(+), 4 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..c274b25 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the KNI sample example gets the MTU from the matching device,
+and in case of KNI PMD it is derived from mbuf buffer length
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..dceca50 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,6 +54,15 @@ New Features
      Also, make sure to start the actual text at the margin.
      =========================================================
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 * **Updated Solarflare network PMD.**
 
   Updated the sfc_efx driver including the following changes:
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);
 
 	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..562d8bf 100644
--- a/kernel/linux/kni/compat.h
+++ b/kernel/linux/kni/compat.h
@@ -114,6 +114,10 @@
 #define ndo_change_mtu ndo_change_mtu_rh74
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)
+#define HAVE_MAX_MTU_PARAM
+#endif
+
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
 #define HAVE_SIGNAL_FUNCTIONS_OWN_HEADER
 #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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

[dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[lironh]

From: Liron Himi <lironh@marvell.com>

- mbuf_size and mtu are now being calculated according
to the given mb-pool.

- max_mtu is now being set according to the given mtu

the above two changes provide the ability to work with jumbo frames

Signed-off-by: Liron Himi <lironh@marvell.com>
---
 doc/guides/nics/kni.rst                        |  3 ++-
 doc/guides/prog_guide/kernel_nic_interface.rst |  2 ++
 doc/guides/rel_notes/release_19_05.rst         |  9 +++++++++
 drivers/net/kni/rte_eth_kni.c                  | 10 +++++++---
 kernel/linux/kni/compat.h                      |  4 ++++
 kernel/linux/kni/kni_misc.c                    |  3 +++
 6 files changed, 27 insertions(+), 4 deletions(-)

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)
 
 KNI control path is not supported with the PMD, since there is no physical
 backend device by default.
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 33ea980..c274b25 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -187,6 +187,8 @@ The ``struct rte_kni_conf`` structure contains fields which allow the
 user to specify the interface name, set the MTU size, set an explicit or
 random MAC address and control the affinity of the kernel Rx thread(s)
 (both single and multi-threaded modes).
+By default the KNI sample example gets the MTU from the matching device,
+and in case of KNI PMD it is derived from mbuf buffer length
 
 The ``struct rte_kni_ops`` structure contains pointers to functions to
 handle requests from the ``rte_kni`` kernel module.  These functions
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73..dceca50 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,6 +54,15 @@ New Features
      Also, make sure to start the actual text at the margin.
      =========================================================
 
+* **Updated KNI kernel module, KNI PMD driver.**
+
+  Updated the KNI kernel module to set the max_mtu according to the given
+  initial mtu size. Without it, the maximum mtu was 1500.
+
+  Updated the KNI PMD driver to set the mbuf_size and mtu based on
+  the given mb-pool. This provide the ability to pass jumbo frames
+  if the mb-pool contains suitable buffers' size.
+
 * **Updated Solarflare network PMD.**
 
   Updated the sfc_efx driver including the following changes:
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);
 
 	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..562d8bf 100644
--- a/kernel/linux/kni/compat.h
+++ b/kernel/linux/kni/compat.h
@@ -114,6 +114,10 @@
 #define ndo_change_mtu ndo_change_mtu_rh74
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)
+#define HAVE_MAX_MTU_PARAM
+#endif
+
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
 #define HAVE_SIGNAL_FUNCTIONS_OWN_HEADER
 #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
 
 	ret = register_netdev(net_dev);
 	if (ret) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[Thomas Monjalon]

26/03/2019 18:59, Ferruh Yigit:
> On 3/26/2019 6:40 PM, lironh@marvell.com wrote:
> > From: Liron Himi <lironh@marvell.com>
> > 
> > - mbuf_size and mtu are now being calculated according
> > to the given mb-pool.
> > 
> > - max_mtu is now being set according to the given mtu
> > 
> > the above two changes provide the ability to work with jumbo frames
> > 
> > Signed-off-by: Liron Himi <lironh@marvell.com>
> 
> Suggested title:
> kni: calculate MTU from mbuf buffer size
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks

Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool

[Thomas Monjalon]

26/03/2019 18:59, Ferruh Yigit:
> On 3/26/2019 6:40 PM, lironh@marvell.com wrote:
> > From: Liron Himi <lironh@marvell.com>
> > 
> > - mbuf_size and mtu are now being calculated according
> > to the given mb-pool.
> > 
> > - max_mtu is now being set according to the given mtu
> > 
> > the above two changes provide the ability to work with jumbo frames
> > 
> > Signed-off-by: Liron Himi <lironh@marvell.com>
> 
> Suggested title:
> kni: calculate MTU from mbuf buffer size
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks