Date: Fri, 28 Jan 2011 04:24:18 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: Carsten Heesch <sysconfig@ossafe.org> Cc: freebsd-xen@freebsd.org, luke@hybrid-logic.co.uk Subject: Re: I have a problem with iSCSI on AMD64 Xen HVM Message-ID: <alpine.BSF.2.00.1101280348410.20212@tiktik.epipe.com> In-Reply-To: <0F524D72-3752-47FD-9234-ED009009B0A0@ossafe.org> References: <AANLkTink37iAtMeNZ5NEhgKwPFOgXOVr4epSFxp=7Kmr@mail.gmail.com> <AANLkTink=S9WxJCVT%2BAOaMjiLPLg9gtSwF1VwdzexFG%2B@mail.gmail.com> <alpine.BSF.2.00.1101251425320.20212@tiktik.epipe.com> <1295969742.3187.48.camel@pow> <alpine.BSF.2.00.1101260038310.20212@tiktik.epipe.com> <0F524D72-3752-47FD-9234-ED009009B0A0@ossafe.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101280348410.20212>