| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | statement: avoid huge rodata array | Florian Westphal | 2013-10-22 | 1 | -9/+14 |
| | | | | | | | | | | commit b259d1a ('src: operational limit match') creates huge array, increasing nft binary size from ~240k to ~5m on x86_64. Use switch statement instead. Signed-off-by: Florian Westphal <fw@strlen.de> | ||||
| * | src: operational limit match | Phil Oester | 2013-10-22 | 1 | -2/+10 |
| | | | | | | | | | | | | | | | | | | | | | The nft limit match currently does not work at all. Below patches to nftables, libnftables, and kernel address the issue. A few notes on the implementation: - Removed support for nano/micro/milli second limits. These seem pointless, given we are using jiffies in the limit match, not a hpet. And who really needs to limit items down to sub-second level?? - 'depth' member is removed as unnecessary. All we need in the kernel is the rate and the unit. - 'stamp' member becomes the time we need to next refresh the token bucket, instead of being updated on every packet which goes through the match. This closes netfilter bugzilla #827, reported by Eric Leblond. Signed-off-by: Phil Oester <kernel@linuxace.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> | ||||
| * | log: s/threshold/queue-threshold/ | Florian Westphal | 2013-09-14 | 1 | -1/+1 |
| | | | | | | | | | on input we expect "queue-threshold" token, so use the same name when printing the output. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> | ||||
| * | Initial commitv0.01-alpha1 | Patrick McHardy | 2009-03-18 | 1 | -0/+210 |
 |
index : nftables | |
| nft command line tool | pablo@netfilter.org |
| summaryrefslogtreecommitdiffstats |