Il 17/05/2012 07:59, Zhi Yong Wu ha scritto: >> > However, then I noticed that qemu_can_send_packet is not called very much, >> > and I do not understand why qemu_net_queue_send and qemu_net_queue_send_iov >> > do not call qemu_can_send_packet before calling deliver/deliver_iov. > This case has existed in current upstream code, not only vlan-hub > code. Currently can_send function has been called by backend send > function before deliver/deliver_iov, If we put can_send in queue send > function, your idea will have a big challenge for slirp packet queue.
Exactly why? For SLIRP's receive path, SLIRP doesn't implement can_receive at all so it will never block. For the send path, when flow control kicks qemu_net_queue_append will copy the packet so it is not a problem for SLIRP's stack-allocated packets. > We can implement your idea below later, not in this patchset. What do > you think? Note that my idea above was only means to an end. If you can remove the TODOs in a convincing manner, that would be fine. Paolo
