All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [xs-devel] blktap3 / tapdisk3 development
       [not found] <20141001181023.GG12451@reaktio.net>
@ 2014-10-02  8:41 ` Thanos Makatos
       [not found] ` <2368A3FCF9F7214298E53C823B0A48EC0420E2DD@AMSPEX01CL02.citrite.net>
  1 sibling, 0 replies; 3+ messages in thread
From: Thanos Makatos @ 2014-10-02  8:41 UTC (permalink / raw)
  To: xs-devel; +Cc: xen-devel, s.munaut

> It seems upcoming XenServer 6.5 "Creedence" is going to use blktap3 /
> tapdisk3 after all, so if i understand this correctly blktap3 is being developed
> "only for XenServer", right?

Correct, although it shouldn't be too much work for making it work on upstream Xen.

> Many interested persons have been asking on mailing lists and on IRC about
> the status of blktap3 development.
> Is it possible for someone from Citrix/XenServer to comment about this?
> 
> I know there's a blog post about blktap3/tapdisk3 performance
> (improvements) here:
> http://xenserver.org/blog/entry/tapdisk3
> 
> One of the interested developers is CC'd on this email. He has written
> RBD/Ceph support patch for blktap2, and he's interested in porting that to
> blktap3/tapdisk3..
> 
> Also is this the correct repo with latest blktap3/tapdisk3 bits in it?:
> https://github.com/xapi-project/blktap

blktap3 is actively developed and is the I/O default data path in XenServer 6.5. The repo you mention is the right one (https://github.com/xapi-project/blktap, git branch "xs64bit", but we'll soon bring the "master" branch up to date. I'd be more than happy to assist you and the developer in porting that patch to blktap3!

Cheers

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [xs-devel] blktap3 / tapdisk3 development
       [not found] ` <2368A3FCF9F7214298E53C823B0A48EC0420E2DD@AMSPEX01CL02.citrite.net>
@ 2014-10-02  9:23   ` Fabio Fantoni
  2014-10-02 15:17     ` Felipe Franciosi
  0 siblings, 1 reply; 3+ messages in thread
From: Fabio Fantoni @ 2014-10-02  9:23 UTC (permalink / raw)
  To: Thanos Makatos, xs-devel; +Cc: xen-devel, s.munaut

Il 02/10/2014 10:41, Thanos Makatos ha scritto:
>> It seems upcoming XenServer 6.5 "Creedence" is going to use blktap3 /
>> tapdisk3 after all, so if i understand this correctly blktap3 is being developed
>> "only for XenServer", right?
> Correct, although it shouldn't be too much work for making it work on upstream Xen.
>
>> Many interested persons have been asking on mailing lists and on IRC about
>> the status of blktap3 development.
>> Is it possible for someone from Citrix/XenServer to comment about this?
>>
>> I know there's a blog post about blktap3/tapdisk3 performance
>> (improvements) here:
>> http://xenserver.org/blog/entry/tapdisk3
>>
>> One of the interested developers is CC'd on this email. He has written
>> RBD/Ceph support patch for blktap2, and he's interested in porting that to
>> blktap3/tapdisk3..
>>
>> Also is this the correct repo with latest blktap3/tapdisk3 bits in it?:
>> https://github.com/xapi-project/blktap
> blktap3 is actively developed and is the I/O default data path in XenServer 6.5. The repo you mention is the right one (https://github.com/xapi-project/blktap, git branch "xs64bit", but we'll soon bring the "master" branch up to date. I'd be more than happy to assist you and the developer in porting that patch to blktap3!

Sorry for a my probably stupid question.
Why not use qdisk (that have very good performance, support many formats 
and is supported also by other project) and improve it if needed instead 
do/maintain another project xen-only?
FWIK the only thing in what blktab is better is vhd support (not vhdx).

Thanks for any reply and sorry for my bad english.

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [xs-devel] blktap3 / tapdisk3 development
  2014-10-02  9:23   ` Fabio Fantoni
@ 2014-10-02 15:17     ` Felipe Franciosi
  0 siblings, 0 replies; 3+ messages in thread
From: Felipe Franciosi @ 2014-10-02 15:17 UTC (permalink / raw)
  To: 'Fabio Fantoni',
	Thanos Makatos, 'Pasi Kärkkäinen',
	xs-devel
  Cc: xen-devel, s.munaut

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Fabio Fantoni
> Sent: 02 October 2014 10:24
> To: Thanos Makatos; xs-devel@lists.xenserver.org
> Cc: xen-devel@lists.xenproject.org; s.munaut@whatever-company.com
> Subject: Re: [Xen-devel] [xs-devel] blktap3 / tapdisk3 development
> 
> Il 02/10/2014 10:41, Thanos Makatos ha scritto:
> >> It seems upcoming XenServer 6.5 "Creedence" is going to use blktap3 /
> >> tapdisk3 after all, so if i understand this correctly blktap3 is
> >> being developed "only for XenServer", right?
> > Correct, although it shouldn't be too much work for making it work on
> upstream Xen.
> >
> >> Many interested persons have been asking on mailing lists and on IRC
> >> about the status of blktap3 development.
> >> Is it possible for someone from Citrix/XenServer to comment about this?
> >>
> >> I know there's a blog post about blktap3/tapdisk3 performance
> >> (improvements) here:
> >> http://xenserver.org/blog/entry/tapdisk3
> >>
> >> One of the interested developers is CC'd on this email. He has
> >> written RBD/Ceph support patch for blktap2, and he's interested in
> >> porting that to blktap3/tapdisk3..
> >>
> >> Also is this the correct repo with latest blktap3/tapdisk3 bits in it?:
> >> https://github.com/xapi-project/blktap
> > blktap3 is actively developed and is the I/O default data path in XenServer
> 6.5. The repo you mention is the right one (https://github.com/xapi-
> project/blktap, git branch "xs64bit", but we'll soon bring the "master" branch
> up to date. I'd be more than happy to assist you and the developer in porting
> that patch to blktap3!
> 
> Sorry for a my probably stupid question.
> Why not use qdisk (that have very good performance, support many formats
> and is supported also by other project) and improve it if needed instead
> do/maintain another project xen-only?
> FWIK the only thing in what blktab is better is vhd support (not vhdx).

Tapdisk3 has many differences if compared to qdisk. One of them is the VHD support you already mentioned.
Another important one is the use of grant copy instead of grant mapping or persistent grants. In XenServer, we also have a tapdisk3 process per VBD, whereas qdisk uses one process per VM. Both these differences have performance implications and our studies show that tapdisk3 performs/scales better (at least) in the XenServer environment. I have presented some numbers at the XPDS14 and you can find my slides here (I suppose a video recording of the presentation will also be available at some point):
http://www.xenproject.org/component/allvideoshare/video/xpds14-scaling.html

We were already working on tapdisk3 for XenServer 6.5 prior to decisions regarding upstreaming. Right now it is too soon to comment whether qdisk will be considered for future releases.

Cheers,
Felipe

> 
> Thanks for any reply and sorry for my bad english.
> 
> >
> > Cheers
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-10-02 15:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20141001181023.GG12451@reaktio.net>
2014-10-02  8:41 ` [xs-devel] blktap3 / tapdisk3 development Thanos Makatos
     [not found] ` <2368A3FCF9F7214298E53C823B0A48EC0420E2DD@AMSPEX01CL02.citrite.net>
2014-10-02  9:23   ` Fabio Fantoni
2014-10-02 15:17     ` Felipe Franciosi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.