[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 2013-10-16 0:23, jianhai luan wrote:

On 2013-10-16 0:03, Wei Liu wrote:
On Tue, Oct 15, 2013 at 11:19:42PM +0800, jianhai luan wrote:
* time_after_eq(now, next_credit) -> false
* time_before(now, expires) -> false
If now is placed in above environment, the result will be correct
(Sending package will be not allowed until next_credit).
No, it is not necessarily correct. Keep in mind that "now" wraps around, which is the issue you try to fix. You still have a window to stall your
Remember that time_after_eq is supposed to work even with wraparound
occurring, so long as the two times are less than MAX_LONG/2 apart.
Sorry for my misunderstand explanation. I mean that
   * time_after_eq()/time_before_eq() fix the jiffies wraparound, so
please think about  jiffies in line increasing.
   * time_after_eq()/time_before_eq() have the range (0, MAX_LONG/2),
the judge will be wrong if out of the range.

So please think about three kind environment
   -  expires        now        next_credit
      --------time increases this direction ---------->

   -  expires        [next_credit        now next_credit+MAX_LONG/2
      --------time increase this direction ----------->

   - expires        next_credit        next_credit+MAX_LONG/2 now
      --------time increadse this direction ---------->

The first environment should be netfront consume all credit_byte
before next_credit, So we should pending one timer to calculator the
new credit_byte, and don't transmit until next_credit.

the second environment should be calculator the credit_byte because
netfront don't consume all credit_byte before next_credit, and
time_after_eq() do correct judge.

the third environment should be calculator in time because netfront
don't consume all credit_byte until next_credit.But time_after_eq do
error judge (time_after_eq(now, next_credit) is false), so the
remaining_byte isn't be increased.

and I work on the third environment.  You know now >
next_credit+MAX_LONG/2, time_before(now, expire) should be
true(time_before(now, expire) is false in first environment)
Thanks for staighten this out for me. I'm just too dumb for this, please
be patient with me. :-)

Could you prove that time_before(now, expire) is always true in third
case? That's where my main cencern lies. Is it because msecs_to_jiffies
always returns MAX_JIFFY_OFFSET (which is ((LONG_MAX >> 1)-1) ) at most?

I have wrong judge in third environment. If now large than expires + MAX_UNLONG, time_before(now, expires) will be false. expires next_credit next_credit+MAX_UNLONG/2 expires + MAX_UNLONG now next_credit+MAX_UNLONG --------------------------------------------------------- time increadse this direction ---------------------------------->

In the above environment, time_before(now, expires) will return false. But the jiffies elapsed more time and next_credit will be reachable in soon(time_after_eq(now, next_credit) will be true).

After above talk, the window should be exist (expire+MAX_ULONG next_credit+MAX_ULONG, expire + 2MAX_ULONF next_credit+MAX_ULONG ....,expire+<n>ULONG next_credit+<n>MAX_ULONG). Other time window should be not exist (maybe i don't think about).
 If so, please think about the below:
* If no speed control, vif->credit_usec should be zero. expire = next_credit and the window is zero * If we have done speed control, the scenario should be very likely than first environment except the value is larger (the delta is <n>MAX_UNLONG)
     - If do speed control. the window should have been think about
                     speed            worse time
                     100M/s          40s
                     1000M/s       4s
     - the time should be acceptable.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.