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

[Jason Wang]

On 07/27/2015 03:45 PM, Yang Hongyang wrote:
> On 07/27/2015 03:31 PM, Jason Wang wrote:
>>
>>
>> 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 <address@hidden>
>>>>>>
>>>>>> 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?
>
> But how to implement a plugin which suppose to do the actual work on
> the packets?

Well, the filter get the packets, so it can do everything it wants.

> how to configure params related to the plugin? different
> plugins may need different params, implement as another netdev?

I belive qmp can do this? something like -filter dump,id=f0,len=10000?

>
>>
>>> 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?
>
> No, when remove filter, we restore the connection between network
> backend and
> NIC. Just like filter does not ever exists.

But e1000's peer is f0. You mean you will modify the peer pointer during
filter removing? Sounds scary.

>
>>
>>
>>
>> .
>>
>