Le jeudi 06 janvier 2011 Ã 18:13 -0800, Luis R. Rodriguez a Ãcrit :
> On Thu, Jan 6, 2011 at 6:07 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> The only way to accept your patch is to use a debugfs option to
> disable it, we need AMSDU support enabled by default.
>
I dont care of my patch ;)
There is a reason I felt it was not appropriate.
> > If the hardware needs 8192 bytes (or 16384) buffers to perform its
> > operation, it should not give them back to linux, because there is no
> > guarantee it can allocate fresh ones for the next frames.
>
> Last I looked at this the issue was not the upper used by the driver
> but an issue of a roundoff by the kernel that ended up on *some*
> machines going a higher order. Not all machines use the higher order.
> I wondered at one point if using ksize() might help here too but
> again, this is a new API. Not sure how to fix it for older kernels.
common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
ah->caps.rx_status_len,
min(common->cachelsz, (u16)64));
Given IEEE80211_MAX_MPDU_LEN is more than 3840, and skb shinfo adds more
than 256 bytes, I can assert rx_bufsize is greater than 4096 : order-1
allocations at minimum.
ksize() wont help you.
Many net drivers perform a copy (r8169.c comes to mind, because of a
hardware flaw).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
