qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3 03/13] l2tpv3: Drop l2tpv3_can_send


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [PATCH v3 03/13] l2tpv3: Drop l2tpv3_can_send
Date: Tue, 26 May 2015 10:07:10 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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

Attachment: pgp4yPaLmunjR.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]