[dpdk-dev] DPDK drivers should not use kernel version

[dpdk-dev] DPDK drivers should not use kernel version

[Stephen Hemminger]

Looking at some other issues, I noticed that both the TAP and MLX5 device
drivers are looking at kernel version through uname.  Although this may
seem like a good way to deal with kernel API changes, it is not reliable.

Enterprise kernel distro vendors never change kernel version but do backport
features from later kernels. Therefore the behavior expected may change
even though kernel version doesn't change. Also kernel version does not
dictate that the expected feature (like flower) is in the kernel configuration.

I recommend this be looked for in all future submissions. Maybe even flagged
as error in DPDK version of checkpatch.

$ git blame drivers/net/mlx5/mlx5_ethdev.c | grep uname
3a49ffe38a950 (Shahaf Shuler                2017-02-09 14:29:54 +0200  895) 	if (uname(&utsname) == -1 ||
$ git blame drivers/net/tap/rte_eth_tap.c | grep uname
de96fe68ae959 (Pascal Mazon     2017-03-23 09:33:57 +0100 1169) 	if (uname(&utsname) == -1 ||

Re: [dpdk-dev] DPDK drivers should not use kernel version

[Hemant Agrawal]

On 6/21/2017 9:58 PM, Stephen Hemminger wrote:
> Looking at some other issues, I noticed that both the TAP and MLX5 device
> drivers are looking at kernel version through uname.  Although this may
> seem like a good way to deal with kernel API changes, it is not reliable.
>
> Enterprise kernel distro vendors never change kernel version but do backport
> features from later kernels. Therefore the behavior expected may change
> even though kernel version doesn't change. Also kernel version does not
> dictate that the expected feature (like flower) is in the kernel configuration.
>
> I recommend this be looked for in all future submissions. Maybe even flagged
> as error in DPDK version of checkpatch.

what is the alternative than?

There are many legitimate cases, where userspace code need to make 
decision on the basis underlying kernel version.

In some cases, user space code can add error handling and fallback, but 
it is not possible in all cases.

>
> $ git blame drivers/net/mlx5/mlx5_ethdev.c | grep uname
> 3a49ffe38a950 (Shahaf Shuler                2017-02-09 14:29:54 +0200  895) 	if (uname(&utsname) == -1 ||
> $ git blame drivers/net/tap/rte_eth_tap.c | grep uname
> de96fe68ae959 (Pascal Mazon     2017-03-23 09:33:57 +0100 1169) 	if (uname(&utsname) == -1 ||
>
>

Re: [dpdk-dev] DPDK drivers should not use kernel version

[Stephen Hemminger]

On Fri, 23 Jun 2017 13:03:55 +0530
Hemant Agrawal <hemant.agrawal@nxp.com> wrote:

> On 6/21/2017 9:58 PM, Stephen Hemminger wrote:
> > Looking at some other issues, I noticed that both the TAP and MLX5 device
> > drivers are looking at kernel version through uname.  Although this may
> > seem like a good way to deal with kernel API changes, it is not reliable.
> >
> > Enterprise kernel distro vendors never change kernel version but do backport
> > features from later kernels. Therefore the behavior expected may change
> > even though kernel version doesn't change. Also kernel version does not
> > dictate that the expected feature (like flower) is in the kernel configuration.
> >
> > I recommend this be looked for in all future submissions. Maybe even flagged
> > as error in DPDK version of checkpatch.  
> 
> what is the alternative than?
> 
> There are many legitimate cases, where userspace code need to make 
> decision on the basis underlying kernel version.
> 
> In some cases, user space code can add error handling and fallback, but 
> it is not possible in all cases.

Userspace code should test for the specific feature it wants. I.e
is the flow qdisc available.  Then report missing feature as error if
necessary.

Re: [dpdk-dev] DPDK drivers should not use kernel version

[Shahaf Shuler]

Friday, June 23, 2017 10:34 AM, Hemant Agrawal:
> On 6/21/2017 9:58 PM, Stephen Hemminger wrote:
> > Looking at some other issues, I noticed that both the TAP and MLX5
> > device drivers are looking at kernel version through uname.  Although
> > this may seem like a good way to deal with kernel API changes, it is not
> reliable.
> >
> > Enterprise kernel distro vendors never change kernel version but do
> > backport features from later kernels. Therefore the behavior expected
> > may change even though kernel version doesn't change. Also kernel
> > version does not dictate that the expected feature (like flower) is in the
> kernel configuration.
> >
> > I recommend this be looked for in all future submissions. Maybe even
> > flagged as error in DPDK version of checkpatch.
> 
> what is the alternative than?
> 
> There are many legitimate cases, where userspace code need to make
> decision on the basis underlying kernel version.
> 
> In some cases, user space code can add error handling and fallback, but it is
> not possible in all cases.

+1 on Hemant question.

Taking for example mlx5 code -
Mlx5 uses the kernel for the control path, while the data path is in user space. 

In order to query the link status, it uses an ioctl. There are two different APIs for that : GLINKSETTING and GSET.
GSET was deprecated since kernel 4.5, and all the bugs in GLINKSETTING were fixed only after 4.9.

One could try to use the GSET API, and if fails use the GLINKSETTINGS. However, for kernels in range of [4.5,4.9) the behavior will not be correct.

On this specific example - backported kernel should maintain both APIs. 

> 
> >
> > $ git blame drivers/net/mlx5/mlx5_ethdev.c | grep uname
> > 3a49ffe38a950 (Shahaf Shuler                2017-02-09 14:29:54 +0200  895)
> 	if (uname(&utsname) == -1 ||
> > $ git blame drivers/net/tap/rte_eth_tap.c | grep uname
> > de96fe68ae959 (Pascal Mazon     2017-03-23 09:33:57 +0100 1169) 	if
> (uname(&utsname) == -1 ||
> >
> >
>