From owner-freebsd-xen@FreeBSD.ORG Fri Jan 28 04:24:20 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 4BD50106564A for ; Fri, 28 Jan 2011 04:24:20 +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 0C5B28FC0A for ; Fri, 28 Jan 2011 04:24:19 +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 p0S4OIbZ017315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 04:24:18 GMT (envelope-from snabb@epipe.com) X-DKIM: Sendmail DKIM Filter v2.8.3 tiktik.epipe.com p0S4OIbZ017315 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=epipe.com; s=default; t=1296188659; x=1296793459; bh=x+rr38jE5QcPp+ev5uTx8jT2/Kfxbsaq4ZV9v+r1Uck=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=ZSn99QbQsYmDxeI+kWz0UF284WtuHEYgbGRpjZHTdT9LuSZBMTSiMSYfxG/AAk+9A z/bRy6Izh/SRXJvNmkp8YFn5t6Is4L1gv3nMqVeaWx8UwNh5WFDG0JB+/hD9YlLfkH yssUGBe9w5jpg2Bblw7a6cRCZQfRfKA877psX2Tw= Date: Fri, 28 Jan 2011 04:24:18 +0000 (UTC) From: Janne Snabb To: Carsten Heesch In-Reply-To: <0F524D72-3752-47FD-9234-ED009009B0A0@ossafe.org> Message-ID: References: <1295969742.3187.48.camel@pow> <0F524D72-3752-47FD-9234-ED009009B0A0@ossafe.org> 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]); Fri, 28 Jan 2011 04:24:19 +0000 (UTC) Cc: freebsd-xen@freebsd.org, luke@hybrid-logic.co.uk 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: Fri, 28 Jan 2011 04:24:20 -0000 On Thu, 27 Jan 2011, Carsten Heesch wrote: > >> int max = 24 /* MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD) */; > > I've just recompiled XENHVM setting this for a quick test: > > > int max = MAX_SKB_FRAGS; > > Before, I was receiving said error message a lot; now it's gone. > Also, throughput has massively increased! Good :). > Which would be the right value for max? This was obviously only > a quick, dirty test. I haven't got a clue either, where the max=5 > came from, but it doesn't seem to be a reasonable value. Could you, Luke or Grzegorz send-pr this, and include the following links in the PR? Evidence of several people having this problem and that the problem is indeed caused by incorrect "max" value or the "if (frags > max)" check: http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000779.html http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000783.html http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000784.html Some analysis of the relevant code by myself: http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000782.html http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000784.html It looks like all the FreeBSD Xen gurus/committers are busy/quiet currently. It would be good to have a PR on this so that someone who understands this "max" thing could have a look at it at some point even if they do not notice this discussion on this mailing list. The solution is likely to be simple, but it should be made/verified by someone who understands the code and its history. (Removing the "if (frags > max)" check altogether might be the correct solution, but it could also cause panics or other issues under heavy network load in case it is actually something that is needed.) PS. I think the 8.2 release is waiting for Xen fixes before being released. I think the release will not be as good as it could be on Xen. We are a bit late in the release cycle spotting all these problems... probably not enough time to correctly fix all of them given that some of the relevant people are currently busy/inactive. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/