Re: Info on SKbuf....

From: Jes Sorensen (Jes.Sorensen@cern.ch)
Date: Thu Apr 20 2000 - 03:36:12 EST


>>>>> "Donald" == Donald Becker <becker@scyld.com> writes:

Donald> I think that there is a more significant performance
Donald> improvement to be had than just recycling (which *does* help a
Donald> lot). I have experimented with recycling combined with
Donald> separating the skbuff head from the data. A packet is
Donald> received into a FIFO of data buffers, and then associated with
Donald> a LIFO of skbuff heads. The idea is that a few skbuff heads
Donald> are always "hot" in the cache, mitigating the large expense of
Donald> initializing the fields, and the data buffers will be given
Donald> time to cool off before being written by the PCI bus master.

Donald> Another improvement I've considered is allowing the skb free
Donald> code to "push" the buffer back to the driver. The driver
Donald> would have low and high Rx buffer count thresholds. At the
Donald> dynamically-increased low threshold it would "pull" new
Donald> buffers, as it currently does. This might not be much of a
Donald> win over a clever, cache-aware allocator.

I tried this some time ago with the AceNIC Gigabit Ethernet driver and
the performance increase I originally saw totally vanished when I
applied Ingo's per-cpu slab cache patch.

Jes

-
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/



This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:16 EST