> Date: Thu, 11 Jul 2013 22:25:47 +0200 > From: fw@xxxxxxxxx > To: michael.zintakis@xxxxxxxxxxxxxx > CC: fw@xxxxxxxxx; netfilter-devel@xxxxxxxxxxxxxxx; pablo@xxxxxxxxxxxxx > Subject: Re: [PATCH v3 kernel 19/29] add byte threshold capability to nfacct > > Michael Zintakis <michael.zintakis@xxxxxxxxxxxxxx> wrote: >> Florian Westphal wrote: >>> Michael Zintakis <michael.zintakis@xxxxxxxxxxxxxx> wrote: >>>> * add a 'bthr' variable to each nfacct object, allowing a bytes 'threshold' >>>> to be stored and then reported if/when traffic breaches it. >>> >>> Again, why is this needed? >>> Why is it useful? >> This is used for measuring traffic "expectancy", i.e. allows one to be able to register what amount of traffic is "expected" to pass through this accounting object. If that traffic threshold is exceeded, this is properly indicated when the accounting object is listed or any statistics for that object are being collected by the nfacct daemon. >> >> That traffic "expectancy" can be set/reset depending on the nature of the traffic or its source/destination etc, so it is pretty flexible. Again, there is extensive information on this in the (revised) man page if you decide to look at it. > > I still don't understand why this needs to be in the kernel. > nfacct gives you the counters, how these are interpreted (e.g. 'higher > than expected' should be entirely up to userspace). > I also vote for this patch. I'll try here to describe our use case. We checking counter every minute, why not to check it more often? It's possible and doesn't lead to huge performance problems, but we want to save battery power and we don't want such big resolution in measurements. But also we need to restrict traffic according to predefined user quota. To not exceed such restriction we need to deligate such responsobility to kernel. Now I talking only about wireless connection, but even on 3G it's possible to download more than 50Mb per one minute. Also we need to inform user about quota comming beforehand. Based on given kernel couters update time interval, quota value and bandwidth I came to conclusion what it's better to have some warning threshold for informing user space from kernel. I predict here comment about none general use case :) I thought to add it to xt_quota, but nfacct it's better place. > In case you need some way of reacting to excess counters, then perhaps > it makes sense to change nfacct match to allow "greater/less than" > matching expression instead? > > E.g.: > -A bla -m nfacct --nfacct-name bla --nfacct-packets 1000000: -m limit > --limit 1/hour -j NFLOG --nflog-prefix 'bla packet threshold' > > or something like that? It's fit too. P.S. we don't use neither nfacct now, nor xt_quota due we counting based on net_cls (cls_cgroup) marks and as I understand it's not possible for incomming traffic without netfilter refactoring. > > There is something similar for the conntrack accounting (-m connbytes). > -- > 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 -- 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
