public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: annie li <annie.li@oracle•com>
To: jianhai luan <jianhai.luan@oracle•com>
Cc: Wei Liu <wei.liu2@citrix•com>,
	xen-devel@lists•xenproject.org,
	Ian Campbell <Ian.Campbell@citrix•com>,
	netdev@vger•kernel.org
Subject: Re: [Xen-devel] DomU's network interface will hung when Dom0 running 32bit
Date: Wed, 16 Oct 2013 17:39:43 +0800	[thread overview]
Message-ID: <525E5EDF.4030904@oracle.com> (raw)
In-Reply-To: <525E41CF.7090008@oracle.com>


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
>>
>> Wei.
>>
>>> Jason
>>>> Wei.
> Jason.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists•xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2013-10-16  9:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  8:53 DomU's network interface will hung when Dom0 running 32bit jianhai luan
2013-10-14 11:19 ` Wei Liu
2013-10-15  2:44   ` jianhai luan
2013-10-15  8:43     ` Ian Campbell
2013-10-15  9:34       ` jianhai luan
2013-10-15 10:06         ` Wei Liu
2013-10-15 11:26           ` jianhai luan
2013-10-15 12:58             ` Wei Liu
2013-10-15 14:29               ` jianhai luan
2013-10-15 14:49                 ` Wei Liu
2013-10-15 14:50                   ` Ian Campbell
2013-10-15 15:19                     ` jianhai luan
2013-10-15 16:03                       ` Wei Liu
2013-10-15 16:23                         ` jianhai luan
2013-10-16  0:15                           ` jianhai luan
2013-10-16  7:35               ` jianhai luan
2013-10-16  9:39                 ` annie li [this message]
2013-10-16 13:08                   ` [Xen-devel] " jianhai luan
2013-10-16 13:47                     ` Wei Liu
2013-10-16 15:04                       ` jianhai luan
2013-10-16 15:17                         ` Wei Liu
2013-10-16 16:11                           ` David Vrabel
2013-10-16 16:44                             ` jianhai luan
2013-10-16 15:26                         ` annie li
2013-10-16  7:10       ` annie li
2013-10-16  8:46         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525E5EDF.4030904@oracle.com \
    --to=annie.li@oracle$(echo .)com \
    --cc=Ian.Campbell@citrix$(echo .)com \
    --cc=jianhai.luan@oracle$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=wei.liu2@citrix$(echo .)com \
    --cc=xen-devel@lists$(echo .)xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox