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.
next prev parent 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