Re: kern/44473: (FAST-)IPSEC processing comsumes too much CPU in interrupt processing

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR kern/44473; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/44473: (FAST-)IPSEC processing comsumes too much CPU in
 interrupt processing
Date: Thu, 27 Jan 2011 10:58:55 -0500

 On Thu, 27 Jan 2011 13:00:01 +0000 (UTC)
 Wolfgang.Stukenbrock%nagler-company.com@localhost wrote:
 
 >      - no upper limit for the number of threads - an easy aproach may be the 
 > number of CPU's available
 >      - curently the threads are not bound to a CPU, they switch between 
 > them. But I simple do not know how to fix them to a 
 >        CPU and I'm not shure how to decide to which CPU it should be bound.
 
 I'm not sure if others will agree but perhaps that a default or limit
 of one or two  thread(s) per CPU would be allright.  For tieing those
 threads to specific CPUs, in userland there's AFFINITY(3) for that,
 which internally uses the _sched_setaffinity(2) syscall,
 sys__sched_setaffinity() in src/sys/kern/sys_sched.c which sets the
 flag and ties a cpuset with the lwp.  That syscall obviously doesn't
 allow to do this on system threads, but it could be from a security
 standpoint rather than a limit of the system threads capabilities.
 
 Thanks,
 -- 
 Matt