[Top][All Lists]

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

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

From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH] RFC/net: Add a net filter
Date: Mon, 27 Jul 2015 15:31:00 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

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?

> 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?

reply via email to

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