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 routing etc. 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. Rusty. -- 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
