Sorry for the quite long non-response period, and thank you
for your reply.

From: Takahiro Igarashi <thir@thir.org>
Subject: Re: device polling system
Date: Fri, 30 May 2003 23:19:17 +0900 (JST)
Message-ID: <20030530.231917.104578289.tigara@pop02.odn.ne.jp>

 > thank you for your interest.
 > 
 > > Hayakawa Koichi <haya@arch.sony.co.jp> wrote
 > 
 > >  * How many clock interrupts per second (hz value)?
 > 
 > 024, I use.

Did you mean 1024?

 > >  * Did you measure TCP/IP performance?
 > 
 > What I use for benchmarking is now only spray, so the answer
 > is no.
 > 
 > I'm recognizing the short of test tool, so I'll select or
 > make them.

I'm interesting in performance, especially TCP performance,
under low polling rate, such as 128 per second.

 > > I suppose, for the first step, making generic polling
 > > interrupt handler, without NIC driver changes, is better.
 > 
 > To see my patch tells NIC dirver changes are small, add
 > polling handler and some code to enable polling.

I mean that generalised approach is better than 'special
magic only for ethernet controllers' approach.  Of course,
this attempt is interesting for me, especially as good
experiments.

 > And I'm now rewriting the kern_poll.c, main routine polling
 > system.  What my patch did in both netisr_poll and
 > netisr_pollmore is called by new polling system as polling
 > handler.  What would you say this one?

No.  Please refer to the comment just above.

 > > Do you consider sporadic server or some kind of similar
 > > handler on NetBSD?
 > 
 > Sorry for my English skill. I don't understand what you say
 > by this.  Would you explain it to me?

What I mean is, do you consider implementing generic
interrupt scheduler, such as sporadic server, or similar
scheme?