Xen devel - Nov 2007 - ring.h notification hold-off question

hi.

trying to understand the idea behind _notify in

#define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {         \
  RING_IDX __old = (_r)->sring->req_prod;                             \
  RING_IDX __new = (_r)->req_prod_pvt;                                \
  wmb(); /* back sees requests /before/ updated producer index */     \
  (_r)->sring->req_prod = __new;                                      \
  mb(); /* back sees new requests /before/ we check req_event */      \
  (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <           \
               (RING_IDX)(__new - __old));                            \
} while (0)

questions are regarding wrapping the ring indexes.

a) to make sure: ring idx integer-wraps do happen, right?
   asking because the only mask operations i can find are those
   in the GET_REQUEST/RESPONSE macros.

b) if __old were UINT_MAX, then the consumer side might/would
   set req_event to 0 after catching up right? (req_cons(== req_prod)+1)
   now assume __new  ==  __old + 2 then we had

	req_event [0] < __new [1] < __old [INT_MAX]

   i.e.
	 __new - req_event [1] > __new - __old [-1]

   i.e. _notify=false, which i believe skips a wanted notification.

c)
  the case

	__old < __new < req_event

  (no wraps) would always notify. this somewhere contradicts 
  the statement
  in ring.h regarding opportunities to customise FINAL_CHECK for
  for larger-than-one batches.

if i''m wrong, then can anybode enlighten me, please?

thanks for patience,
daniel


-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 2007-11-10 at 06:37 +0100, Daniel Stodden wrote:
> req_event [0] < __new [1] < __old [INT_MAX]
> 
>    i.e.
> 	 __new - req_event [1] > __new - __old [-1]
uh, pardon, the -1 is wrong. but the rest i believe holds.
						
-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/11/07 05:37, "Daniel Stodden" <stodden@cs.tum.edu> wrote:
> b) if __old were UINT_MAX, then the consumer side might/would
>    set req_event to 0 after catching up right? (req_cons(== req_prod)+1)
>    now assume __new  ==  __old + 2 then we had
> 
> req_event [0] < __new [1] < __old [INT_MAX]
> 
>    i.e.
> __new - req_event [1] > __new - __old [-1]
> 
>    i.e. _notify=false, which i believe skips a wanted notification.
No. req_event==0, new==1, old==UINT_MAX. Then new-req_event==1, new-old==2.
Hence a notification will be sent.

Case (c) you are also wrong because after the subtractions we cast to an
unsigned integer. Hence in the case old<new<req_event, new-req_event will
be
a large +ve integer, not a small -ve one.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 2007-11-10 at 09:40 +0000, Keir Fraser wrote:
> i.e. _notify=false, which i believe skips a wanted notification.
> 
> No. req_event==0, new==1, old==UINT_MAX. Then new-req_event==1, new-old==2.
> Hence a notification will be sent.
unsigned. omygod. %}
> Case (c) you are also wrong because after the subtractions we cast to an
> unsigned integer. Hence in the case old<new<req_event, new-req_event
will be
> a large +ve integer, not a small -ve one.
makes all sense then.

sorry and thanks for the patience.

regards,
daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel