From owner-freebsd-xen@FreeBSD.ORG Tue Jan 25 14:35:55 2011 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABE21065679 for ; Tue, 25 Jan 2011 14:35:55 +0000 (UTC) (envelope-from snabb@epipe.com) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:1828:0:3::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E97E8FC16 for ; Tue, 25 Jan 2011 14:35:55 +0000 (UTC) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:1828:0:3::2]) by tiktik.epipe.com (8.14.4/8.14.4) with ESMTP id p0PEZsdI070477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 14:35:54 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com p0PEZsdI070477 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1295966154; x=1296570954; bh=mwQQ8O6U16C6R6jATQshJATCoKNfjcbwJVPu+WcfDxg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=nSjPI2EAdTvQclwl9l0gQc2+/+x230S5vcr1u0YNjtNjIpDyamhnyDddbokFwZMhR x1L+eZoOdlDUV8uaiPj2OVH5iNnypBxy5IgvertFvsjneUWeRlQA057H6kzYHSLNmV UEJAcX5NEsqQxnJhm6GKk0dAVGXjXC0hrXvaNNlU= Date: Tue, 25 Jan 2011 14:35:54 +0000 (UTC) From: Janne Snabb To: Grzegorz Rybicki In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (tiktik.epipe.com [IPv6:2001:1828:0:3::2]); Tue, 25 Jan 2011 14:35:54 +0000 (UTC) Cc: freebsd-xen@freebsd.org Subject: Re: I have a problem with iSCSI on AMD64 Xen HVM X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 14:35:55 -0000 On Mon, 24 Jan 2011, Grzegorz Rybicki wrote: > xennet_get_responses: too many frags 11 > max 5 [..] The following in sys/dev/xen/netfront/netfront.c xennet_get_responses() looks a little bit suspicious: > int max = 5 /* MAX_TX_REQ_FRAGS + (rx->status <= RX_COPY_THRESHOLD) */; ...together with the check at the end of the function (the only place where "max" is used) which produces the error message you see: > if (unlikely(frags > max)) { > if (net_ratelimit()) > WPRINTK("Too many frags\n"); > printf("%s: too many frags %d > max %d\n", __func__, frags, > max); > err = E2BIG; > } MAX_TX_REQ_FRAGS is defined as follows in the same file: > #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) ...which produces already 18. Where does this "max = 5" come from? Either "max" is wrong or I do not understand the comment on the line where it is defined. There are some interesting and probably related comments in the same file about the Linux netback driver's lacking capabilities of handling many fragments. But why do we care about that when receiving? I would guestimate that either "max" should be higher than what it currently is (5) or the check which produces the error might be unneeded. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/