mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] Persistent grant maps for xen blk drivers
Date: Tue, 23 Oct 2012 20:09:27 +0200	[thread overview]
Message-ID: <5086DD57.4000206@citrix.com> (raw)
In-Reply-To: <20121023172008.GB11787@phenom.dumpdata.com>

On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
>>>> index c6decb9..2b982b2 100644
>>>> --- a/drivers/block/xen-blkback/blkback.c
>>>> +++ b/drivers/block/xen-blkback/blkback.c
>>>> @@ -78,6 +78,7 @@ struct pending_req {
>>>>       unsigned short          operation;
>>>>       int                     status;
>>>>       struct list_head        free_list;
>>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];

Should I change this to a bool? Since we are only setting it to 0 or 1.

>>> Perhaps there should be a #define for that array..
>>
>> Do you mean something like:
>>
>> #define unmap(req, i) req->unmap_seg[i]
> 
> I was thinking that you just check for req->unamp_seg[i] to
> have an non-zero value. But since that array is just used as an check
> to see whether the functionality is enabled (or not), you might want
> to declerare the right values so:
> #define UNMAP_SG_ON 1
> #define UNMAP_SG_OFF 0
> 
> or so.

Agreed, will add the defines.

>>>> +             if (persistent_gnts[i]) {
>>>> +                     if (!persistent_gnts[i]->handle) {
>>>> +                             /*
>>>> +                              * If this is a new persistent grant
>>>> +                              * save the handler
>>>> +                              */
>>>> +                             persistent_gnts[i]->handle = map[j].handle;
>>>> +                             persistent_gnts[i]->dev_bus_addr =
>>>> +                                     map[j++].dev_bus_addr;
>>>> +                     }
>>>> +                     pending_handle(pending_req, i) =
>>>> +                             persistent_gnts[i]->handle;
>>>> +                     pending_req->unmap_seg[i] = 0;
>>>
>>> Could we have a #define for that?
>>
>> Sure.

I've used the previous macro, so it looks like:

unmap(req, i) = UNMAP_SG_OFF;

I'm not sure if this is what you meant, or if you where interested in
defining a set of macros like:

#define check_unmap(req, i) req->unmap_seg[i]
#define unset_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_OFF
#define set_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_ON

I would go for the first option (the unmap macro that can be used here
and in xen_blkbk_unmap).

>>> HA! By default, eh?
>>
>> Yes, you caught me, there's a paragraph in the commit message that
>> explains that we are using persistent grants in the frontend
>> unconditionally, since the protocol is compatible (you can have a
>> persistent blkfront and a non-persistent blkback). It simplifies the
>> logic in blkfront. Are you OK with it?
> 
> It is OK, but you should be checking whether the backend supports it.
> I don't see it checking the info->feature_persistent_grant to print
> that.

I don't understand why blkfront needs to check if the backend supports
persisten grants, blkfront is going to use persistent grants anyway.


  reply	other threads:[~2012-10-23 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 11:22 Roger Pau Monne
2012-10-19  1:34 ` [Xen-devel] " James Harper
2012-10-19  8:26   ` Roger Pau Monné
2012-10-22 13:47 ` Konrad Rzeszutek Wilk
2012-10-23 16:07   ` Roger Pau Monné
2012-10-23 17:20     ` Konrad Rzeszutek Wilk
2012-10-23 18:09       ` Roger Pau Monné [this message]
2012-10-23 18:50         ` [Xen-devel] " Konrad Rzeszutek Wilk
2012-10-24  7:40           ` Jan Beulich
2012-10-25 12:40             ` Konrad Rzeszutek Wilk
2012-10-24 10:45           ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5086DD57.4000206@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=konrad@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome