[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKD1Yr02SCHvd-xZJL14d_Ta8Dk4evHZ60zytpU0h4r80FucwA@mail.gmail.com>
Date: Wed, 2 Nov 2016 00:25:15 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Daniel Mack <daniel@...que.org>,
Pablo Neira Ayuso <pablo@...filter.org>, htejun@...com,
ast@...com, David Miller <davem@...emloft.net>, kafai@...com,
Florian Westphal <fw@...len.de>, harald@...hat.com,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Sargun Dhillon <sargun@...gun.me>, cgroups@...r.kernel.org
Subject: Re: [PATCH v7 0/6] Add eBPF hooks for cgroups
On Sun, Oct 30, 2016 at 5:29 AM, Daniel Borkmann <daniel@...earbox.net> wrote:
> Fwiw, not sure if swapping brings much, even after netfilter there could
> be complex processing that would potentially drop, mangle, redirect, etc
> from tc layer (egress or from qdisc itself). But also at even lower layers
I agree lots of stuff can still happen after the netfilter hooks have
finished. But it seems to me that netfilter hooks are more flexible
and have more access to more data (L2 headers, output devices,
conntrack state entries, etc. etc.) than this hook. So it seems to me
that this hook would be more useful if it ran after netfilter on
egress.
That way, if you want to modify the packet or do something
sophisticated in netfilter, you can still use the eBPF hook on the
results of that operation, and if you don't want to run netfilter, you
can write netfilter rules to skip the packet (and maybe still fix it
up later, perhaps in another netfilter chain).
Powered by blists - more mailing lists