qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 09/12] netfilter: add a netbuffer filter


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH 09/12] netfilter: add a netbuffer filter
Date: Thu, 30 Jul 2015 16:16:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

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




reply via email to

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