svn commit: r307082 - in head: . sys/amd64/conf sys/arm/conf sys/arm64/conf sys/conf sys/i386/conf sys/mips/conf sys/modules/cc sys/modules/khelp sys/netinet sys/netinet/tcp_stacks sys/pc98/conf sy...

[Jonathan Looney]

On Wed, Oct 12, 2016 at 5:44 AM, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:

> Do you perform estimate of performane impact of this overhead?
>
>
Somewhat, but not precisely. It will depend on (at least) a few factors:

a. The hardware
   * How fast is your CPU? Your L1/L2/L3 cache?
   * How many CPUs?
   * How smart is the hardware prefetching?
   * How fast is the memory bus?
   * etc.
b. Whether VNET is enabled
   * If VNET is enabled, the hook lookup will require more instructions to
     find the correct list
c. Which TCP stack you are using
   * The hook lookup is implemented as an external function in the
     non-default stacks, so that requires the overhead of a function call
d. The probability that the number of hooks is in your CPU cache
   * This is a combination of the hardware and the exact workload on the
     device

On a test system running a fairly heavy load of TCP traffic using the
default TCP stack, without VNET, and without any TCP hooks installed, the
input/output hhook functions accounted for approximately .075% of the
"busy" CPU cycles during one of my measurements. That certainly is not a
large number, but it is large enough to be measurable. And, I think the
hardware I used for the measurement is tuned for high-performance, so
this may be close to the "best case" measurement.

I suspect that systems with a large number of short-lived sessions will
see a larger improvement from the deletion of khelp_init_osd() from the
session setup path. (I didn't measure this.)

I also suspect that systems with VNET will see a larger improvement.

I also suspect that systems with slower memory busses, smaller caches,
etc. will see a larger improvement.

But, this is very hard to measure precisely in a generic sense. The one
concrete thing we *can* measure is that the functions add some number
of instructions to the session setup, session teardown, input, and
output code paths. If you need those instructions to achieve the desired
functionality (in this case, probably a congestion-control algorithm),
then you probably want those instructions. If not, then you may want to
delete them. This was the impetus to add a kernel option to give you
the ability to decide whether you want to include the functionality.

I hope this answer helps explain some more about the change.

Jonathan