kni: add ability to set min/max MTU

Message ID 20190919112257.85337-1-iryzhov@nfware.com (mailing list archive)
State Superseded, archived
Delegated to: David Marchand
Headers
Series kni: add ability to set min/max MTU |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK
ci/iol-dpdk_compile_ovs success Compile Testing PASS
ci/iol-dpdk_compile success Compile Testing PASS
ci/iol-dpdk_compile_spdk success Compile Testing PASS
ci/intel-Performance success Performance Testing PASS
ci/mellanox-Performance success Performance Testing PASS

Commit Message

Igor Ryzhov Sept. 19, 2019, 11:22 a.m. UTC
  Starting with kernel version 4.10, there are new min/max MTU values in
net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
default. We should be able to change these values to allow MTU more than
1500 to be set on KNI.

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
---
 examples/kni/main.c                               | 3 +++
 kernel/linux/kni/compat.h                         | 4 ++++
 kernel/linux/kni/kni_misc.c                       | 8 ++++++++
 lib/librte_eal/linux/eal/include/rte_kni_common.h | 2 ++
 lib/librte_kni/rte_kni.c                          | 2 ++
 lib/librte_kni/rte_kni.h                          | 2 ++
 6 files changed, 21 insertions(+)
  

Comments

Ferruh Yigit Oct. 11, 2019, 4:16 p.m. UTC | #1
On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
> Starting with kernel version 4.10, there are new min/max MTU values in
> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
> default. We should be able to change these values to allow MTU more than
> 1500 to be set on KNI.
> 
> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
  
David Marchand Oct. 16, 2019, 6:40 a.m. UTC | #2
On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
> > Starting with kernel version 4.10, there are new min/max MTU values in
> > net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
> > default. We should be able to change these values to allow MTU more than
> > 1500 to be set on KNI.
> >
> > Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
Does it sound ok to you?

Would it make sense to backport this patch?


--
David Marchand
  
Ferruh Yigit Oct. 16, 2019, 10:43 a.m. UTC | #3
On 10/16/2019 7:40 AM, David Marchand wrote:
> On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
>>> Starting with kernel version 4.10, there are new min/max MTU values in
>>> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
>>> default. We should be able to change these values to allow MTU more than
>>> 1500 to be set on KNI.
>>>
>>> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
>>
>> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
> Does it sound ok to you?

I am not quite sure it is a fix, this patch enables application to pass min/max
MTU values for kni netdev but existing code is not doing anything wrong.

> 
> Would it make sense to backport this patch?
>
  
David Marchand Oct. 16, 2019, 10:55 a.m. UTC | #4
On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 10/16/2019 7:40 AM, David Marchand wrote:
> > On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >>
> >> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
> >>> Starting with kernel version 4.10, there are new min/max MTU values in
> >>> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
> >>> default. We should be able to change these values to allow MTU more than
> >>> 1500 to be set on KNI.
> >>>
> >>> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> >>
> >> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> > I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
> > Does it sound ok to you?
>
> I am not quite sure it is a fix, this patch enables application to pass min/max
> MTU values for kni netdev but existing code is not doing anything wrong.

To me, starting 4.10, we can't set the mtu to something greater than
1500 on a kni netdev, since netdev uses the ETH_DATA_LEN default value
and will refuse a bigger mtu before even calling the change mtu ndo.
Did I understand something wrong?
  
David Marchand Oct. 16, 2019, 2:47 p.m. UTC | #5
On Wed, Oct 16, 2019 at 12:55 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> > On 10/16/2019 7:40 AM, David Marchand wrote:
> > > On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > >>
> > >> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
> > >>> Starting with kernel version 4.10, there are new min/max MTU values in
> > >>> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
> > >>> default. We should be able to change these values to allow MTU more than
> > >>> 1500 to be set on KNI.
> > >>>
> > >>> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> > >>
> > >> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > >
> > > I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
> > > Does it sound ok to you?
> >
> > I am not quite sure it is a fix, this patch enables application to pass min/max
> > MTU values for kni netdev but existing code is not doing anything wrong.
>
> To me, starting 4.10, we can't set the mtu to something greater than
> 1500 on a kni netdev, since netdev uses the ETH_DATA_LEN default value
> and will refuse a bigger mtu before even calling the change mtu ndo.
> Did I understand something wrong?

- As discussed on irc and after looking deeper into the code.
The support for jumbo frames was already present and should be working
with the current code.
So I agree this does not qualify as a fix, sorry for the noise.

- On the other hand, we could refactor this patch to make use of/merge
with the existing HAVE_MAX_MTU_PARAM pre-existing macro without
introducing a new one.

- The commit title/log is still a bit cryptic to me, in which case
would an application pass a min_mtu/max_mtu?


Thanks.
  
