[v2 PATCH 0/6] netfilter: "fail-open" feature support for NFQUEUE

[Krishna Kumar <krkumar2@in.ibm.com>]

Many users of an IBM security product, which uses netfilter's NFQUEUE
target to process packets in userspace, face a problem of dropped
connections during heavy load. Incoming packets are queued and
processed by the security module, which does deep packet analysis to
decide whether to accept or reject them. However during heavy load,
NFQUEUE queue (default 1024 entries) fills up and connections fail
after large number of packets drop during enqueue. Increasing the
queue size delays the problem and also worsens latency.

This patch set implements a "failopen" support for NFQUEUE to help
keep connections open during such failures. This is achieved by
allowing acceptance of packets temporarily when the queue is full,
which enables existing connections to be kept alive. Customers have
expressed preference for this option as similar feature is available
on other systems.

Failopen is enabled/disabled using nfq_set_failopen() call, which
uses netlink's NFQA_CFG_FAIL_OPEN attribute (will submit the library
code to turn fail-open on/off later). During a stalled scp session,
application can call this new API with fail-open set to continue the
session, as can be seen below:

		Server:
# iptables -A INPUT -p tcp -m mac --mac-source 00:00:C9:C6:4F:22 \
	-j NFQUEUE --queue-num 0
# Run interceptor program with 50ms delay between packet processing, and
	also sets qlen to 16. After every read system call, this program
	tests and read's a config file's contents (0 or 1) and dynamically
	calls nfq_set_failopen(qh, val).

		Client:
# scp LARGE_FILE 10.0.4.1:/tmp
LARGE_FILE                           2% 2832KB 183.7KB/s   09:38 ETA
LARGE_FILE                           2% 3088KB  67.3KB/s   26:14 ETA
	<Set failopen=1 on server at this time>
LARGE_FILE                           11%   12MB   1.0MB/s   01:35 ETA
LARGE_FILE                           70%   75MB   7.2MB/s   00:04 ETA
LARGE_FILE                           100%  107MB   2.5MB/s  00:42


Please review.

Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Signed-off-by: Vivek Kashyap <vivk@us.ibm.com>
Signed-off-by: Sridhar Samudrala <samudrala@us.ibm.com>
---