[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <525EBABB.4070906@citrix.com>
Date: Wed, 16 Oct 2013 17:11:39 +0100
From: David Vrabel <david.vrabel@...rix.com>
To: Wei Liu <wei.liu2@...rix.com>
CC: jianhai luan <jianhai.luan@...cle.com>,
<xen-devel@...ts.xenproject.org>, annie li <annie.li@...cle.com>,
Ian Campbell <Ian.Campbell@...rix.com>,
<netdev@...r.kernel.org>
Subject: Re: [Xen-devel] DomU's network interface will hung when Dom0 running
32bit
On 16/10/13 16:17, Wei Liu wrote:
> On Wed, Oct 16, 2013 at 11:04:34PM +0800, jianhai luan wrote:
> [...]
>> >From ef02403a10173896c5c102f768741d0700b8a3a2 Mon Sep 17 00:00:00 2001
>> From: Jason Luan <jianhai.luan@...cle.com>
>> Date: Tue, 15 Oct 2013 17:07:49 +0800
>> Subject: [PATCH] xen-netback: pending timer only in the range [expire,
>> next_credit)
>>
>> The function time_after_eq() do correct judge in range of MAX_UNLONG/2.
>> If net-front send lesser package, the delta between now and next_credit
>> will out of the range and time_after_eq() will do wrong judge in result
>> to net-front hung. For example:
>> expire next_credit .... next_credit+MAX_UNLONG/2 now
>> -----------------time increases this direction----------------->
>>
>> We should be add the environment which now beyond next_credit+MAX_UNLONG/2.
>> Because the fact now mustn't before expire, time_before(now, expire) == true
>> will show the environment.
>> time_after_eq(now, next_credit) || time_before (now, expire)
>> ==
>> !time_in_range_open(now, expire, next_credit)
>>
I would like the description improved because it's too hard to understand.
How about something like:
"time_after_eq() only works if the delta is < MAX_ULONG/2.
If netfront sends at a very low rate, the time between subsequent calls
to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for
timer_after_eq() will be incorrect. Credit will not be replenished and
the guest may become unable to send (e.g., if prior to the long gap, all
credit was exhausted)."
But that's as far as I get because I can't see how the fix is correct.
The time_in_range() test might still return the wrong value if now has
advanced even further and wrapped so it is between expire and
next_credit again.
I think the credit timeout should be always armed to expire in
MAX_ULONG/4 jiffies (or some other large value). If credit is exceeded,
this timer is then adjusted to fire earlier (at next_credit as it does
already).
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists