On Thu, May 17, 2012 at 5:51 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > 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. You know that qemu_send_packet is void type, and has return value, if can_send fails, if_encap will not currently get expected return value, so this will cause that we have to modify the definition of qemu_send_packet to make it return one valid value. a lot of functions have called it, so i would not like to modify its definition.
> >> 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. You mean that we need adopt another handling way? or directly TODO comments? > > Paolo -- Regards, Zhi Yong Wu
