summaryrefslogtreecommitdiff
path: root/drivers/atm/solos-pci.c
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2009-07-27 12:22:46 +0400
committerDavid S. Miller <davem@davemloft.net>2009-07-27 22:35:32 +0400
commita44a4a006b860476881ec0098c36584036e1cb91 (patch)
treed1f6f519b734ca3b4b9e18ad473577884fb6b0d1 /drivers/atm/solos-pci.c
parent8a729fce76f7af50d8b622f2fb26adce9c8df743 (diff)
downloadlinux-a44a4a006b860476881ec0098c36584036e1cb91.tar.xz
xfrm: export xfrm garbage collector thresholds via sysctl
Export garbage collector thresholds for xfrm[4|6]_dst_ops Had a problem reported to me recently in which a high volume of ipsec connections on a system began reporting ENOBUFS for new connections eventually. It seemed that after about 2000 connections we started being unable to create more. A quick look revealed that the xfrm code used a dst_ops structure that limited the gc_thresh value to 1024, and always dropped route cache entries after 2x the gc_thresh. It seems the most direct solution is to export the gc_thresh values in the xfrm[4|6] dst_ops as sysctls, like the main routing table does, so that higher volumes of connections can be supported. This patch has been tested and allows the reporter to increase their ipsec connection volume successfully. Reported-by: Joe Nall <joe@nall.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> ipv4/xfrm4_policy.c | 18 ++++++++++++++++++ ipv6/xfrm6_policy.c | 18 ++++++++++++++++++ 2 files changed, 36 insertions(+) Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/atm/solos-pci.c')
0 files changed, 0 insertions, 0 deletions