From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJdxI-0002HP-Sv for qemu-devel@nongnu.org; Mon, 27 Jul 2015 04:40:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJdxF-0007PO-Lo for qemu-devel@nongnu.org; Mon, 27 Jul 2015 04:40:16 -0400 Received: from [59.151.112.132] (port=36912 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJdxE-0007NT-HQ for qemu-devel@nongnu.org; Mon, 27 Jul 2015 04:40:13 -0400 Message-ID: <55B5EE5F.4050003@cn.fujitsu.com> Date: Mon, 27 Jul 2015 16:39:59 +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> <55B5E1A4.9010100@cn.fujitsu.com> <55B5E543.8050505@redhat.com> In-Reply-To: <55B5E543.8050505@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 04:01 PM, Jason Wang wrote: > > 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 >>>>>>> >>>>>>> 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? So you mean implement another object filter? and the structure is like netdev? That will duplicate some of the netdev layer code. Implement it as a netdev can reuse the existing netdev design. And current dump is implemented as a netdev right? even if we simply passing the packets to the filter function before calling nc->info->receive{_raw}(), we might also need to implement as a netdev as dump dose. > >> >>> >>>> 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? Yes. > Sounds scary. > >> >>> >>> >>> >>> . >>> >> > > . > -- Thanks, Yang.