From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Durgin Subject: Re: About Adding eventfd support for LibRBD Date: Mon, 13 Jul 2015 12:58:05 -0700 Message-ID: <55A4184D.8020505@redhat.com> References: <559C9422.8010403@redhat.com> <758467134.37486644.1436795528859.JavaMail.zimbra@redhat.com> <1771808938.37680022.1436808765381.JavaMail.zimbra@redhat.com> <694208947.37724099.1436812751415.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751678AbbGMT6A (ORCPT ); Mon, 13 Jul 2015 15:58:00 -0400 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Sage Weil , Jason Dillaman Cc: Milosz Tanski , Haomai Wang , ceph-devel On 07/13/2015 11:42 AM, Sage Weil wrote: > On Mon, 13 Jul 2015, Jason Dillaman wrote: >>> But it doesn't provide an easily compassable way >>> of integrating waiting on other events in the application. eventfd is >>> easy to embed in your (e)pool loop or any kind of event library >>> (libev). >> >> Agreed -- which is why I asked about the proposed design since it >> appears (to me) that everything is hidden behind the librbd API and thus >> not embeddable within a generic app event loop. It might just be a >> misunderstanding on my part, which is why I asked for an example >> integration. > > Bonus points if this helps out the qemu librbd usage, which (if memory > serves) does some annoying stuff with a pipe in the callback to notify > qemu of IO completion. Perhaps qemu can work with an eventfd more > directly? This was fixed a little while back when qemu was converted to using coroutines and more than one thread, but it would make usage in other applications with simpler threading models easier. IIRC the xen blktap driver for rbd used the same pipe workaround to deal with librbd's current callback api.