|| ||Rusty Russell <rusty-AT-rustcorp.com.au>|
|| ||David Miller <davem-AT-davemloft.net>|
|| ||Re: Netchannles: first stage has been completed. Further ideas.|
|| ||Thu, 27 Jul 2006 15:46:12 +1000|
|| ||kuznet-AT-ms2.inr.ac.ru, johnpol-AT-2ka.mipt.ru, netdev-AT-vger.kernel.org|
On Wed, 2006-07-26 at 22:17 -0700, David Miller wrote:
> I read this as "we will be able to get around the problems" but
> no specific answer as to "how". I am an optimist too but I want
> to start seeing concrete discussion about the way in which the
> problems will be dealt with.
> Alexey has some ideas, such as running the netfilter path from the
> netchannel consumer socket context. That is the kind of thing
> we need to be talking about.
Yes, my first thought back in January was how netfilter would interact
with this in a sane way. One answer is "don't": once someone registers
on any hook we go into slow path. Another is to run the hooks in socket
context, which is better, but precludes having the consumer in
userspace, which still appeals to me 8)
So I don't like either. The mistake (?) with netfilter was that we are
completely general: you will see all packets, do what you want. If,
instead, we had forced all rules to be of form "show me all packets
matching this tuple" we would be in a combine it in a single lookup with
What would the tuple look like? Off the top of my head:
SRCIP/DSTIP/PROTO/SPT/DPT/IN/OUT (where IN and OUT are boolean values
indicating whether the src/dest is local).
Of course, it means rewriting all the userspace tools, documentation,
and creating a complete new infrastructure for connection tracking and
NAT, but if that's what's required, then so be it.
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)