Re: [Xen-devel] DomU's network interface will hung when Dom0 running 32bit

[jianhai luan <jianhai.luan@xxxxxxxxxx>]

On 2013-10-16 17:39, annie li wrote:
> On 2013-10-16 15:35, jianhai luan wrote:
> > On 2013-10-15 20:58, Wei Liu wrote:
> > > On Tue, Oct 15, 2013 at 07:26:31PM +0800, jianhai luan wrote:
> > > [...]
> > > > > > > Can you propose a patch?
> > > > > > Because credit_timeout.expire always after jiffies, i judge the
> > > > > > value over the range of time_after_eq() by time_before(now,
> > > > > > vif->credit_timeout.expires). please check the patch.
> > > > > I don't think this really fix the issue for you. You still have 
> > > > > chance
> > > > > that now wraps around and falls between expires and next_credit. 
> > > > > In that
> > > > > case it's stalled again.
> > > > if time_before(now, vif->credit_timeout.expires) is true, time wrap
> > > > and do operation. Otherwise time_before(now,
> > > > vif->credit_timeout.expires) isn't true, now -
> > > > vif->credit_timeout.expires should be letter than ULONG_MAX/2.
> > > > Because next_credit large than vif->credit_timeout.expires
> > > > (next_crdit = vif->credit_timeout.expires +
> > > > msecs_to_jiffies(vif->credit_usec/1000)), the delta between now and
> > > > next_credit should be in range of time_after_eq().  So
> > > > time_after_eq() do correctly judge.
> > > Not sure I understand you. Consider "now" is placed like this:
> > >
> > >     expires   now   next_credit
> > >     ----time increases this direction--->
> > >
> > > * time_after_eq(now, next_credit) -> false
> > > * time_before(now, expires) -> false
> > >
> > > Then it's stuck again. You're merely narrowing the window, not fixing
> > > the real problem.
> > The above environment isn't stack again. The netback will pending one 
> > timer to process the environment.
> > The attachment program will prove if !(time_after_eq(now, 
> > next_credit) || time_before(now, vif->credit_timeout.expires)), now 
> > will only be placed in above environment [ expires next_credit),  and 
> > the above environment will be processed by timer in soon.
> Or check following to see what the if condition really do,
>
> ----------expires-------now-------credit----------    is the only case 
> where we need to add a timer.
> Other cases like following would match the if condition above, then no 
> timer is added.
> ----------expires----------credit------now------
> -----now-----expires----------credit----------
>
> Or we can consider the extreme condition, when the rate control does 
> not exist, "credit_usec" is zero, and "next_credit" is equal to 
> "expires". The above if condition would cover all conditions, and no 
> rate control really happens. If credit_usec is not zero, the "if 
> condition" would cover the range outside of that from expires to 
> next_credit.
> Even if "now" is wrapped again into the range from "expires" to 
> "next_credit", the "next_credit" that is set in __mod_timer is 
> reasonable value(this can be gotten from credit_usec), and the timer 
> would be hit soon.
Thanks Annie's express, my option is consistent with Annie.

Jason
> Thanks
> Annie
> > > Wei.
> > >
> > > > Jason
> > > > > Wei.
> > Jason.
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel