Re: [Qemu-devel] [Qemu-block] [PATCH v3 00/13] main-loop: Get rid of fd_read_poll and qemu_set_fd_handler2

[Fam Zheng <famz@redhat.com>]

On Tue, 05/19 16:02, Stefan Hajnoczi wrote:
> On Tue, May 19, 2015 at 10:50:57AM +0000, Fam Zheng wrote:
> > v3: Replace previous 13 with a simple return type conversion patch.
> >     Drop RFC.
> > 
> > This carries out the mandate in the comment of qemu_set_fd_handler2 and removes
> > fd_read_poll from the code base, because it will make the work easier to
> > convert ppoll to epoll in main loop.  Also, the aio interface doesn't have a
> > read poll callback, which means this conversion woule be necessary if we want
> > to move iohandler fds from main loop to AioContext.
> > 
> > There are five users of the read poll callback now: qemu-nbd, l2tpv3, netmap,
> > socket and tap, which are all covered.
> > 
> > Patch 1 adds a stub for qemu_set_fd_handler which will be referenced in coming
> > patches.
> > 
> > Patch 2 converts qemu-nbd which compares two global numbers in the fd_read_poll
> > callback.
> > 
> > Patches 3~6 converts the four net devices, all of which checks
> > qemu_can_send_packet() in the callback.
> > 
> > Patch 7 and 8 finally removes the function.
> > 
> > The rest patches are cleanup for the unuseful return value of
> > qemu_set_fd_handler.
> > 
> > Please review!
> 
> I looked at the first few patches.
> 
> The qemu-nbd.c conversion is good.  It finds locations where read_poll
> state transitions happen and updates file descriptor monitoring there.

Paolo, will you apply the qemu-nbd.c patch? I'll split net patches into a
separate series.

> 
> The l2tpv3 and netmap conversion throws away read_poll and introduces
> problems instead.
> 
> Please look at the patches again and either:
> 
> 1. Convert everything like you converted qemu-nbd.c.  This is a
>    conservative approach and we can be confident that behavior is
>    unchanged.

OK, I'll try this.

Fam

> 
> 2. Convert more carefully, making sure that packets are actually
>    dropped and QEMU does not spin on a readable fd.
> 
> I prefer #1 because it's easier to check that behavior is still correct.
> It also minimizes queuing inside QEMU.
> 
> Stefan