Hi Pablo, On 09/20/2016 04:29 PM, Pablo Neira Ayuso wrote: > On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote: > [...] >> Why would we artificially limit the use-cases of this implementation if >> the way it stands, both filtering and introspection are possible? > > Why should we place infrastructure in the kernel to filter packets so > late, and why at postrouting btw, when we can do this way earlier > before any packet is actually sent? The point is that from an application's perspective, restricting the ability to bind a port and dropping packets that are being sent is a very different thing. Applications will start to behave differently if they can't bind to a port, and that's something we do not want to happen. Looking at packets and making a verdict on them is the only way to implement what we have in mind. Given that's in line with what netfilter does, it can't be all that wrong, can it? > No performance impact, no need for > skbuff allocation and *no cycles wasted to evaluate if every packet is > wanted or not*. Hmm, not sure why this keeps coming up. As I said - for accounting, there is no other option than to look at every packet and its size. Regarding the performance concerns, are you saying a netfilter based implementation that uses counters for that purpose would be more efficient? Because in my tests, just loading the netfilter modules with no rules in place at all has more impact than running the code from 6/6 on every packet. As stated before, I see no reason why we shouldn't have a netfilter based implementation that can achieve the same, function-wise. And I would also like to compare their throughput. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
