sk: jumbo buffer

Sepherosa Ziehau sepherosa at gmail.com
Tue Nov 28 17:48:58 PST 2006


On 11/29/06, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
:Nov 28 14:44:58 fw kernel: sk0: no free jumbo buffer
:Nov 28 15:00:49 fw kernel: sk0: no free jumbo buffer
:Nov 28 15:59:45 fw kernel: sk0: no free jumbo buffer
:Nov 28 17:47:49 fw kernel: sk0: no free jumbo buffer
:Nov 28 17:54:40 fw kernel: sk0: no free jumbo buffer
:Nov 28 19:42:04 fw kernel: sk0: no free jumbo buffer
:Nov 28 21:44:48 fw kernel: sk0: no free jumbo buffer
:Nov 28 21:51:38 fw kernel: sk0: no free jumbo buffer
:Nov 28 22:25:26 fw kernel: sk0: no free jumbo buffer
:Nov 28 22:30:53 fw kernel: sk0: no free jumbo buffer
:Nov 28 22:33:50 fw kernel: sk0: no free jumbo buffer
:Nov 28 22:36:12 fw kernel: sk0: no free jumbo buffer
:
:I think the problem is that we are testing a gigabit module with one of
:the NICs, while the other (also Marvell) card is on 100FD - that's why I
:posted this here instead of the bugtracker. Am I right?
    I think it's just occassionally running out of jumbo buffers from
    its fixed pool.  In fact I see a problem generally with the
    implementation, that being that a jumbo buffer's mbuf can remain 'stuck'
    in a socket buffer for a long time before it gets freed.
We can handle it this way:
1) jumbo ring is still created during attaching, but in addition we
create a bunch of dmamap for RX mcluster on attach patch too
2) in ifnet.if_init()'s RX buffer initialization, if ifnet.if_mtu >
(ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN) then we use jumbo ring,
else we use mcluster.
I will give you a patch to try either today or tomorrow.

Best Regards,
sephe
--
Live Free or Die




More information about the Users mailing list