From: Mark McLoughlin <markmc@redhat.com>
To: Pierre Riteau <Pierre.Riteau@irisa.fr>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] Fix TAP networking on host kernels without IFF_VNET_HDR support
Date: Wed, 25 Nov 2009 08:55:55 +0000 [thread overview]
Message-ID: <1259139355.2514.5.camel@blaa> (raw)
In-Reply-To: <14A83280-2A2D-4DCC-BD75-5DB6B43883EB@irisa.fr>
On Tue, 2009-11-24 at 22:27 +0100, Pierre Riteau wrote:
> On 24 nov. 2009, at 12:22, Mark McLoughlin wrote:
>
> > On Tue, 2009-11-24 at 12:17 +0100, Pierre Riteau wrote:
> >> Isn't there a way to detect whether the kernel supports the
> >> TUNSETOFFLOAD ioctl at all?
> >
> > The kernel will set errno to EINVAL if TUNSETOFFLOAD isn't supported, so
> > we could just ignore that case:
> >
> > if (ioctl(fd, TUNSETOFFLOAD, offload) != 0) {
> > offload &= ~TUN_F_UFO;
> > if (ioctl(fd, TUNSETOFFLOAD, offload) != 0 && errno != EINVAL) {
> > fprintf(stderr, "TUNSETOFFLOAD ioctl() failed: %s\n",
> > strerror(errno));
> > }
> > }
> >
> > The only concern is that we'll also miss out on an error message if
> > EINVAL is set for another reason. Currently, the only other reason if we
> > pass a offload flag not supported by the kernel, but that should never
> > happen.
> >
> > Feel free to send a patch with that change and I'll ack it
....
>
> Couldn't we probe the kernel with a 0 offload value to check if it supports TUNSETOFFLOAD?
> I tried the following and it works on my 2.6.26 Debian kernel.
> What do you think? I will send a proper patch if you agree.
>
> diff --git a/net/tap-linux.c b/net/tap-linux.c
> index 0f621a2..e038e1a 100644
> --- a/net/tap-linux.c
> +++ b/net/tap-linux.c
> @@ -129,6 +129,11 @@ void tap_fd_set_offload(int fd, int csum, int tso4,
> {
> unsigned int offload = 0;
>
> + /* Check if our kernel supports TUNSETOFFLOAD */
> + if (ioctl(fd, TUNSETOFFLOAD, 0) != 0 && errno == EINVAL) {
> + return;
> + }
> +
It's not ideal because a) it's another syscall and b) you're briefly
disabling any flags that may have been set previously ... but in our
case, neither is a real concern and it's a nice, simple solution.
So, sounds good to me :)
Cheers,
Mark.
prev parent reply other threads:[~2009-11-25 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 9:06 [Qemu-devel] [PATCH] Fix TAP networking on host kernels without IFF_VNET_HDR support Pierre Riteau
2009-11-24 10:05 ` [Qemu-devel] [PATCH] net: initialize vnet_hdr in net_tap_init() Mark McLoughlin
2009-11-24 10:24 ` Pierre Riteau
2009-11-24 10:28 ` [Qemu-devel] Re: [PATCH] Fix TAP networking on host kernels without IFF_VNET_HDR support Mark McLoughlin
2009-11-24 11:17 ` Pierre Riteau
2009-11-24 11:22 ` Mark McLoughlin
2009-11-24 21:27 ` Pierre Riteau
2009-11-25 8:55 ` Mark McLoughlin [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=1259139355.2514.5.camel@blaa \
--to=markmc@redhat.com \
--cc=Pierre.Riteau@irisa.fr \
--cc=qemu-devel@nongnu.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.