On 30/07/15 12:28, Yang Hongyang wrote: > On 07/30/2015 06:14 PM, Jason Wang wrote: >> >> >> On 07/30/2015 05:49 PM, Yang Hongyang wrote: >>> On 07/30/2015 05:33 PM, Jason Wang wrote: [...] >>>> I see, so the reason is you are using qemu_deliver_packet() for both >>>> enqueuing packet to filter and delivering packet to destination. How >>>> about something like: >>>> >>>> E.g for qemu_send_packet_async(), move the hook before >>>> qemu_send_packet_async_with_flags(). Then flush method can call >>>> qemu_send_packet_async_with_flags() without any issue? >>> >>> I think we can't move the hook earlier, because filters only deal >>> with the packets will actually been sent. for example, a dump filter. >>> dump packet that probably won't been sent is wrong. calling >>> qemu_send_packet_async() or qemu_send_packet_async_with_flags() >>> doesn't mean the packet is sent, if the sent_cb is not provided and >>> the other peer is not able to receive, the packet will be dropped. >> >> It depends on how do you define 'actually been sent' and whether or not >> we should have such accuracy. Packet could be dropped by various layers. >> Reaching receive() or receive_iov() does not mean it can be sent for >> sure. For example, lots of nics drop packet in their receive() >> implementation. > > This is true, ok, I'm convinced that we might not need to be this accurate. > but Thomas might have different opinion, I saw this description in his > dump series: > > + /* > + * Log network traffic into a dump file. Note: This should ideally > + * be done after calling the ->receive() function below to make sure > + * that we only log the packets that have really been sent. However, > + * this does not work right with slirp networking since it immediately > + * sends reply packets during the receive() function already, so we > + * would get a wrong order of the packets in the dump file in that > case. > + */ > > So Thomas, what do you think of this?
IMHO it should be ok if a dump captures a packet multiple times - it's not nice, but it could theoretically also happen on a physical line when a packet has to be retransmitted. Thomas
