Hi Donald,
On Thu, 24 Aug 2000, Donald Becker wrote:
> On Thu, 24 Aug 2000, Marcell Gal wrote:
>
> > Alan says the Nicstar ATM card has HW support for [369]00 us INT delay.
> > Any ethernet cards known to have similar smart features?
>
> The 21143 is a common, low-cost example.
> All gigabit Ethernet boards have some sort of mitigation.
>
> > Is anything like this configurable for some ethernet drivers, has
> > anyone done some successful or unsuccessful experiments with this?
>
> See the work by Josip Loncaric in the Tulip mailing list achieve for a
> write-up on the 21143 mitigation.
>
> I've also done experiments, but the result have usually gone directly into
> the drivers. I've learned that writing up the results is usually wasted
> time: A few years ago I did profiles of the typical transmit queue length
> and packet dwell period. I wrote up the results, complete with charts and
> graphs and Xs and Os on the back, but no one on the driver mailing lists was
> interested. It's pretty mundane topic, and wouldn't make a substantial
> conference paper. So now I just use the final numbers.
>
I will be interested and i think it would make a good Linux conference
paper at least.
BTW, i couldnt find Josip Loncaric's thread on this ... do you have a
specific URL? (in any case that piece of code hasnt been propogated to the
current 2.4 tulip driver; small patch below)
In my experimentation, i found that hard-coding a specific mitigation
value was not a very good idea because the ideal value really depended on
the system/network load. So, i devised a dynamically adjusting
mitigation value which is selected based on how overloaded the system is
(stolen from TCP and based on observing tulip_max_interrupt_work
history).
I didnt spend a lot of time really tuning this so there could be better
ways of doing this ...
Of course this is the stuff i presented on at the OLS (amongst other
things); i'll post a 2.4 patch on the least controvesial pieces when i get
the time (maybe in the next week or so).
I am interested in Josip's reasoning though.
cheers,
jamal
The tulip patch
--------
--- interrupt.c 2000/08/19 16:01:20 1.1
+++ interrupt.c 2000/08/25 11:19:32
@@ -314,12 +314,11 @@
oi++;
}
if (csr5 & TimerInt) {
-#if 0
+
if (tulip_debug > 2)
printk(KERN_ERR "%s: Re-enabling interrupts,
%8.8x.\n",
dev->name, csr5);
outl(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
-#endif
tp->ttimer = 0;
oi++;
}
@@ -327,14 +326,19 @@
if (tulip_debug > 1)
printk(KERN_WARNING "%s: Too much work during
an interrupt, "
"csr5=0x%8.8x. (%lu) (%d,%d,%d)\n",
dev->name, csr5, tp->nir, tx, rx, oi);
- /* Acknowledge all interrupt sources. */
-#if 0
- /* Clear all interrupting sources, set timer to
re-enable. */
- outl(((~csr5) & 0x0001ebef) | NormalIntr | AbnormalIntr
| TimerInt,
- ioaddr + CSR7);
- outl(12, ioaddr + CSR11);
- tp->ttimer = 1;
-#endif
+
+ /* Acknowledge all interrupt sources. */
+ outl(0x8001ffff, ioaddr + CSR5);
+ if (tp->flags & HAS_INTR_MITIGATION) {
+ /* Josip Loncaric at ICASE did extensive experimentation
+ to develop a good interrupt mitigation setting.*/
+ outl(0x8b240000, ioaddr + CSR11);
+ } else {
+ /* Mask all interrupting sources, set timer to
+ re-enable. */
+ outl(((~csr5) & 0x0001ebef) | AbnormalIntr |
TimerInt, ioaddr + CSR7);
+ outl(0x0012, ioaddr + CSR11);
+ }
break;
}
} while (work_count-- > 0);
@@ -366,4 +370,3 @@
dev->name, inl(ioaddr + CSR5));
}
-