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

[Xen-devel] ring.h notification hold-off question


  • To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Daniel Stodden <stodden@xxxxxxxxxx>
  • Date: Sat, 10 Nov 2007 06:37:47 +0100
  • Delivery-date: Fri, 09 Nov 2007 21:38:34 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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


 


Rackspace

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