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