Re: Info on SKbuf....

From: Donald Becker (becker@scyld.com)
Date: Thu Apr 20 2000 - 01:00:21 EST


Ashok Raj wrote
>> driver allocates skbuf, copies data and returns to upper layer calling
>> netif_rx(). After consumption seems that that is returned back to the free
>> pool. Are there any implementations that allow returning the skbuf back to
>> the driver for reclamation? for some interfaces that needs registration of

Dave Miller wrote
>The reason we can't easily just "give it back" to the driver
>is that we must hold onto the packet until the application
>actually reads the data from the socket receive queue.

I think what Raj is asking for is a quick recycle of the fully freed skbuff
back to the device for which it was initially allocated, rather than putting
it in a general free pool.

We've measured where the cycles are being taken in the device drivers. Much
of the time is taken in cache misses during skbuff management, especially
allocation. My device drivers go to some effort to always allocate the
same size skbuff, so it's pretty unreasonable to just toss the memory into
the general free pool.

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

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

Donald Becker becker@scyld.com
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403

-
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