* [dpdk-dev] [PATCH] net/kni: calc mbuf&mtu according to given mb_pool @ 2019-02-21 8:47 lironh 2019-02-23 20:14 ` [dpdk-dev] [PATCH v2] " lironh 0 siblings, 1 reply; 37+ messages in thread From: lironh @ 2019-02-21 8:47 UTC (permalink / raw) To: dev; +Cc: ferruh.yigit, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-02-21 8:47 [dpdk-dev] [PATCH] net/kni: calc mbuf&mtu according to given mb_pool lironh @ 2019-02-23 20:14 ` lironh 2019-02-25 11:29 ` Liron Himi 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh 0 siblings, 2 replies; 37+ messages in thread From: lironh @ 2019-02-23 20:14 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-02-23 20:14 ` [dpdk-dev] [PATCH v2] " lironh @ 2019-02-25 11:29 ` Liron Himi 2019-03-10 14:27 ` Liron Himi 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh 1 sibling, 1 reply; 37+ messages in thread From: Liron Himi @ 2019-02-25 11:29 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, Liron Himi, 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-02-25 11:29 ` Liron Himi @ 2019-03-10 14:27 ` Liron Himi 2019-03-13 16:57 ` Ferruh Yigit 0 siblings, 1 reply; 37+ messages in thread From: Liron Himi @ 2019-03-10 14:27 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, Alan Winkowski, 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-10 14:27 ` Liron Himi @ 2019-03-13 16:57 ` Ferruh Yigit 2019-03-14 6:37 ` Liron Himi 0 siblings, 1 reply; 37+ messages in thread From: Ferruh Yigit @ 2019-03-13 16:57 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski 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? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-13 16:57 ` Ferruh Yigit @ 2019-03-14 6:37 ` Liron Himi 2019-03-14 6:37 ` Liron Himi 2019-03-14 9:28 ` Ferruh Yigit 0 siblings, 2 replies; 37+ messages in thread From: Liron Himi @ 2019-03-14 6:37 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-14 6:37 ` Liron Himi @ 2019-03-14 6:37 ` Liron Himi 2019-03-14 9:28 ` Ferruh Yigit 1 sibling, 0 replies; 37+ messages in thread From: Liron Himi @ 2019-03-14 6:37 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-14 6:37 ` Liron Himi 2019-03-14 6:37 ` Liron Himi @ 2019-03-14 9:28 ` Ferruh Yigit 2019-03-14 9:28 ` Ferruh Yigit 2019-03-15 17:02 ` Liron Himi 1 sibling, 2 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-14 9:28 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski 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? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-14 9:28 ` Ferruh Yigit @ 2019-03-14 9:28 ` Ferruh Yigit 2019-03-15 17:02 ` Liron Himi 1 sibling, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-14 9:28 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski 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? ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-14 9:28 ` Ferruh Yigit 2019-03-14 9:28 ` Ferruh Yigit @ 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:59 ` Ferruh Yigit 1 sibling, 2 replies; 37+ messages in thread From: Liron Himi @ 2019-03-15 17:02 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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 = ð_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; ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-15 17:02 ` Liron Himi @ 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:59 ` Ferruh Yigit 1 sibling, 0 replies; 37+ messages in thread From: Liron Himi @ 2019-03-15 17:02 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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 = ð_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; ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:02 ` Liron Himi @ 2019-03-15 17:59 ` Ferruh Yigit 2019-03-15 17:59 ` Ferruh Yigit 2019-03-17 9:43 ` Liron Himi 1 sibling, 2 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-15 17:59 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski 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 = ð_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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-15 17:59 ` Ferruh Yigit @ 2019-03-15 17:59 ` Ferruh Yigit 2019-03-17 9:43 ` Liron Himi 1 sibling, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-15 17:59 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski 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 = ð_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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-15 17:59 ` Ferruh Yigit 2019-03-15 17:59 ` Ferruh Yigit @ 2019-03-17 9:43 ` Liron Himi 2019-03-17 9:43 ` Liron Himi 2019-03-20 19:48 ` Ferruh Yigit 1 sibling, 2 replies; 37+ messages in thread From: Liron Himi @ 2019-03-17 9:43 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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 = ð_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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-17 9:43 ` Liron Himi @ 2019-03-17 9:43 ` Liron Himi 2019-03-20 19:48 ` Ferruh Yigit 1 sibling, 0 replies; 37+ messages in thread From: Liron Himi @ 2019-03-17 9:43 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Alan Winkowski, 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 = ð_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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-17 9:43 ` Liron Himi 2019-03-17 9:43 ` Liron Himi @ 2019-03-20 19:48 ` Ferruh Yigit 2019-03-20 19:48 ` Ferruh Yigit 1 sibling, 1 reply; 37+ messages in thread From: Ferruh Yigit @ 2019-03-20 19:48 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski On 3/17/2019 9:43 AM, Liron Himi wrote: > > > -----Original Message----- > From: Ferruh Yigit <ferruh.yigit@intel.com> > Sent: Friday, March 15, 2019 19:59 > To: Liron Himi <lironh@marvell.com> > Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> > Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool > > On 3/15/2019 5:02 PM, Liron Himi wrote: >> >> >> -----Original Message----- >> From: Ferruh Yigit <ferruh.yigit@intel.com> >> Sent: Thursday, March 14, 2019 11:28 >> To: Liron Himi <lironh@marvell.com> >> Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> >> Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given >> mb_pool >> >> On 3/14/2019 6:37 AM, Liron Himi wrote: >>> >>> >>> -----Original Message----- >>> From: Ferruh Yigit <ferruh.yigit@intel.com> >>> Sent: Wednesday, March 13, 2019 18:58 >>> To: Liron Himi <lironh@marvell.com> >>> Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> >>> Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given >>> mb_pool >>> >>> On 3/10/2019 2:27 PM, Liron Himi wrote: >>>> Adding Alan. >>>> >>>> -----Original Message----- >>>> From: Liron Himi >>>> Sent: Monday, February 25, 2019 13:30 >>>> To: ferruh.yigit@intel.com >>>> Cc: dev@dpdk.org; Liron Himi <lironh@marvell.com>; Liron Himi >>>> <lironh@marvell.com> >>>> Subject: RE: [PATCH v2] net/kni: calc mbuf&mtu according to given >>>> mb_pool >>>> >>>> Hi, >>>> >>>> Kind reminder >>> >>> Sorry for late response. >>> >>>> >>>> Regards, >>>> Liron >>>> >>>> -----Original Message----- >>>> From: lironh@marvell.com <lironh@marvell.com> >>>> Sent: Saturday, February 23, 2019 22:15 >>>> To: ferruh.yigit@intel.com >>>> Cc: dev@dpdk.org; Liron Himi <lironh@marvell.com> >>>> Subject: [PATCH v2] net/kni: calc mbuf&mtu according to given >>>> mb_pool >>>> >>>> From: Liron Himi <lironh@marvell.com> >>>> >>>> - mbuf_size and mtu are now being calculated according to the given mb-pool. >>> >>> +1 to have dynamic size instead of fixed "MAX_PACKET_SZ" >>> >>>> >>>> - max_mtu is now being set according to the given mtu >>>> >>>> the above two changes provide the ability to work with jumbo frames >>> >>> From kernel -> userspace, if the data length is bigger than >>> mbuf->buffer_len (- >>> headroom) the packet is dropped. I guess you are trying to solve that issue? >>> [L.H.] correct >>> >>> By providing larger mbuf buffer, it should be possible to send larger (jumbo) packets? >>> [L.H.] correct >>> >>> Another option can be adding multi segment send support, that also lets sending large packets from kernel to userspace, and it can co-exits with your patch. >>> What do you think, can you work on that support? >>> [L.H.] I suggest to first go with this patch, and then prepare >>> multi-segment patch if possible >> >> Yes, I was hoping both can go in a same patchset, can it be possible? >> [L.H.] I'm on tight schedule right now, I prefer to continue with this patch as is, multi-segment support can be pushed later on. > > OK > >> >>> Multi segment support already exists in userspace to kernel path, but otherway around is missing. >>> >>>> >>>> Signed-off-by: Liron Himi <lironh@marvell.com> >>>> --- >>>> drivers/net/kni/rte_eth_kni.c | 10 +++++++--- >>>> kernel/linux/kni/compat.h | 4 ++++ >>>> kernel/linux/kni/kni_misc.c | 3 +++ >>> >>> It can be good to update release notes / kni documentation to document new feature. >>> [L.H.] okay > [L.H.] I have made the following change, but I'm not sure to which document to mark the adding of this new feature. > Is it release notes? If yes, which exact one? I think feature is big enough to add to release notes, the one for current release is: "doc/guides/rel_notes/release_19_05.rst". > > Should I mark it as Jumbo support? Or just specify that the mtu and mbuf are based on the given pool? I was thinking "doc/guides/prog_guide/kernel_nic_interface.rst" instead of kni PMD doc. In that doc, in "KNI Creation and Deletion" section, there is a paragraph about "struct rte_kni_conf", I think appending a single sentences to that paragraph to say by default mtu is set as mbuf buffer length is good. > > > diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst > index 204fbd5..a66c595 100644 > --- a/doc/guides/nics/kni.rst > +++ b/doc/guides/nics/kni.rst > @@ -55,7 +55,8 @@ configuration: > > Interface name: kni# > force bind kernel thread to a core : NO > - mbuf size: MAX_PACKET_SZ > + mbuf size: (rte_pktmbuf_data_room_size(pktmbuf_pool) - RTE_PKTMBUF_HEADROOM) > + mtu: (conf.mbuf_size - ETHER_HDR_LEN) >>> >>>> 3 files changed, 14 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/net/kni/rte_eth_kni.c >>>> b/drivers/net/kni/rte_eth_kni.c index a1e9970..5e02224 100644 >>>> --- a/drivers/net/kni/rte_eth_kni.c >>>> +++ b/drivers/net/kni/rte_eth_kni.c >>>> @@ -16,9 +16,11 @@ >>>> /* Only single queue supported */ >>>> #define KNI_MAX_QUEUE_PER_PORT 1 >>>> >>>> -#define MAX_PACKET_SZ 2048 >>>> #define MAX_KNI_PORTS 8 >>>> >>>> +#define KNI_ETHER_MTU(mbuf_size) \ >>>> + ((mbuf_size) - ETHER_HDR_LEN) /**< Ethernet MTU. */ >>>> + >>>> #define ETH_KNI_NO_REQUEST_THREAD_ARG "no_request_thread" >>>> static const char * const valid_arguments[] = { >>>> ETH_KNI_NO_REQUEST_THREAD_ARG, >>>> @@ -123,11 +125,13 @@ eth_kni_start(struct rte_eth_dev *dev) >>>> struct rte_kni_conf conf; >>>> const char *name = dev->device->name + 4; /* remove net_ */ >>>> >>>> + mb_pool = internals->rx_queues[0].mb_pool; >>>> snprintf(conf.name, RTE_KNI_NAMESIZE, "%s", name); >>>> conf.force_bind = 0; >>>> conf.group_id = port_id; >>>> - conf.mbuf_size = MAX_PACKET_SZ; >>>> - mb_pool = internals->rx_queues[0].mb_pool; >>>> + conf.mbuf_size = >>>> + rte_pktmbuf_data_room_size(mb_pool) - RTE_PKTMBUF_HEADROOM; >>>> + conf.mtu = KNI_ETHER_MTU(conf.mbuf_size); >>> >>> Can you please do "conf.mbuf_size" changes also to kni sample application? >>> kni sample application gets mtu from physical device, so I believe better to not change that but I think mbuf_size can be dynamic instead of hardcoded. >>> [L.H.] okay >>> >>> Another question, for the case mbuf size < ETHER_MTU, should we keep MTU ETHER_MTU, what do you think? >>> [L.H.] in any case we need to set the MTU according to the mbuf-size until multi-segment support will be available, right? >> >> Right. >> >>> >>>> >>>> internals->kni = rte_kni_alloc(mb_pool, &conf, NULL); >>>> if (internals->kni == NULL) { >>>> diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h >>>> index 3c575c7..b9f9a6f 100644 >>>> --- a/kernel/linux/kni/compat.h >>>> +++ b/kernel/linux/kni/compat.h >>>> @@ -117,3 +117,7 @@ >>>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0) #define >>>> HAVE_SIGNAL_FUNCTIONS_OWN_HEADER #endif >>>> + >>>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0) #define >>>> +HAVE_MAX_MTU_PARAM #endif >>>> diff --git a/kernel/linux/kni/kni_misc.c >>>> b/kernel/linux/kni/kni_misc.c index 522ae23..04c78eb 100644 >>>> --- a/kernel/linux/kni/kni_misc.c >>>> +++ b/kernel/linux/kni/kni_misc.c >>>> @@ -459,6 +459,9 @@ kni_ioctl_create(struct net *net, uint32_t >>>> ioctl_num, >>>> >>>> if (dev_info.mtu) >>>> net_dev->mtu = dev_info.mtu; >>>> +#ifdef HAVE_MAX_MTU_PARAM >>>> + net_dev->max_mtu = net_dev->mtu; >>>> +#endif >>> >>> Do we need to set 'max_mtu'? I guess this is not really required for large packet support, if so what do you think making this separate patch? >>> [L.H.] 'max_mtu' is set by default to '1500', so in order to be able to modify the interface MTU to support jumbo (or even any size > 1500) the 'max_mtu' must be updated to the larger supported value. >> >> I missed that it set by default to '1500', I was thinking it is zero by default. >> Can you please point where its default value set in Linux? >> [L.H.] I also thought that a zero value will make more sense to provide backwards compatibility, but this is not the case. >> Here is the code snipped from net/ethernet/eth.c : >> void ether_setup(struct net_device *dev) { >> dev->header_ops = ð_header_ops; >> dev->type = ARPHRD_ETHER; >> dev->hard_header_len = ETH_HLEN; >> dev->min_header_len = ETH_HLEN; >> dev->mtu = ETH_DATA_LEN; >> dev->min_mtu = ETH_MIN_MTU; >> dev->max_mtu = ETH_DATA_LEN; >> > > You are right, thanks for the pointer, please go with this update. > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-20 19:48 ` Ferruh Yigit @ 2019-03-20 19:48 ` Ferruh Yigit 0 siblings, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-20 19:48 UTC (permalink / raw) To: Liron Himi; +Cc: dev, Alan Winkowski On 3/17/2019 9:43 AM, Liron Himi wrote: > > > -----Original Message----- > From: Ferruh Yigit <ferruh.yigit@intel.com> > Sent: Friday, March 15, 2019 19:59 > To: Liron Himi <lironh@marvell.com> > Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> > Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given mb_pool > > On 3/15/2019 5:02 PM, Liron Himi wrote: >> >> >> -----Original Message----- >> From: Ferruh Yigit <ferruh.yigit@intel.com> >> Sent: Thursday, March 14, 2019 11:28 >> To: Liron Himi <lironh@marvell.com> >> Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> >> Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given >> mb_pool >> >> On 3/14/2019 6:37 AM, Liron Himi wrote: >>> >>> >>> -----Original Message----- >>> From: Ferruh Yigit <ferruh.yigit@intel.com> >>> Sent: Wednesday, March 13, 2019 18:58 >>> To: Liron Himi <lironh@marvell.com> >>> Cc: dev@dpdk.org; Alan Winkowski <walan@marvell.com> >>> Subject: Re: [PATCH v2] net/kni: calc mbuf&mtu according to given >>> mb_pool >>> >>> On 3/10/2019 2:27 PM, Liron Himi wrote: >>>> Adding Alan. >>>> >>>> -----Original Message----- >>>> From: Liron Himi >>>> Sent: Monday, February 25, 2019 13:30 >>>> To: ferruh.yigit@intel.com >>>> Cc: dev@dpdk.org; Liron Himi <lironh@marvell.com>; Liron Himi >>>> <lironh@marvell.com> >>>> Subject: RE: [PATCH v2] net/kni: calc mbuf&mtu according to given >>>> mb_pool >>>> >>>> Hi, >>>> >>>> Kind reminder >>> >>> Sorry for late response. >>> >>>> >>>> Regards, >>>> Liron >>>> >>>> -----Original Message----- >>>> From: lironh@marvell.com <lironh@marvell.com> >>>> Sent: Saturday, February 23, 2019 22:15 >>>> To: ferruh.yigit@intel.com >>>> Cc: dev@dpdk.org; Liron Himi <lironh@marvell.com> >>>> Subject: [PATCH v2] net/kni: calc mbuf&mtu according to given >>>> mb_pool >>>> >>>> From: Liron Himi <lironh@marvell.com> >>>> >>>> - mbuf_size and mtu are now being calculated according to the given mb-pool. >>> >>> +1 to have dynamic size instead of fixed "MAX_PACKET_SZ" >>> >>>> >>>> - max_mtu is now being set according to the given mtu >>>> >>>> the above two changes provide the ability to work with jumbo frames >>> >>> From kernel -> userspace, if the data length is bigger than >>> mbuf->buffer_len (- >>> headroom) the packet is dropped. I guess you are trying to solve that issue? >>> [L.H.] correct >>> >>> By providing larger mbuf buffer, it should be possible to send larger (jumbo) packets? >>> [L.H.] correct >>> >>> Another option can be adding multi segment send support, that also lets sending large packets from kernel to userspace, and it can co-exits with your patch. >>> What do you think, can you work on that support? >>> [L.H.] I suggest to first go with this patch, and then prepare >>> multi-segment patch if possible >> >> Yes, I was hoping both can go in a same patchset, can it be possible? >> [L.H.] I'm on tight schedule right now, I prefer to continue with this patch as is, multi-segment support can be pushed later on. > > OK > >> >>> Multi segment support already exists in userspace to kernel path, but otherway around is missing. >>> >>>> >>>> Signed-off-by: Liron Himi <lironh@marvell.com> >>>> --- >>>> drivers/net/kni/rte_eth_kni.c | 10 +++++++--- >>>> kernel/linux/kni/compat.h | 4 ++++ >>>> kernel/linux/kni/kni_misc.c | 3 +++ >>> >>> It can be good to update release notes / kni documentation to document new feature. >>> [L.H.] okay > [L.H.] I have made the following change, but I'm not sure to which document to mark the adding of this new feature. > Is it release notes? If yes, which exact one? I think feature is big enough to add to release notes, the one for current release is: "doc/guides/rel_notes/release_19_05.rst". > > Should I mark it as Jumbo support? Or just specify that the mtu and mbuf are based on the given pool? I was thinking "doc/guides/prog_guide/kernel_nic_interface.rst" instead of kni PMD doc. In that doc, in "KNI Creation and Deletion" section, there is a paragraph about "struct rte_kni_conf", I think appending a single sentences to that paragraph to say by default mtu is set as mbuf buffer length is good. > > > diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst > index 204fbd5..a66c595 100644 > --- a/doc/guides/nics/kni.rst > +++ b/doc/guides/nics/kni.rst > @@ -55,7 +55,8 @@ configuration: > > Interface name: kni# > force bind kernel thread to a core : NO > - mbuf size: MAX_PACKET_SZ > + mbuf size: (rte_pktmbuf_data_room_size(pktmbuf_pool) - RTE_PKTMBUF_HEADROOM) > + mtu: (conf.mbuf_size - ETHER_HDR_LEN) >>> >>>> 3 files changed, 14 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/net/kni/rte_eth_kni.c >>>> b/drivers/net/kni/rte_eth_kni.c index a1e9970..5e02224 100644 >>>> --- a/drivers/net/kni/rte_eth_kni.c >>>> +++ b/drivers/net/kni/rte_eth_kni.c >>>> @@ -16,9 +16,11 @@ >>>> /* Only single queue supported */ >>>> #define KNI_MAX_QUEUE_PER_PORT 1 >>>> >>>> -#define MAX_PACKET_SZ 2048 >>>> #define MAX_KNI_PORTS 8 >>>> >>>> +#define KNI_ETHER_MTU(mbuf_size) \ >>>> + ((mbuf_size) - ETHER_HDR_LEN) /**< Ethernet MTU. */ >>>> + >>>> #define ETH_KNI_NO_REQUEST_THREAD_ARG "no_request_thread" >>>> static const char * const valid_arguments[] = { >>>> ETH_KNI_NO_REQUEST_THREAD_ARG, >>>> @@ -123,11 +125,13 @@ eth_kni_start(struct rte_eth_dev *dev) >>>> struct rte_kni_conf conf; >>>> const char *name = dev->device->name + 4; /* remove net_ */ >>>> >>>> + mb_pool = internals->rx_queues[0].mb_pool; >>>> snprintf(conf.name, RTE_KNI_NAMESIZE, "%s", name); >>>> conf.force_bind = 0; >>>> conf.group_id = port_id; >>>> - conf.mbuf_size = MAX_PACKET_SZ; >>>> - mb_pool = internals->rx_queues[0].mb_pool; >>>> + conf.mbuf_size = >>>> + rte_pktmbuf_data_room_size(mb_pool) - RTE_PKTMBUF_HEADROOM; >>>> + conf.mtu = KNI_ETHER_MTU(conf.mbuf_size); >>> >>> Can you please do "conf.mbuf_size" changes also to kni sample application? >>> kni sample application gets mtu from physical device, so I believe better to not change that but I think mbuf_size can be dynamic instead of hardcoded. >>> [L.H.] okay >>> >>> Another question, for the case mbuf size < ETHER_MTU, should we keep MTU ETHER_MTU, what do you think? >>> [L.H.] in any case we need to set the MTU according to the mbuf-size until multi-segment support will be available, right? >> >> Right. >> >>> >>>> >>>> internals->kni = rte_kni_alloc(mb_pool, &conf, NULL); >>>> if (internals->kni == NULL) { >>>> diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h >>>> index 3c575c7..b9f9a6f 100644 >>>> --- a/kernel/linux/kni/compat.h >>>> +++ b/kernel/linux/kni/compat.h >>>> @@ -117,3 +117,7 @@ >>>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0) #define >>>> HAVE_SIGNAL_FUNCTIONS_OWN_HEADER #endif >>>> + >>>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0) #define >>>> +HAVE_MAX_MTU_PARAM #endif >>>> diff --git a/kernel/linux/kni/kni_misc.c >>>> b/kernel/linux/kni/kni_misc.c index 522ae23..04c78eb 100644 >>>> --- a/kernel/linux/kni/kni_misc.c >>>> +++ b/kernel/linux/kni/kni_misc.c >>>> @@ -459,6 +459,9 @@ kni_ioctl_create(struct net *net, uint32_t >>>> ioctl_num, >>>> >>>> if (dev_info.mtu) >>>> net_dev->mtu = dev_info.mtu; >>>> +#ifdef HAVE_MAX_MTU_PARAM >>>> + net_dev->max_mtu = net_dev->mtu; >>>> +#endif >>> >>> Do we need to set 'max_mtu'? I guess this is not really required for large packet support, if so what do you think making this separate patch? >>> [L.H.] 'max_mtu' is set by default to '1500', so in order to be able to modify the interface MTU to support jumbo (or even any size > 1500) the 'max_mtu' must be updated to the larger supported value. >> >> I missed that it set by default to '1500', I was thinking it is zero by default. >> Can you please point where its default value set in Linux? >> [L.H.] I also thought that a zero value will make more sense to provide backwards compatibility, but this is not the case. >> Here is the code snipped from net/ethernet/eth.c : >> void ether_setup(struct net_device *dev) { >> dev->header_ops = ð_header_ops; >> dev->type = ARPHRD_ETHER; >> dev->hard_header_len = ETH_HLEN; >> dev->min_header_len = ETH_HLEN; >> dev->mtu = ETH_DATA_LEN; >> dev->min_mtu = ETH_MIN_MTU; >> dev->max_mtu = ETH_DATA_LEN; >> > > You are right, thanks for the pointer, please go with this update. > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-02-23 20:14 ` [dpdk-dev] [PATCH v2] " lironh 2019-02-25 11:29 ` Liron Himi @ 2019-03-22 18:12 ` lironh 2019-03-22 18:12 ` lironh ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: lironh @ 2019-03-22 18:12 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh @ 2019-03-22 18:12 ` lironh 2019-03-23 21:48 ` Rami Rosen 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh 2 siblings, 0 replies; 37+ messages in thread From: lironh @ 2019-03-22 18:12 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh 2019-03-22 18:12 ` lironh @ 2019-03-23 21:48 ` Rami Rosen 2019-03-23 21:48 ` Rami Rosen 2019-03-24 10:05 ` [dpdk-dev] [EXT] " Liron Himi 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh 2 siblings, 2 replies; 37+ messages in thread From: Rami Rosen @ 2019-03-23 21:48 UTC (permalink / raw) To: lironh; +Cc: ferruh.yigit, dev, walan <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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-23 21:48 ` Rami Rosen @ 2019-03-23 21:48 ` Rami Rosen 2019-03-24 10:05 ` [dpdk-dev] [EXT] " Liron Himi 1 sibling, 0 replies; 37+ messages in thread From: Rami Rosen @ 2019-03-23 21:48 UTC (permalink / raw) To: lironh; +Cc: ferruh.yigit, dev, walan <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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [EXT] Re: [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-23 21:48 ` Rami Rosen 2019-03-23 21:48 ` Rami Rosen @ 2019-03-24 10:05 ` Liron Himi 2019-03-24 10:05 ` Liron Himi 1 sibling, 1 reply; 37+ messages in thread From: Liron Himi @ 2019-03-24 10:05 UTC (permalink / raw) To: Rami Rosen; +Cc: ferruh.yigit, dev, Alan Winkowski, 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>> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [EXT] Re: [PATCH v3] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-24 10:05 ` [dpdk-dev] [EXT] " Liron Himi @ 2019-03-24 10:05 ` Liron Himi 0 siblings, 0 replies; 37+ messages in thread From: Liron Himi @ 2019-03-24 10:05 UTC (permalink / raw) To: Rami Rosen; +Cc: ferruh.yigit, dev, Alan Winkowski, 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>> ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh 2019-03-22 18:12 ` lironh 2019-03-23 21:48 ` Rami Rosen @ 2019-03-24 12:15 ` lironh 2019-03-24 12:15 ` lironh ` (2 more replies) 2 siblings, 3 replies; 37+ messages in thread From: lironh @ 2019-03-24 12:15 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh @ 2019-03-24 12:15 ` lironh 2019-03-25 15:44 ` Ferruh Yigit 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh 2 siblings, 0 replies; 37+ messages in thread From: lironh @ 2019-03-24 12:15 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh 2019-03-24 12:15 ` lironh @ 2019-03-25 15:44 ` Ferruh Yigit 2019-03-25 15:44 ` Ferruh Yigit 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh 2 siblings, 1 reply; 37+ messages in thread From: Ferruh Yigit @ 2019-03-25 15:44 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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) { > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v4] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-25 15:44 ` Ferruh Yigit @ 2019-03-25 15:44 ` Ferruh Yigit 0 siblings, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-25 15:44 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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) { > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh 2019-03-24 12:15 ` lironh 2019-03-25 15:44 ` Ferruh Yigit @ 2019-03-25 20:48 ` lironh 2019-03-25 20:48 ` lironh ` (2 more replies) 2 siblings, 3 replies; 37+ messages in thread From: lironh @ 2019-03-25 20:48 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh @ 2019-03-25 20:48 ` lironh 2019-03-25 21:11 ` Ferruh Yigit 2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh 2 siblings, 0 replies; 37+ messages in thread From: lironh @ 2019-03-25 20:48 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh 2019-03-25 20:48 ` lironh @ 2019-03-25 21:11 ` Ferruh Yigit 2019-03-25 21:11 ` Ferruh Yigit 2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh 2 siblings, 1 reply; 37+ messages in thread From: Ferruh Yigit @ 2019-03-25 21:11 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v5] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-25 21:11 ` Ferruh Yigit @ 2019-03-25 21:11 ` Ferruh Yigit 0 siblings, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-25 21:11 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh 2019-03-25 20:48 ` lironh 2019-03-25 21:11 ` Ferruh Yigit @ 2019-03-26 18:40 ` lironh 2019-03-26 17:59 ` Ferruh Yigit 2019-03-26 18:40 ` lironh 2 siblings, 2 replies; 37+ messages in thread From: lironh @ 2019-03-26 18:40 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh @ 2019-03-26 17:59 ` Ferruh Yigit 2019-03-26 17:59 ` Ferruh Yigit 2019-03-30 0:00 ` Thomas Monjalon 2019-03-26 18:40 ` lironh 1 sibling, 2 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-26 17:59 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-26 17:59 ` Ferruh Yigit @ 2019-03-26 17:59 ` Ferruh Yigit 2019-03-30 0:00 ` Thomas Monjalon 1 sibling, 0 replies; 37+ messages in thread From: Ferruh Yigit @ 2019-03-26 17:59 UTC (permalink / raw) To: lironh; +Cc: dev, walan 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-26 17:59 ` Ferruh Yigit 2019-03-26 17:59 ` Ferruh Yigit @ 2019-03-30 0:00 ` Thomas Monjalon 2019-03-30 0:00 ` Thomas Monjalon 1 sibling, 1 reply; 37+ messages in thread From: Thomas Monjalon @ 2019-03-30 0:00 UTC (permalink / raw) To: lironh; +Cc: dev, Ferruh Yigit, walan 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-30 0:00 ` Thomas Monjalon @ 2019-03-30 0:00 ` Thomas Monjalon 0 siblings, 0 replies; 37+ messages in thread From: Thomas Monjalon @ 2019-03-30 0:00 UTC (permalink / raw) To: lironh; +Cc: dev, Ferruh Yigit, walan 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [dpdk-dev] [PATCH v6] net/kni: calc mbuf&mtu according to given mb_pool 2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh 2019-03-26 17:59 ` Ferruh Yigit @ 2019-03-26 18:40 ` lironh 1 sibling, 0 replies; 37+ messages in thread From: lironh @ 2019-03-26 18:40 UTC (permalink / raw) To: ferruh.yigit; +Cc: dev, walan, Liron Himi 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2019-03-30 0:00 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-21 8:47 [dpdk-dev] [PATCH] net/kni: calc mbuf&mtu according to given mb_pool lironh 2019-02-23 20:14 ` [dpdk-dev] [PATCH v2] " lironh 2019-02-25 11:29 ` Liron Himi 2019-03-10 14:27 ` Liron Himi 2019-03-13 16:57 ` Ferruh Yigit 2019-03-14 6:37 ` Liron Himi 2019-03-14 6:37 ` Liron Himi 2019-03-14 9:28 ` Ferruh Yigit 2019-03-14 9:28 ` Ferruh Yigit 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:02 ` Liron Himi 2019-03-15 17:59 ` Ferruh Yigit 2019-03-15 17:59 ` Ferruh Yigit 2019-03-17 9:43 ` Liron Himi 2019-03-17 9:43 ` Liron Himi 2019-03-20 19:48 ` Ferruh Yigit 2019-03-20 19:48 ` Ferruh Yigit 2019-03-22 18:12 ` [dpdk-dev] [PATCH v3] " lironh 2019-03-22 18:12 ` lironh 2019-03-23 21:48 ` Rami Rosen 2019-03-23 21:48 ` Rami Rosen 2019-03-24 10:05 ` [dpdk-dev] [EXT] " Liron Himi 2019-03-24 10:05 ` Liron Himi 2019-03-24 12:15 ` [dpdk-dev] [PATCH v4] " lironh 2019-03-24 12:15 ` lironh 2019-03-25 15:44 ` Ferruh Yigit 2019-03-25 15:44 ` Ferruh Yigit 2019-03-25 20:48 ` [dpdk-dev] [PATCH v5] " lironh 2019-03-25 20:48 ` lironh 2019-03-25 21:11 ` Ferruh Yigit 2019-03-25 21:11 ` Ferruh Yigit 2019-03-26 18:40 ` [dpdk-dev] [PATCH v6] " lironh 2019-03-26 17:59 ` Ferruh Yigit 2019-03-26 17:59 ` Ferruh Yigit 2019-03-30 0:00 ` Thomas Monjalon 2019-03-30 0:00 ` Thomas Monjalon 2019-03-26 18:40 ` lironh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).