From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHvby-0000O6-Bj for qemu-devel@nongnu.org; Wed, 22 Jul 2015 11:07:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHvbt-0002Bj-3b for qemu-devel@nongnu.org; Wed, 22 Jul 2015 11:07:10 -0400 Received: from [59.151.112.132] (port=53713 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHvbr-00025F-Lj for qemu-devel@nongnu.org; Wed, 22 Jul 2015 11:07:05 -0400 Message-ID: <55AFB18E.1020007@cn.fujitsu.com> Date: Wed, 22 Jul 2015 23:06:54 +0800 From: Yang Hongyang MIME-Version: 1.0 References: <55AF75E6.6070909@cn.fujitsu.com> <1437562536-20414-1-git-send-email-yanghy@cn.fujitsu.com> <55AF9515.3030600@redhat.com> In-Reply-To: <55AF9515.3030600@redhat.com> Content-Type: text/plain; charset="utf-8"; 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: Thomas Huth , qemu-devel@nongnu.org Cc: jasowang@redhat.com, stefanha@redhat.com On 07/22/2015 09:05 PM, Thomas Huth wrote: > On 22/07/15 12:55, 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 > > That's basically a neat idea... however, one question remains: Will > there be other filters beside the "dump" filter that you mentioned in > your example? Do you already have something in mind? Yes, one usecase I can think of is a netbuffer plugin, which simply buffer the packets, and then release the packets on demand, this can be used by vm ft solutions like microcheckpoiting, will simplify the network configuration of MC, currently MC network replication needs kernel support and some extra configuration. Another use case could be COLO ft solution, it needs to capture packets from both primary/secondary and compare them to decide whether we should start a checkpoint. > > If not, I think this is likely not worth the effort - and we likely > should keep it simple and implement the dump option as suggested with my > patches instead. > >> diff --git a/net/filter.c b/net/filter.c >> new file mode 100644 >> index 0000000..006c64a >> --- /dev/null >> +++ b/net/filter.c >> @@ -0,0 +1,200 @@ >> +/* >> + * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO) >> + * (a.k.a. Fault Tolerance or Continuous Replication) > > This looks like a bad copy-n-paste comment... ? > >> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD. >> + * Copyright (c) 2015 FUJITSU LIMITED >> + * Copyright (c) 2015 Intel Corporation >> + * >> + * This work is licensed under the terms of the GNU GPL, version 2 or >> + * later. See the COPYING file in the top-level directory. >> + */ > ... > > Thomas > > > > -- Thanks, Yang.