Ferruh Yigit Oct. 16, 2019, 2:59 p.m. UTC | #6
On 10/16/2019 3:47 PM, David Marchand wrote:
> On Wed, Oct 16, 2019 at 12:55 PM David Marchand
> <david.marchand@redhat.com> wrote:
>>
>> On Wed, Oct 16, 2019 at 12:43 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>>
>>> On 10/16/2019 7:40 AM, David Marchand wrote:
>>>> On Fri, Oct 11, 2019 at 6:16 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>>>>
>>>>> On 9/19/2019 12:22 PM, Igor Ryzhov wrote:
>>>>>> Starting with kernel version 4.10, there are new min/max MTU values in
>>>>>> net_device structure, which are set to ETH_MIN_MTU and ETH_DATA_LEN by
>>>>>> default. We should be able to change these values to allow MTU more than
>>>>>> 1500 to be set on KNI.
>>>>>>
>>>>>> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
>>>>>
>>>>> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
>>>>
>>>> I intend to change the title as "kni: fix mtu setting with kernels >= 4.10".
>>>> Does it sound ok to you?
>>>
>>> I am not quite sure it is a fix, this patch enables application to pass min/max
>>> MTU values for kni netdev but existing code is not doing anything wrong.
>>
>> To me, starting 4.10, we can't set the mtu to something greater than
>> 1500 on a kni netdev, since netdev uses the ETH_DATA_LEN default value
>> and will refuse a bigger mtu before even calling the change mtu ndo.
>> Did I understand something wrong?
> 
> - As discussed on irc and after looking deeper into the code.
> The support for jumbo frames was already present and should be working
> with the current code.
> So I agree this does not qualify as a fix, sorry for the noise.
> 
> - On the other hand, we could refactor this patch to make use of/merge
> with the existing HAVE_MAX_MTU_PARAM pre-existing macro without
> introducing a new one.

+1 to this, I missed the existing HAVE_MAX_MTU_PARAM macro

> 
> - The commit title/log is still a bit cryptic to me, in which case
> would an application pass a min_mtu/max_mtu?
> 
> 
> Thanks.
>
  

Patch

diff --git a/examples/kni/main.c b/examples/kni/main.c
index 4710d7176..c22a7c18d 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -907,6 +907,9 @@  kni_alloc(uint16_t port_id)
 
 			rte_eth_dev_get_mtu(port_id, &conf.mtu);
 
+			conf.min_mtu = dev_info.min_mtu;
+			conf.max_mtu = dev_info.max_mtu;
+
 			memset(&ops, 0, sizeof(ops));
 			ops.port_id = port_id;
 			ops.change_mtu = kni_change_mtu;
diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h
index 562d8bf94..fe0ee55e7 100644
--- a/kernel/linux/kni/compat.h
+++ b/kernel/linux/kni/compat.h
@@ -89,6 +89,10 @@ 
 #define HAVE_TRANS_START_HELPER
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)
+#define HAVE_MIN_MAX_MTU
+#endif
+
 /*
  * KNI uses NET_NAME_UNKNOWN macro to select correct version of alloc_netdev()
  * For old kernels just backported the commit that enables the macro
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 2b75502a8..aeb275329 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -390,6 +390,14 @@  kni_ioctl_create(struct net *net, uint32_t ioctl_num,
 	net_dev->max_mtu = net_dev->mtu;
 #endif
 
+#ifdef HAVE_MIN_MAX_MTU
+	if (dev_info.min_mtu)
+		net_dev->min_mtu = dev_info.min_mtu;
+
+	if (dev_info.max_mtu)
+		net_dev->max_mtu = dev_info.max_mtu;
+#endif
+
 	ret = register_netdev(net_dev);
 	if (ret) {
 		pr_err("error %i registering device \"%s\"\n",
diff --git a/lib/librte_eal/linux/eal/include/rte_kni_common.h b/lib/librte_eal/linux/eal/include/rte_kni_common.h
index 37d9ee8f0..70992d835 100644
--- a/lib/librte_eal/linux/eal/include/rte_kni_common.h
+++ b/lib/librte_eal/linux/eal/include/rte_kni_common.h
@@ -120,6 +120,8 @@  struct rte_kni_device_info {
 	/* mbuf size */
 	unsigned mbuf_size;
 	unsigned int mtu;
+	unsigned int min_mtu;
+	unsigned int max_mtu;
 	uint8_t mac_addr[6];
 };
 
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 4b51fb4fe..521db27c4 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -252,6 +252,8 @@  rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
 	dev_info.group_id = conf->group_id;
 	dev_info.mbuf_size = conf->mbuf_size;
 	dev_info.mtu = conf->mtu;
+	dev_info.min_mtu = conf->min_mtu;
+	dev_info.max_mtu = conf->max_mtu;
 
 	memcpy(dev_info.mac_addr, conf->mac_addr, RTE_ETHER_ADDR_LEN);
 
diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index 5699a6443..b22446fa7 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -70,6 +70,8 @@  struct rte_kni_conf {
 	uint8_t force_bind : 1; /* Flag to bind kernel thread */
 	uint8_t mac_addr[RTE_ETHER_ADDR_LEN]; /* MAC address assigned to KNI */
 	uint16_t mtu;
+	uint16_t min_mtu;
+	uint16_t max_mtu;
 };
 
 /**