[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
On 2013-10-17 18:31, David Vrabel wrote: On 17/10/13 11:19, jianhai luan wrote:On 2013-10-17 17:15, David Vrabel wrote:On 17/10/13 10:02, jianhai luan wrote:On 2013-10-17 16:26, Jan Beulich wrote:On 16.10.13 at 19:22, Jason Luan <jianhai.luan@xxxxxxxxxx> wrote: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). We should add the scenario which now beyond next_credit+MAX_UNLONG/2. Because the fact now must be not before than expire, time_before(now, expire) == true will verify the scenario. time_after_eq(now, next_credit) || time_before (now, expire) == !time_in_range_open(now, expire, next_credit)So first of all this must be with a 32-bit netback. And the not coverable gap between activity is well over 240 days long. _If_ this really needs dealing with, then why is extending this from 240+ to 480+ days sufficient? I.e. why don't you simply change to 64-bit jiffy values, and use time_after_eq64()?Yes, the issue only can be reproduced in 32-bit Dom0 (Beyond MAX_ULONG/2 in 64-bit will need long long time) I think the gap should be think all environment even now extending 480+. if now fall in the gap, one timer will be pending and replenish will be in time. Please run the attachment test program. If use time_after_eq64(), expire ,next_credit and other member will must be u64.Yes, you'll need to store next_credit as a u64 in vif instead of calculating it in tx_credit_exceeded from expires (which is only an unsigned long).I know that. Even we use u64, time_after_eq() will also do wrong judge in theory (not in reality because need long long time).If jiffies_64 has millisecond resolution that would be more than 500,000,000 years. Yes, I agree the fact. I think the two better fixed way is below: - By time_before() to judge if now beyond MAX_ULONG/2This is broken, so no. Where is broken? would you like to help me point it out. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |