On Thu, 14 Sep 2000, jamal wrote:
> On Thu, 14 Sep 2000, Andrew Morton wrote:
> > But for 3c59x (which is not a very efficient driver (yet)), it takes 6
> > usecs to even get into the ISR, and around 4 uSecs to traverse it.
> > Guess another 4 to leave the ISR, guess half as much again for whoever
> > got interrupted to undo the resulting cache pollution.
> >
> > That's 20 usec per interrupt, of which 1 usec could be saved by skb
> > pooling.
>
> With these numbers + how long it takes to queue the packets in
> netif_rx(); i would say you roughly should be able to tune your DMA
> ring appropriately.
>
> Roughly your DMA ring should be able to hold:
>
> (PCI_Burst_bandwidth*((20*10-6)+pci_bus_latency))) bits.
>
> Did i hear Donald say something? ;->
No, because I know I sound like a broken record. <skip><skip>
What we measured is that the cache impact of allocating and initializing our
(ever-larger) skbuffs is huge. So we pay some CPU time getting a new
skbuff, and some more CPU time later reloading the cache with useful data.
The skbuff is added to the end of the driver Rx buffer list, so the memory
lines are out of the cache by the time we need them.
The Rx ring should be able to hold at least
(interrupt-latency * 100/1000Mbps) bits
and
(interrupt-latency * 100/1000Mbps)/(64 bytes/packet * 8 bits/byte) packets
> > If you don't do Rx interrupt mitigation there's no point in event
> > thinking about skb pooling.
>
> FF does not use mitigation and as Robert was pointing out this was adding
> a lot of value.
The PCI drivers make some effort to always allocate the same size skbuff, so
recycling skbuffs, or otherwise optimizing their allocation, is useful.
The only significant advantage of interrupt mitigation is cache locality
when allocating new skbuffs, and having an additional mechanism to drop
packets under overwhelming load.
The disadvantage of Rx interrupt mitigation is adding latency just where it
might matter the most. Remember that the hot ticket for old-IPX performance
was taking an *extra* early interrupt for each Rx packet.
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution
Annapolis MD 21403
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:24 EST