Date: Wed, 26 Jan 2011 01:30:56 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: luke@hybrid-logic.co.uk Cc: freebsd-xen@freebsd.org Subject: Re: I have a problem with iSCSI on AMD64 Xen HVM Message-ID: <alpine.BSF.2.00.1101260038310.20212@tiktik.epipe.com> In-Reply-To: <1295969742.3187.48.camel@pow> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Jan 2011, Luke Marsden wrote: > On Tue, 2011-01-25 at 14:35 +0000, Janne Snabb wrote: > > 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. > > In my tests commenting out that check entirely works fine. It also appears that before SVN r181945 (2008-08-21 by kmacy) "max" was 24, so it was much less likely to hit the (possibly unneeded) "if (frags > max)" check limit: > int max = 24 /* MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD) */; I do not understand from the commit message why it was changed to 5. (I wish there was a bit more comments in the non-obvious parts of the code. Now it is difficult for a FreeBSD/Xen PV newbie to work on it without intimate knowledge of the history of the odd bits of the code. It clearly needs more care than what it is being given now. Things like the "do something useful" panic also indicate that there is no more than few people who actually play with and try out the code currently.) -- 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.1101260038310.20212>