On Thu, Nov 25, 2010 at 12:30:39PM +0000, Owain Ainsworth wrote:
> On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> > On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > > > and I would really like to see this going in.
> > > > 
> > > > netisr needs to be made a normal C function and not this madness it
> > > > currently is. This is necessary to imporve the packet scheduling.
> > > > 
> > > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > > 
> > > hi,
> > > 
> > > i like the diff, but why not get rid of netisr_dispatch.h?
> > 
> > I planned to this after this diff goes in. I did not want to change
> > Owain's initial diff too much so I left that out for now.
> 
> My diff needed some tweaking anyway.
> 
> Miod pointed out to me when I first sent this out that some archs use
> something slightly different than this generic version.
> 
> For example hppa uses a specially aligned netisr variable so it can use
> the pa-risc real atomic instructions which are quite a bit faster.
> 
> Similarly x86 uses compare-and-swap instead of test, then clear bits.
>
> I meant to add some MD defines so that this could be kept (falling back
> to the implementation in this diff)  since miod claims that it is useful
> and significantly faster (I did not check this). I've cced miod so he
> can answer with somewhat more authority.
> 

This is all nice and so but the main reason for me to get the netisr code
into a pure c form is that we need better netisr scheduling. There are
some rather nasty effects because of the current way netisr works and it
has nothing todo with optimising the netisr bitfield itself. 
Some quick tests showed that netisr is causing a >25% drop in forwarding
performance. So fixing netisr and the protocol queues can have a very huge
impact on performance.

If somebody has a good way to allow netisr.c to have MD defines in a clean
way then go for it. I doubt that there is a measurable performance
difference on i386/amd64.

> > 
> > > also i'm not sure, but maybe netisr.c copyright should be
> > > attributed to berkeley as we're using their code directly?
> > 
> > Are we? The current netisr.c code is a generic implementation of using
> > softinterrupts to run the netisr and in the future it will get even more
> > different.  Owain, what do you think? 
> 
> I think my initial mail possibly mentioned that I was unsure if the
> original was needed. Put the original one in there as well if you are
> unsure. I won't try and claim that I'm positive that it was entirely my
> code (too long ago for a start ;).
> 
> Anyway, thanks for taking over this diff, claudio. I'm far too busy
> right now to sort it out.
> 

OK, I will kill netisr_dispatch.h. Diff follows...

-- 
:wq Claudio

Reply via email to