I have a problem with iSCSI on AMD64 Xen HVM

[Janne Snabb]

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 at epipe.com - http://epipe.com/