From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZL6Ji-0003sa-EC for qemu-devel@nongnu.org; Fri, 31 Jul 2015 05:09:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZL6Jd-0001Hs-S4 for qemu-devel@nongnu.org; Fri, 31 Jul 2015 05:09:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZL6Jd-0001Hc-K1 for qemu-devel@nongnu.org; Fri, 31 Jul 2015 05:09:21 -0400 Message-ID: <55BB3B3D.5000403@redhat.com> Date: Fri, 31 Jul 2015 17:09:17 +0800 From: Jason Wang MIME-Version: 1.0 References: <1438316014-8369-1-git-send-email-yanghy@cn.fujitsu.com> <1438316014-8369-6-git-send-email-yanghy@cn.fujitsu.com> <55BB1062.8000901@redhat.com> <55BB30C1.4090300@cn.fujitsu.com> In-Reply-To: <55BB30C1.4090300@cn.fujitsu.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 5/9] netfilter: hook packets before net queue send List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yang Hongyang , qemu-devel@nongnu.org Cc: thuth@redhat.com, zhang.zhanghailiang@huawei.com, lizhijian@cn.fujitsu.com, mrhines@linux.vnet.ibm.com, stefanha@redhat.com On 07/31/2015 04:24 PM, Yang Hongyang wrote: > > > On 07/31/2015 02:06 PM, Jason Wang wrote: >> >> >> On 07/31/2015 12:13 PM, Yang Hongyang wrote: >>> Capture packets that will be sent. >>> >>> Signed-off-by: Yang Hongyang >>> --- >>> include/net/filter.h | 8 +++++++ >>> net/filter.c | 1 + >>> net/net.c | 67 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++- >>> 3 files changed, 75 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/net/filter.h b/include/net/filter.h >>> index 1b6f896..93579c1 100644 >>> --- a/include/net/filter.h >>> +++ b/include/net/filter.h >>> @@ -19,11 +19,19 @@ enum { >>> }; >>> >>> typedef void (FilterCleanup) (NetFilterState *); >>> +/* >>> + * Return: >>> + * 0: finished handling the packet, we should continue >>> + * size: filter stolen this packet, we stop pass this packet further >>> + */ >>> +typedef ssize_t (FilterReceiveIOV)(NetFilterState *, NetClientState >>> *sender, >>> + unsigned flags, const struct >>> iovec *, int); >>> >>> typedef struct NetFilterInfo { >>> NetFilterOptionsKind type; >>> size_t size; >>> FilterCleanup *cleanup; >>> + FilterReceiveIOV *receive_iov; >> >> Please move this to patch 2. > > Ok, thanks! > >> >>> } NetFilterInfo; >>> >>> struct NetFilterState { >>> diff --git a/net/filter.c b/net/filter.c >>> index b3a2285..1ae9344 100644 >>> --- a/net/filter.c >>> +++ b/net/filter.c >>> @@ -29,6 +29,7 @@ NetFilterState *qemu_new_net_filter(NetFilterInfo >>> *info, >>> NetFilterState *nf; >>> >>> assert(info->size >= sizeof(NetFilterState)); >>> + assert(info->receive_iov); >>> >>> nf = g_malloc0(info->size); >>> nf->info = info; >>> diff --git a/net/net.c b/net/net.c >>> index 22748e0..b55d934 100644 >>> --- a/net/net.c >>> +++ b/net/net.c >>> @@ -24,6 +24,7 @@ >>> #include "config-host.h" >>> >>> #include "net/net.h" >>> +#include "net/filter.h" >>> #include "clients.h" >>> #include "hub.h" >>> #include "net/slirp.h" >>> @@ -592,6 +593,42 @@ int qemu_can_send_packet(NetClientState *sender) >>> return 1; >>> } >>> >>> +static ssize_t filter_receive_iov(NetClientState *nc, int chain, >>> + NetClientState *sender, >>> + unsigned flags, >>> + const struct iovec *iov, >>> + int iovcnt) { >>> + ssize_t ret = 0; >>> + Filter *filter = NULL; >>> + NetFilterState *nf = NULL; >>> + ssize_t size = iov_size(iov, iovcnt); >>> + >>> + QTAILQ_FOREACH(filter, &nc->filters, next) { >>> + nf = filter->nf; >>> + if (nf->chain == chain || nf->chain == NET_FILTER_ALL) { >>> + ret = nf->info->receive_iov(nf, sender, flags, iov, >>> iovcnt); >>> + if (ret == size) { >>> + return ret; >>> + } >>> + } >>> + } >> >> So if a packet is being stolen or blocked by one filter, it could only >> be flushed to destination? I think we need an API to flush it into next >> filter. > > Yes, we could, just call next filter's receive_iov, do I need to > introduce > the API now in this series? or introduce later when we actually need it? Consider it is a public API. better in this patch.