lkml.org 
[lkml]   [1998]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PCI_LATENCY_TIMER brain-damage in net drivers.
Hello,

> The code said:
> - > 10 is reasonnable
> - <= 9 is not and shall be changed to 255.

This algorithm is certainly not ideal, but it seems that its author has
intended it to work this way: Latency values larger than 10 seem to be set
by some piece of software which knew what it was doing and it should be
therefore left as is. Latency values less than this limit are brain-damaged
and should be set to something sensible.

In this case, 255 is not an ideal value -- if you look at pci_set_master()
(which is now the preferred way how to cope with CFLT setting), you will see
it sets everything less than 16 to 64.

> If PCI gurus are ok about a 30 micro-second PCI latency being good for a
> system, and claim that this code actually fixes-up something, then I have
> nothing more to add to this thread.

In most cases, bandwidth is IMHO more important than latency. On the other
hand, the value of 64 should give both good throughput and acceptable latency
except for few marginal cases when users can use setpci for fine tuning.

The best way to cope with this problem is probably to ask Donald if he can
modify his drivers to use pci_set_master() on 2.1 kernels.

Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Ctrl and Alt keys stuck -- press Del to continue."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.692 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site