* Re: [dpdk-dev] DPDK drivers should not use kernel version
2017-06-23 7:33 ` Hemant Agrawal
@ 2017-06-23 17:55 ` Stephen Hemminger
2017-06-25 6:03 ` Shahaf Shuler
1 sibling, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2017-06-23 17:55 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: Shahaf Shuler, Pascal Mazon, dev
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] DPDK drivers should not use kernel version
2017-06-23 7:33 ` Hemant Agrawal
2017-06-23 17:55 ` Stephen Hemminger
@ 2017-06-25 6:03 ` Shahaf Shuler
1 sibling, 0 replies; 4+ messages in thread
From: Shahaf Shuler @ 2017-06-25 6:03 UTC (permalink / raw)
To: Hemant Agrawal, Stephen Hemminger, Pascal Mazon; +Cc: dev
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 ||
> >
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread