Re: rbuf starvation in the iwn driver

[David Young <dyoung%pobox.com@localhost>]

On Wed, Apr 07, 2010 at 11:30:24AM -0600, Sverre Froyen wrote:
> On Tue April 6 2010 06:26:10 Manuel Bouyer wrote:
> ...
> > What is doing this driver looks somewhat wrong to me.
> > It can use its rbufs as external mbuf storage, and pass this to the network
> > stack, as long as there's enough free rbufs. When the number of free rbufs
> > is below the limit, it should stop giving them to the network stack,
> > and copy the received data to a ordinary mbuf cluster instead.
> > See for example if_nfe.c:
> 
> I've been looking at the iwn_rx_done code to see how I can fix this. One 
> option 
> is to use the code from iwn_rx_intr in if_iwn.c rev 1.32 (I presume I can 
> figure out the needed bus_dmamap changes by looking at if_nfe.c).
> 
> However, it looks like the current OpenBSD and FreeBSD drivers do not use 
> private storage. FreeBSD just gets an mbuf cluster from m_getjcl and OpenBSD 
> uses MCLGETI. Is this an option for NetBSD? Why was private storage used in 
> the first place? For speed reasons? Damien Bergamini warned me there would 
> likely be alignment issues.

Based a cursory scan of the code, iwn(4) provides a 4kB,
physically-contiguous Rx buffer to the firmware, i.e., a buffer large
enough to fit an 802.11 aggregate packet (A-MPDU).  Don't OpenBSD and
FreeBSD provide the firmware with 4kB Rx buffers, too?  On most (all?)
NetBSD architectures, an mbuf cluster is just 2kB, so MCLGET() won't do.
I wouldn't trust MEXTMALLOC() to return a physically-contiguous region.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933