Re: [Xen-devel] VT-d flush timeout

["Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>]

I think the point is that the current code is incorrect In all cases.  
Currently we have a 1 second timeout which is too long (by a factor of 100) for 
the non-ACS case and is too short (by a factor of 60 according to the PCI SIG 
spec) for the ACS case.

Given that a 10 msec timeout is sufficient for the non-ACS case we should make 
the simple change to the current timeout to change it to 10 msec while we work 
on creating a more complex solution for the 60 second wait required for the ACS 
case.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Zhang, Yang Z 
Sent: Friday, August 22, 2014 2:06 AM
To: Jan Beulich
Cc: andrew.cooper3@xxxxxxxxxx; Dugger, Donald D; Tian, Kevin; Li, LiangX Z; 
xen-devel@xxxxxxxxxxxxx
Subject: RE: RE: VT-d flush timeout

Jan Beulich wrote on 2014-08-22:
>>>> On 22.08.14 at 09:49, <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-08-22:
>>>>>> On 21.08.14 at 05:16, <yang.z.zhang@xxxxxxxxx> wrote:
>>>> Jan Beulich wrote on 2014-08-19:
>>>>>>>> "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> 08/19/14 3:34 AM >>>
>>>>>> My only concern is that, for QI flush, the spin time relies on 
>>>>>> the length of the queue. I am not sure whether 1s is enough for 
>>>>>> worst case and I think we should remove the 1s in QI flush. And I 
>>>>>> think this also the same reason for Linux don't use timeout 
>>>>>> mechanism in QI
>>> flush.
>>>>> 
>>>>> First of all I think both Linux and Xen in the majority of cases 
>>>>> waits for completion of just individual queue entries. I.e. I'm 
>>>>> not sure if the practical worst case really is equal to the 
>>>>> theoretical one. And
>>>> 
>>>> This is my guessing from Linux's implementation but may wrong.
>>> 
>>> Which is why we ask for you (the VT-d maintainer) to, as a first 
>>> step, supply a patch limiting the spinning time to a value smaller 
>>> than the current on, just enough to cover real requirements. The 
>>> second step
>> 
>> This doesn't answer my question. I still don't see why a smaller 
>> value helps.
> 
> Because it reduces the impact the currently large value would have in 
> misbehaving cases? Don clearly indicated to me that it shouldn't be a 
> big deal to reduce the current timeout, so I really don't see what all 
> this argument is about.

I am not arguing. Since I am not in your meeting, so I don't know the 
background of the decision and I hope someone can answer my question.

> 
> Jan


Best regards,
Yang



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