On Tue, May 26, 2015 at 02:52:48PM +0800, Fam Zheng wrote:
> On Tue, 05/19 15:48, Stefan Hajnoczi wrote:
> > On Tue, May 19, 2015 at 10:51:00AM +0000, Fam Zheng wrote:
> > > This callback is called by main loop before polling s->fd, if it returns
> > > false, the fd will not be polled in this iteration.
> > >
> > > This is redundant with checks inside read callback. After this patch,
> > > the data will be copied from s->fd to s->msgvec when it arrives. If the
> > > device can't receive, it will be queued to incoming_queue, and when the
> > > device status changes, this queue will be flushed.
> >
> > This doesn't work because s->msgvec can fill up when
> > qemu_can_send_packet() returns false. At that point we burn 100% CPU
> > because the file descriptor is still being monitored.
>
> If qemu_can_send_packet returns false, we do stop monitoring the fd. In
> net_l2tpv3_process_queue:
>
> size = qemu_send_packet_async(
> &s->nc,
> vec->iov_base,
> data_size,
> l2tpv3_send_completed
> );
> if (size == 0) {
> l2tpv3_read_poll(s, false);
> }
>
> The packet is queued and size is 0, so the read poll will be disabled until
> it's flushed.
>
> What am I missing?
I think you are right.
I was looking at the while loop qemu_can_send_packet():
} while (
(s->queue_depth > 0) &&
qemu_can_send_packet(&s->nc) &&
((size > 0) || bad_read)
);
and missed the portion you quoted.
Stefan
pgpunICm4wYZ4.pgp
Description: PGP signature
