Re: sk: jumbo buffer

["Sepherosa Ziehau" <sepherosa@xxxxxxxxx>]

On 11/29/06, Matthew Dillon <dillon@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