blkback feature announcement

blkback feature announcement

[Jan Beulich]

Hello,

is there a particular reason why "max-ring-page-order" gets written in
xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
"feature-persistent" get written only in connect(), despite both having
constant values (and hence the node value effectively being known as
soon as the device exists)?

Or in more general terms: Shouldn't it be well defined at what time
a frontend can rely on certain nodes to be available for inspection?
And in doing so, I'd expect the determination to be done such that
widest flexibility is provided towards the actual implementation, i.e.
nodes should be written as early as possible. (Of course this applies
to other frontend/backend pairs too.)

Thanks, Jan

Re: blkback feature announcement

[Roger Pau Monné]

El 07/12/15 a les 13.00, Jan Beulich ha escrit:
> Hello,
> 
> is there a particular reason why "max-ring-page-order" gets written in
> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
> "feature-persistent" get written only in connect(), despite both having
> constant values (and hence the node value effectively being known as
> soon as the device exists)?

No, AFAIK there's no specific reason.

> Or in more general terms: Shouldn't it be well defined at what time
> a frontend can rely on certain nodes to be available for inspection?
> And in doing so, I'd expect the determination to be done such that
> widest flexibility is provided towards the actual implementation, i.e.
> nodes should be written as early as possible. (Of course this applies
> to other frontend/backend pairs too.)

I agree. Regarding blkback the nodes about persistent grants, indirect
descriptors and the ring page order should be written in
xen_blkbk_probe, while the specific information about this virtual disk
(sectors, sector size...) should be written before switching to the
connected state (ie: after hotplug scripts have run).

Roger.

Re: blkback feature announcement

[Konrad Rzeszutek Wilk]

On Mon, Dec 07, 2015 at 01:42:09PM +0100, Roger Pau Monné wrote:
> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
> > Hello,

Ccing Bob.
> > 
> > is there a particular reason why "max-ring-page-order" gets written in
> > xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
> > "feature-persistent" get written only in connect(), despite both having
> > constant values (and hence the node value effectively being known as
> > soon as the device exists)?
> 
> No, AFAIK there's no specific reason.
> 
> > Or in more general terms: Shouldn't it be well defined at what time
> > a frontend can rely on certain nodes to be available for inspection?
> > And in doing so, I'd expect the determination to be done such that
> > widest flexibility is provided towards the actual implementation, i.e.
> > nodes should be written as early as possible. (Of course this applies
> > to other frontend/backend pairs too.)
> 
> I agree. Regarding blkback the nodes about persistent grants, indirect
> descriptors and the ring page order should be written in
> xen_blkbk_probe, while the specific information about this virtual disk
> (sectors, sector size...) should be written before switching to the
> connected state (ie: after hotplug scripts have run).
> 
> Roger.
> 

Re: blkback feature announcement

[Bob Liu]

On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>> Hello,
>>
>> is there a particular reason why "max-ring-page-order" gets written in
>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>> "feature-persistent" get written only in connect(), despite both having
>> constant values (and hence the node value effectively being known as
>> soon as the device exists)?
> 
> No, AFAIK there's no specific reason.
> 

AFAIR, that's for the blkfront resume path.

We need to get the "max-ring-page-order" in blkfront_resume() in advance, so that we can know how many ring pages to be used before setup_blkring().

Bob.

>> Or in more general terms: Shouldn't it be well defined at what time
>> a frontend can rely on certain nodes to be available for inspection?
>> And in doing so, I'd expect the determination to be done such that
>> widest flexibility is provided towards the actual implementation, i.e.
>> nodes should be written as early as possible. (Of course this applies
>> to other frontend/backend pairs too.)
> 
> I agree. Regarding blkback the nodes about persistent grants, indirect
> descriptors and the ring page order should be written in
> xen_blkbk_probe, while the specific information about this virtual disk
> (sectors, sector size...) should be written before switching to the
> connected state (ie: after hotplug scripts have run).
> 
> Roger.
> 

Re: blkback feature announcement

[Jan Beulich]

>>> On 08.12.15 at 02:08, <bob.liu@oracle.com> wrote:
> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>>> Hello,
>>>
>>> is there a particular reason why "max-ring-page-order" gets written in
>>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>>> "feature-persistent" get written only in connect(), despite both having
>>> constant values (and hence the node value effectively being known as
>>> soon as the device exists)?
>> 
>> No, AFAIK there's no specific reason.
>> 
> 
> AFAIR, that's for the blkfront resume path.
> 
> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
> that we can know how many ring pages to be used before setup_blkring().

I don't follow - the proposal is to have the backend announce the
feature _earlier_, so how could frontend resume be affected?

Jan

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

Re: blkback feature announcement

[Bob Liu]

On 12/08/2015 04:13 PM, Jan Beulich wrote:
>>>> On 08.12.15 at 02:08, <bob.liu@oracle.com> wrote:
>> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>>>> Hello,
>>>>
>>>> is there a particular reason why "max-ring-page-order" gets written in
>>>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>>>> "feature-persistent" get written only in connect(), despite both having
>>>> constant values (and hence the node value effectively being known as
>>>> soon as the device exists)?
>>>
>>> No, AFAIK there's no specific reason.
>>>
>>
>> AFAIR, that's for the blkfront resume path.
>>
>> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
>> that we can know how many ring pages to be used before setup_blkring().
> 
> I don't follow - the proposal is to have the backend announce the
> feature _earlier_, so how could frontend resume be affected?
> 

The frontend resume is like this:

blkfront_resume()
     > blkif_free()
     > talk_to_blkback()
         > setup_blkring() etc.

