From: Shahaf Shuler <shahafs@mellanox.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Pascal Mazon <pascal.mazon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: DPDK drivers should not use kernel version
Date: Sun, 25 Jun 2017 06:03:56 +0000 [thread overview]
Message-ID: <VI1PR05MB31494B830614336908DFE10AC3DE0@VI1PR05MB3149.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <4376741f-cece-8086-eddb-c35ee9ef06a4@nxp.com>
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 ||
> >
> >
>
prev parent reply other threads:[~2017-06-25 6:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 16:28 DPDK drivers should not use kernel version Stephen Hemminger
2017-06-23 7:33 ` Hemant Agrawal
2017-06-23 17:55 ` Stephen Hemminger
2017-06-25 6:03 ` Shahaf Shuler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR05MB31494B830614336908DFE10AC3DE0@VI1PR05MB3149.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=pascal.mazon@6wind.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.