[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150410133610.GA19454@acer.localdomain>
Date: Fri, 10 Apr 2015 14:36:11 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Thomas Graf <tgraf@...g.ch>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
davem@...emloft.net
Subject: Re: [PATCH 5/7] net: add netfilter ingress hook
On 10.04, Thomas Graf wrote:
> On 04/10/15 at 02:15pm, Pablo Neira Ayuso wrote:
> > static int __netif_receive_skb_ingress(struct sk_buff *skb, bool pfmemalloc,
> > struct net_device *orig_dev)
> > {
> > @@ -3772,6 +3800,8 @@ skip_taps:
> > if (!skb)
> > return NET_RX_DROP;
> > #endif
> > + if (nf_hook_ingress_active(skb))
> > + return nf_hook_ingress(skb, pt_prev, orig_dev, pfmemalloc);
> >
> > return __netif_receive_skb_finish(skb, pfmemalloc, pt_prev, orig_dev);
> > }
>
> I would favour if we avoid for every subsystem to manage its ingress
> filter pointers in net_device. From a net_device perspective, all it
> takes is a single pointer which points to a single linked list of
> filters which need to be run through. These entries could represent
> an ingress qdisc or a netfilter chain or something else (L2 ingress
> qdisc?).
I'm wondering if the hook is the right abstraction at all. Netfilter hooks
require async resumption (okfn) support, which is why all the refactoring is
needed. Is that something that we need for NF_PROTO_NETDEV? For ingress
userspace queueing *might* actually work if the missing pieces are added,
but for offloaded rules it obviously can not work.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists