[Top] [All Lists]

Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5

To: kuznet@xxxxxxxxxxxxx
Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sun, 7 Oct 2001 08:11:27 +0200
Cc: adilger@xxxxxxxxxxxxx (Andreas Dilger), Robert.Olsson@xxxxxxxxxxx, mingo@xxxxxxx, hadi@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, bcrl@xxxxxxxxxx, netdev@xxxxxxxxxxx, torvalds@xxxxxxxxxxxxx, alan@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200110051917.XAA23007@xxxxxxxxxxxxx>
References: <20011005124824.F315@xxxxxxxxxxxxxx> <200110051917.XAA23007@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
kuznet@xxxxxxxxxxxxx writes:

 > "some hysteresis" is right word. This loop is an experiment with still
 > unknown result yet. Originally, Jamal proposed to spin several times.
 > I killed this. Robert proposed to check inifinite loop yet. (Note,
 > jiffies check is just a way to get rid of completely idle devices,
 > one jiffie is enough lonf time to be considered infinite).

 And from our discussion about packet-reordering we get even more motivation
 for the "extra-polls" not only to save IRQ's 

 We may expand this to others too...

 As polling-lists are per CPU and consecutive polls stays within the same
 CPU the device becomes bound to one CPU. We are protected against packet 
 reordering as long there are consecutive polls.

 I've consulted some CS people who has worked with this issues and I have
 understood packet reordering is non-trivial problem at least with a general 

 So to me it seems we do very well with a very simple scheme and as I 
 understand all SMP networking will benefit from this.

 Our "field-test" indicates that the packet load is still well distributed 
 among the CPU's.

 So maybe the showstopper comes out as a showwinner. :-)



<Prev in Thread] Current Thread [Next in Thread>