Re: ixgbe and fast interrupts

On Fri, Nov 18, 2011 at 11:16:00AM -0800, Doug Barton wrote:
> On 11/18/2011 09:54, Luigi Rizzo wrote:
> > One more thing (i am mentioning it here for archival purposes,
> > as i keep forgetting to test it). Is entropy harvesting expensive ?
> 
> No. It was designed to be inexpensive on purpose. :)

hmmm....
unfortunately I don't have a chance to test it until monday
(probably one could see if the ping times change by modifying
the value of kern.random.sys.harvest.* ).

But in the code i see the following:

- the harvest routine is this:

    void
    random_harvest(void *entropy, u_int count, u_int bits, u_int frac,
	enum esource origin)
    {
        if (reap_func)
                (*reap_func)(get_cyclecount(), entropy, count, bits, frac,
                    origin);
    }

- the reap_func seems to be bound to

    dev/random/randomdev_soft.c::random_harvest_internal()

  which internally uses a spinlock and then moves entries between
  two lists.

I am concerned that the get_cyclecount() might end up querying an
expensive device (is it using kern.timecounter.hardware ?)

    > sysctl -a | grep timecounter
    kern.timecounter.tick: 1
    kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000)
    kern.timecounter.hardware: ACPI-fast

So between the indirect function call, spinlock, list manipulation
and the cyclecounter i wouldn't be surprised it the whole thing
takes a microsecond or so.

Anyways, on monday i'll know better. in the meantime, if someone
wants to give it a try... in our tests between two machines and
ixgbe (10G) interfaces, an unmodified 9.0 kernel has a median ping
time of 30us with "slow" pings (say -i 0.01 or larger) and 17us with
a ping -f .
BTW the reason for the difference is totally unclear to me (ping
-f uses a non-blocking select() but i don't think it can explain
such a large delta).

	cheers
	luigi