From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJd6n-0007qq-M0 for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:46:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJd6k-000165-VU for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:46:01 -0400 Received: from [59.151.112.132] (port=49425 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJd6k-00014L-0q for qemu-devel@nongnu.org; Mon, 27 Jul 2015 03:45:58 -0400 Message-ID: <55B5E1A4.9010100@cn.fujitsu.com> Date: Mon, 27 Jul 2015 15:45:40 +0800 From: Yang Hongyang MIME-Version: 1.0 References: <55AF75E6.6070909@cn.fujitsu.com> <1437562536-20414-1-git-send-email-yanghy@cn.fujitsu.com> <55B082BE.2020703@redhat.com> <55B5C14F.5030808@cn.fujitsu.com> <55B5D214.5030506@redhat.com> <55B5D727.8010806@cn.fujitsu.com> <55B5DE34.9050409@redhat.com> In-Reply-To: <55B5DE34.9050409@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] RFC/net: Add a net filter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang , qemu-devel@nongnu.org Cc: thuth@redhat.com, stefanha@redhat.com 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 >>>>> >>>>> 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? how to configure params related to the plugin? different plugins may need different params, implement as another netdev? > >> 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. > > > > . > -- Thanks, Yang.