On Tue, Jul 14, 2015 at 04:34:19PM +0800, Wen Congyang wrote: > On 07/14/2015 03:53 PM, Fam Zheng wrote: > > Since a90a742 "tap: Drop tap_can_send", all nics that returns false from > > .can_receive() are required to explicitly flush the incoming queue when the > > status of it is changing back to true, otherwise the backend will sop > > processing more rx packets. > > > > The purpose of this callback is to tell the peer backend (tap, socket, etc) > > "hold on until guest consumes old data because my buffer is not ready". More > > often than not NICs also do this when driver deactivated the card or > > disabled > > rx, causing the packets being unnessarily queued, where they should actualy > > be > > dropped. > > > > This series adds such missing qemu_flush_queued_packets calls for all NICs, > > and > > drops such unnecessary conditions in .can_receive(), so that NICs now: > > > > - returns false from .can_receive when guest buffers are busy. > > - calls qemu_flush_queued_packets when buffers are available again. > > - returns -1 from .receive when rx is not enabled. > > > > e1000, ne2000, rocker and vmxnet3 are not included because they're fixed by > > other patches on the list and applied to Stefan's tree. > > > > virtio-net is covered by another thread: > > > > https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07377.html > > When will the virtio-net patch be accepted? Without this patch, virtio-net + > tap > can not work.
Fam's recent net fixes are all-or-nothing. We either have to merge all of them or none of them, because the patches remove .can_receive(). I'm waiting until reviewers are satisfied on all patches. The plan is to merge them for QEMU 2.4. If that isn't possible due to running out of time, I'll have to revert Fam's older qemu_set_fd_handler2() refactoring patches which caused the breakage you are seeing. There is not much time left for QEMU 2.4 but we're close to happy on all of Fam's patches now.
pgp9qBPwN44sO.pgp
Description: PGP signature
