On 5/4/2017 5:07 PM, Scott Wood wrote:=0A=

On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote:=0A=

quoted

+	stop =3D jiffies + 10000;=0A=
+	/*=0A=
+	 * if MR was full and h/w had other FQRNI entries to produce, we=0A=
+	 * need to allow it time to produce those entries once the=0A=
+	 * existing entries are consumed. A worst-case situation=0A=
+	 * (fully-loaded system) means h/w sequencers may have to do 3-4=0A=
+	 * other things before servicing the portal's MR pump, each of=0A=
+	 * which (if slow) may take ~50 qman cycles (which is ~200=0A=
+	 * processor cycles). So rounding up and then multiplying this=0A=
+	 * worst-case estimate by a factor of 10, just to be=0A=
+	 * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume=0A=
+	 * one entry at a time, so h/w has an opportunity to produce new=0A=
+	 * entries well before the ring has been fully consumed, so=0A=
+	 * we're being *really* paranoid here.=0A=
+	 */=0A=

OK, upon reading this more closely it seems the intent was to delay for 1=

0,000=0A=

*processor cycles* and somehow that got turned into 10,000 jiffies (which=

 is=0A=

40 seconds at the default Hz!).  We could just replace this whole thing w=

ith=0A=

msleep(1) and still be far more paranoid than was originally intended.=0A=
=0A=
Claudiu and Roy, any comments?=0A=

Yes the timing here is certainly off, the code changed a few times since=0A=
the comment was originally written.=0A=
An msleep(1) seems reasonable here to me.=0A=
=0A=
Roy=0A=

=0A=
-Scott=0A=
=0A=
=0A=

=0A=