From patchwork Tue Nov 24 21:27:18 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pierre Riteau X-Patchwork-Id: 39240 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 08D6B1007D1 for ; Wed, 25 Nov 2009 08:28:01 +1100 (EST) Received: from localhost ([127.0.0.1]:55752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND2vV-00029Y-Vg for incoming@patchwork.ozlabs.org; Tue, 24 Nov 2009 16:27:57 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND2v1-000282-Dq for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:27:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND2uw-00022r-Ct for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:27:26 -0500 Received: from [199.232.76.173] (port=55241 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND2uw-00022i-7f for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:27:22 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:25652) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1ND2uv-0000xS-OA for qemu-devel@nongnu.org; Tue, 24 Nov 2009 16:27:22 -0500 X-IronPort-AV: E=Sophos;i="4.47,281,1257116400"; d="scan'208";a="38690850" Received: from cse35-1-82-236-142-224.fbx.proxad.net (HELO [192.168.0.15]) ([82.236.142.224]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 24 Nov 2009 22:27:19 +0100 Subject: Re: [Qemu-devel] Re: [PATCH] Fix TAP networking on host kernels without IFF_VNET_HDR support Mime-Version: 1.0 (Apple Message framework v1077) From: Pierre Riteau In-Reply-To: <1259061772.8935.29.camel@blaa> Date: Tue, 24 Nov 2009 22:27:18 +0100 Message-Id: <14A83280-2A2D-4DCC-BD75-5DB6B43883EB@irisa.fr> References: <1259053593-15362-1-git-send-email-Pierre.Riteau@irisa.fr> <1259058521.8935.21.camel@blaa> <1259061772.8935.29.camel@blaa> To: Mark McLoughlin X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Cc: qemu-devel@nongnu.org X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 24 nov. 2009, at 12:22, Mark McLoughlin wrote: > On Tue, 2009-11-24 at 12:17 +0100, Pierre Riteau wrote: >> On 24 nov. 2009, at 11:28, Mark McLoughlin wrote: >> >>> On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote: >>>> vnet_hdr is initialized at 1 by default. We need to reset it to 0 if >>>> the kernel doesn't support IFF_VNET_HDR. >>>> >>>> Signed-off-by: Pierre Riteau >>> >>> Thanks Pierre, I see why this is needed now >>> >>> Acked-by: Mark McLoughlin >>> >>> Cheers, >>> Mark. >> >> >> Thanks for your rapid answer! >> >> BTW, every time I run qemu I see this error message: >> >> TUNSETOFFLOAD ioctl() failed: Invalid argument >> >> It is caused by the piece of code at the end of net/tap-linux.c: >> >> if (ioctl(fd, TUNSETOFFLOAD, offload) != 0) { >> offload &= ~TUN_F_UFO; >> if (ioctl(fd, TUNSETOFFLOAD, offload) != 0) { >> fprintf(stderr, "TUNSETOFFLOAD ioctl() failed: %s\n", >> strerror(errno)); >> } >> } >> >> 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 > > Thanks, > Mark. > 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; + } + if (csum) { offload |= TUN_F_CSUM; if (tso4)