Jozsef Kadlecsik wrote: > On Tue, 12 May 2009, Pablo Neira Ayuso wrote: > >> First of all, this is clashing with seven big patches that I have here >> including one to kill the notifier call chain :), I'm waiting for >> Patrick to open nf-next-2.6 to send them all. I can send them now. > > (I have promised patches ;-). Yes, I know they're clashing, I should have > added the RFC tag to the subject. As soon as your patches are integrated > I'll adapt my patches. Great, thanks! First, my patches have to pass Patrick's review :). >>> The patch adds support to control the in-kernel event generation. >>> In practice we face two problems: we should support a fine-grained >>> event generation in netfilter, in order to be able to catch and follow >>> the different state changes. At the same time, for example for conntrack >>> replication, a too fine-grained event generation can easily result in >>> a high, unnecessary system load. BFP and/or userspace event filtering >>> is not effective enough to avoid it: the resources are already burnt >>> on building up the netlink messages. >> Yes, some fine-grain filtering to avoid the message building would be >> interesting, however, what you're proposing is not flexible enough for >> two different applications that are interested in different events. Time >> ago, I proposed a netlink unicast-based interface for ctnetlink similar >> to nfnetlink_queue and the NFQUEUE target. Still, it needed yet another >> table (at the end of postrouting) for something very specific. > > But if application A is interested in event X and application B is > interested in event Y, then why would it be any problem for the solution > I'm proposing? Just proper rules are required, then the events X and Y > will be generated and delivered to the clients. What do I miss here? Nothing I think, I'm refering to the approach itself. If there's one application A that want to receive all events and another B that only wants one event, A and B will receive all events. I think that this should be per-process. [...] > Yes, but the kernel must supply all events the different applications > want. So actually, it's simpler on the kernel side: it needs just to know > the events wanted. And does not really matter, which application wants > which event. Yes, it's simpler from the kernel-side but allowing selecting this from user-space provides more flexibility. > [...] >> In my patches I have added a per-ct event cache like this (but using the >> conntrack extension infrastructure) to add reliable event reporting, >> which is something that we also need for logging and synchronization. >> >> BTW, I don't like using connmark for this. > > You mean the CONNMARK target? I deliberately avoided using the connection > marks. Or "marking" the connections by the eventmask? But that is the most > effective way to filter the events. I see, but something similar to nfnetlink_queue/NFQUEUE (per-process) together with an extended version of the `conntrack match' for events would be more flexible. -- "Los honestos son inadaptados sociales" -- Les Luthiers -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
