Re: [Qemu-devel] [PATCH] RFC/net: Add a net filter

[Jason Wang <jasowang@redhat.com>]

On 07/27/2015 03:00 PM, Yang Hongyang wrote:
>
>
> On 07/27/2015 02:39 PM, Jason Wang wrote:
>>
>>
>> On 07/27/2015 01:27 PM, Yang Hongyang wrote:
>>> On 07/23/2015 01:59 PM, Jason Wang wrote:
>>>>
>>>>
>>>> On 07/22/2015 06:55 PM, Yang Hongyang wrote:
>>>>> This patch add a net filter between network backend and NIC devices.
>>>>> All packets will pass by this filter.
>>>>> TODO:
>>>>>    multiqueue support.
>>>>>    plugin support.
>>>>>
>>>>>                 +--------------+       +-------------+
>>>>> +----------+  |    filter    |       |frontend(NIC)|
>>>>> | real     |  |              |       |             |
>>>>> | network  <--+backend       <-------+             |
>>>>> | backend  |  |         peer +-------> peer        |
>>>>> +----------+  +--------------+       +-------------+
>>>>>
>>>>> Usage:
>>>>> -netdev tap,id=bn0  # you can use whatever backend as needed
>>>>> -netdev filter,id=f0,backend=bn0,plugin=dump
>>>>> -device e1000,netdev=f0
>>>>>
>>>>> Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
>>>>
>>>> Hi:
>>>>
>>>> Several questions:
>>>>
>>>> - Looks like we can do more than filter, so may be something like
>>>> traffic control or other is more suitable?
>>>
>>> The filter is just a transparent proxy of a backend if no filter plugin
>>> is inserted. It just by pass all packets. Capture all traffic is the
>>> purpose
>>> of the filter. As long as we have an entry to capture all packets, we
>>> can do more, this is what a filter plugin will do. There are some use
>>> cases
>>> I can think of:
>>> - dump, by using filter, we can dump either output/input packets.
>>> - buffer, to buffer/release packets, this feature can be used when
>>> using
>>>            macrocheckpoing. Or other Remus like VM FT solutions. You
>>> can
>>>            also supply an interval to a buffer plugin, which will
>>> release
>>>            packets by interval.
>>
>> This sounds like traffic shaping.
>>
>>> May be other use cases based on this special backend.
>>>
>>>> - What's the advantages of introducing a new type of netdev? As far
>>>> as I
>>>> can see, just replace the dump function in Tomas' series with a
>>>> configurable function pointer will do the trick? (Probably with some
>>>> monitor commands). And then you won't even need to deal with vnet hder
>>>> and offload stuffs?
>>>
>>> I think dump function focus on every netdev, it adds an dump_enabled to
>>> NetClientState, and dump the packet when the netdev receive been
>>> called,
>>> This filter function more focus on packets between backend/frontend,
>>> it's kind of an injection to the network packets flow.
>>> So the semantics are different I think.
>>
>> Yes, their functions are different. But the packet paths are similar,
>> both require the packets go through themselves before reaching the
>> peers. So simply passing the packets to the filter function before
>> calling nc->info->receive{_raw}() in qemu_deliver_packet() will also
>> work?
>
> I think this won't work for the buffer case? If we want the buffer case
> to work under this, we should modify the generic netdev layer code, to
> check the return value of the filter function call.

But checking return value is rather simpler than a new netdev type,
isn't it?

> And it is not as
> extensible as we abstract the filter function to a netdev, We can
> flexibly add/remove/change filter plugins on the fly.

I don't see why we lose the flexibility like what I suggested. Actually,
implement it through a netdev will complex this. E.g:

-netdev tap,id=bn0  # you can use whatever backend as needed
-netdev filter,id=f0,backend=bn0,plugin=dump
-device e1000,netdev=f0

How did you remove filter id=f0? Looks like you need also remove e1000 nic?