[v3,3/4] xen/interface: re-define FRONT/BACK_RING_ATTACH()
diff mbox series

Message ID 20191211152956.5168-4-pdurrant@amazon.com
State New
Headers show
Series
  • xen-blkback: support live update
Related show

Commit Message

Paul Durrant Dec. 11, 2019, 3:29 p.m. UTC
Currently these macros are defined to re-initialize a front/back ring
(respectively) to values read from the shared ring in such a way that any
requests/responses that are added to the shared ring whilst the front/back
is detached will be skipped over. This, in general, is not a desirable
semantic since most frontend implementations will eventually block waiting
for a response which would either never appear or never be processed.

Since the macros are currently unused, take this opportunity to re-define
them to re-initialize a front/back ring using specified values. This also
allows FRONT/BACK_RING_INIT() to be re-defined in terms of
FRONT/BACK_RING_ATTACH() using a specified value of 0.

NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>

A patch to add the FRONT/BACK_RING_ATTACH() macros to the canonical
ring.h in xen.git will be sent once the definitions have been agreed.

v2:
 - change definitions to take explicit initial index values
---
 include/xen/interface/io/ring.h | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

Comments

Jürgen Groß Dec. 12, 2019, 6:04 a.m. UTC | #1
On 11.12.19 16:29, Paul Durrant wrote:
> Currently these macros are defined to re-initialize a front/back ring
> (respectively) to values read from the shared ring in such a way that any
> requests/responses that are added to the shared ring whilst the front/back
> is detached will be skipped over. This, in general, is not a desirable
> semantic since most frontend implementations will eventually block waiting
> for a response which would either never appear or never be processed.
> 
> Since the macros are currently unused, take this opportunity to re-define
> them to re-initialize a front/back ring using specified values. This also
> allows FRONT/BACK_RING_INIT() to be re-defined in terms of
> FRONT/BACK_RING_ATTACH() using a specified value of 0.
> 
> NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen
Jürgen Groß Dec. 13, 2019, 8:59 a.m. UTC | #2
On 12.12.19 07:04, Jürgen Groß wrote:
> On 11.12.19 16:29, Paul Durrant wrote:
>> Currently these macros are defined to re-initialize a front/back ring
>> (respectively) to values read from the shared ring in such a way that any
>> requests/responses that are added to the shared ring whilst the 
>> front/back
>> is detached will be skipped over. This, in general, is not a desirable
>> semantic since most frontend implementations will eventually block 
>> waiting
>> for a response which would either never appear or never be processed.
>>
>> Since the macros are currently unused, take this opportunity to re-define
>> them to re-initialize a front/back ring using specified values. This also
>> allows FRONT/BACK_RING_INIT() to be re-defined in terms of
>> FRONT/BACK_RING_ATTACH() using a specified value of 0.
>>
>> NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.
>>
>> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>

Paul, I think you should send a patch changing ring.h in the Xen tree.

As soon as it has been accepted I'll take your series for the kernel.


Juergen
Paul Durrant Dec. 13, 2019, 9:02 a.m. UTC | #3
> -----Original Message-----
> From: Jürgen Groß <jgross@suse.com>
> Sent: 13 December 2019 09:00
> To: Durrant, Paul <pdurrant@amazon.com>; xen-devel@lists.xenproject.org;
> linux-block@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>; Stefano Stabellini
> <sstabellini@kernel.org>
> Subject: Re: [PATCH v3 3/4] xen/interface: re-define
> FRONT/BACK_RING_ATTACH()
> 
> On 12.12.19 07:04, Jürgen Groß wrote:
> > On 11.12.19 16:29, Paul Durrant wrote:
> >> Currently these macros are defined to re-initialize a front/back ring
> >> (respectively) to values read from the shared ring in such a way that
> any
> >> requests/responses that are added to the shared ring whilst the
> >> front/back
> >> is detached will be skipped over. This, in general, is not a desirable
> >> semantic since most frontend implementations will eventually block
> >> waiting
> >> for a response which would either never appear or never be processed.
> >>
> >> Since the macros are currently unused, take this opportunity to re-
> define
> >> them to re-initialize a front/back ring using specified values. This
> also
> >> allows FRONT/BACK_RING_INIT() to be re-defined in terms of
> >> FRONT/BACK_RING_ATTACH() using a specified value of 0.
> >>
> >> NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.
> >>
> >> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> >
> > Reviewed-by: Juergen Gross <jgross@suse.com>
> 
> Paul, I think you should send a patch changing ring.h in the Xen tree.
> 
> As soon as it has been accepted I'll take your series for the kernel.
> 

Ok. I was waiting for a push so that I could cite the commit hash but I'll prep something now instead.

  Paul

Patch
diff mbox series

diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 3f40501fc60b..2af7a1cd6658 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -125,35 +125,24 @@  struct __name##_back_ring {						\
     memset((_s)->pad, 0, sizeof((_s)->pad));				\
 } while(0)
 
-#define FRONT_RING_INIT(_r, _s, __size) do {				\
-    (_r)->req_prod_pvt = 0;						\
-    (_r)->rsp_cons = 0;							\
+#define FRONT_RING_ATTACH(_r, _s, _i, __size) do {			\
+    (_r)->req_prod_pvt = (_i);						\
+    (_r)->rsp_cons = (_i);						\
     (_r)->nr_ents = __RING_SIZE(_s, __size);				\
     (_r)->sring = (_s);							\
 } while (0)
 
-#define BACK_RING_INIT(_r, _s, __size) do {				\
-    (_r)->rsp_prod_pvt = 0;						\
-    (_r)->req_cons = 0;							\
-    (_r)->nr_ents = __RING_SIZE(_s, __size);				\
-    (_r)->sring = (_s);							\
-} while (0)
+#define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s, 0, __size)
 
-/* Initialize to existing shared indexes -- for recovery */
-#define FRONT_RING_ATTACH(_r, _s, __size) do {				\
-    (_r)->sring = (_s);							\
-    (_r)->req_prod_pvt = (_s)->req_prod;				\
-    (_r)->rsp_cons = (_s)->rsp_prod;					\
+#define BACK_RING_ATTACH(_r, _s, _i, __size) do {			\
+    (_r)->rsp_prod_pvt = (_i);						\
+    (_r)->req_cons = (_i);						\
     (_r)->nr_ents = __RING_SIZE(_s, __size);				\
-} while (0)
-
-#define BACK_RING_ATTACH(_r, _s, __size) do {				\
     (_r)->sring = (_s);							\
-    (_r)->rsp_prod_pvt = (_s)->rsp_prod;				\
-    (_r)->req_cons = (_s)->req_prod;					\
-    (_r)->nr_ents = __RING_SIZE(_s, __size);				\
 } while (0)
 
+#define BACK_RING_INIT(_r, _s, __size) BACK_RING_ATTACH(_r, _s, 0, __size)
+
 /* How big is this ring? */
 #define RING_SIZE(_r)							\
     ((_r)->nr_ents)