blkback_changed()
     > blkfront_connect()


Sometimes the "max-ring-page-order" of backend may have changed after the guest(frontend) migrated to a different machine,
the frontend must aware of this change so that have to get the new value of "max-ring-page-order" in blkfront_resume().

But it would be too late if the backend announces the "max-ring-page-order" in connect(), this situation is like:

blkfront_resume()
     > blkif_free()
     > talk_to_blkback()
	 ^^^ Get a wrong "max-ring-page-order"
         > setup_blkring() etc. but using the wrong value!!

blkback_changed()
     > blkfront_connect()
       ^^^ Then the connect() in backend will be called(after frontend enter XenbusStateConnected) and write the correct "max-ring-page-order", but it's too late.

Bob

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

Re: blkback feature announcement

[Jan Beulich]

>>> On 08.12.15 at 12:06, <bob.liu@oracle.com> wrote:

> On 12/08/2015 04:13 PM, Jan Beulich wrote:
>>>>> On 08.12.15 at 02:08, <bob.liu@oracle.com> wrote:
>>> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>>>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>>>>> Hello,
>>>>>
>>>>> is there a particular reason why "max-ring-page-order" gets written in
>>>>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>>>>> "feature-persistent" get written only in connect(), despite both having
>>>>> constant values (and hence the node value effectively being known as
>>>>> soon as the device exists)?
>>>>
>>>> No, AFAIK there's no specific reason.
>>>>
>>>
>>> AFAIR, that's for the blkfront resume path.
>>>
>>> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
> 
>>> that we can know how many ring pages to be used before setup_blkring().
>> 
>> I don't follow - the proposal is to have the backend announce the
>> feature _earlier_, so how could frontend resume be affected?
>> 
> 
> The frontend resume is like this:
> 
> blkfront_resume()
>      > blkif_free()
>      > talk_to_blkback()
>          > setup_blkring() etc.
> 
> blkback_changed()
>      > blkfront_connect()
> 
> 
> Sometimes the "max-ring-page-order" of backend may have changed after the 
> guest(frontend) migrated to a different machine,
> the frontend must aware of this change so that have to get the new value of 
> "max-ring-page-order" in blkfront_resume().
> 
> But it would be too late if the backend announces the "max-ring-page-order" 
> in connect(), this situation is like:
> 
> blkfront_resume()
>      > blkif_free()
>      > talk_to_blkback()
> 	 ^^^ Get a wrong "max-ring-page-order"
>          > setup_blkring() etc. but using the wrong value!!
> 
> blkback_changed()
>      > blkfront_connect()
>        ^^^ Then the connect() in backend will be called(after frontend enter 
> XenbusStateConnected) and write the correct "max-ring-page-order", but it's 
> too late.

Oh, you're arguing for why "max-ring-page-order" is written early,
but the question really was why others aren't written early too.

Jan

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

Re: blkback feature announcement

[Bob Liu]

On 12/08/2015 07:13 PM, Jan Beulich wrote:
>>>> On 08.12.15 at 12:06, <bob.liu@oracle.com> wrote:
> 
>> On 12/08/2015 04:13 PM, Jan Beulich wrote:
>>>>>> On 08.12.15 at 02:08, <bob.liu@oracle.com> wrote:
>>>> On 12/07/2015 08:42 PM, Roger Pau Monné wrote:
>>>>> El 07/12/15 a les 13.00, Jan Beulich ha escrit:
>>>>>> Hello,
>>>>>>
>>>>>> is there a particular reason why "max-ring-page-order" gets written in
>>>>>> xen_blkbk_probe(), but e.g. "feature-max-indirect-segments" and
>>>>>> "feature-persistent" get written only in connect(), despite both having
>>>>>> constant values (and hence the node value effectively being known as
>>>>>> soon as the device exists)?
>>>>>
>>>>> No, AFAIK there's no specific reason.
>>>>>
>>>>
>>>> AFAIR, that's for the blkfront resume path.
>>>>
>>>> We need to get the "max-ring-page-order" in blkfront_resume() in advance, so 
>>
>>>> that we can know how many ring pages to be used before setup_blkring().
>>>
>>> I don't follow - the proposal is to have the backend announce the
>>> feature _earlier_, so how could frontend resume be affected?
>>>
>>
>> The frontend resume is like this:
>>
>> blkfront_resume()
>>      > blkif_free()
>>      > talk_to_blkback()
>>          > setup_blkring() etc.
>>
>> blkback_changed()
>>      > blkfront_connect()
>>
>>
>> Sometimes the "max-ring-page-order" of backend may have changed after the 
>> guest(frontend) migrated to a different machine,
>> the frontend must aware of this change so that have to get the new value of 
>> "max-ring-page-order" in blkfront_resume().
>>
>> But it would be too late if the backend announces the "max-ring-page-order" 
>> in connect(), this situation is like:
>>
>> blkfront_resume()
>>      > blkif_free()
>>      > talk_to_blkback()
>> 	 ^^^ Get a wrong "max-ring-page-order"
>>          > setup_blkring() etc. but using the wrong value!!
>>
>> blkback_changed()
>>      > blkfront_connect()
>>        ^^^ Then the connect() in backend will be called(after frontend enter 
>> XenbusStateConnected) and write the correct "max-ring-page-order", but it's 
>> too late.
> 
> Oh, you're arguing for why "max-ring-page-order" is written early,
> but the question really was why others aren't written early too.
> 

Oh, sorry for misunderstood your point.
Yes, I agree that others can be written early too.

-- 
Regards,
-Bob

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