From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfODE-0002jL-N0 for qemu-devel@nongnu.org; Fri, 25 Sep 2015 04:18:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZfODA-0000dI-GP for qemu-devel@nongnu.org; Fri, 25 Sep 2015 04:18:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfODA-0000d8-CB for qemu-devel@nongnu.org; Fri, 25 Sep 2015 04:18:32 -0400 References: <1442405768-23019-1-git-send-email-yanghy@cn.fujitsu.com> <1442405768-23019-10-git-send-email-yanghy@cn.fujitsu.com> <87si64qiyr.fsf@blackfin.pond.sub.org> <5604F54F.1000509@cn.fujitsu.com> From: Jason Wang Message-ID: <5605035D.7070801@redhat.com> Date: Fri, 25 Sep 2015 16:18:37 +0800 MIME-Version: 1.0 In-Reply-To: <5604F54F.1000509@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v11 09/12] netfilter: add a netbuffer filter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yang Hongyang , Markus Armbruster Cc: thuth@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, lizhijian@cn.fujitsu.com, zhang.zhanghailiang@huawei.com On 09/25/2015 03:18 PM, Yang Hongyang wrote: > > > On 09/24/2015 05:12 PM, Markus Armbruster wrote: >> Yang Hongyang writes: >> >>> This filter is to buffer/release packets, this feature can be used >>> when using MicroCheckpointing, or other Remus like VM FT solutions, you >> >> What's "Remus"? > > Remus is an opensource VM FT solution: > paper: http://http//www.cs.ubc.ca/~andy/papers/remus-nsdi-final.pdf > First implemented on Xen: > http://wiki.xen.org/wiki/Remus > > MicroCheckpointing in QEMU is another Remus implementation. > > [...] >> >>> + * FIXME: even if guest can't receive packet for some reasons. >>> Filter >>> + * can still accept packet until its internal queue is full. >>> + */ >> >> I'm not sure I understand the comment. > > This is taken from Jason's comments, may be he can have a better explain? For example. For some reason, receiver could not receive more packets (.can_receive() returns zero). Without a filter, at most one packet will be queued in incoming queue and sender's poll will be disabled unit its sent_cb() was called. With a filter, it will keep receive the packets without caring about the receiver. This is suboptimal. May need more thoughts (e.g keeping sent_cb). [...]