On Fri, Jan 07, 2011 at 10:34:52AM -0800, Ben Greear wrote: > On 01/07/2011 02:58 AM, Johannes Berg wrote: > > On Thu, 2011-01-06 at 16:46 -0800, [email protected] wrote: > >> From: Ben Greear<[email protected]> > >> > >> Patch is from Eric Dumazet, as described here: > >> https://patchwork.kernel.org/patch/104271/ > >> > >> Reported-by: Michael Guntsche<[email protected]> > >> Signed-off-by: Eric Dumazet<[email protected]> > >> Signed-off-by: Ben Greear<[email protected]> > >> --- > >> > >> NOTE: This needs review by ath9k and/or other informed > >> people. > > > > This doesn't make sense. It might help, but it'll probably lead to not > > being able to receive all frames off the air. > > > > If this is an issue, ath9k should do paged RX like iwlwifi. > > Ok, I backed this out..but now I'm back to getting buffer allocation > failures (and this is on a system with 2GB RAM). > > Seems it's coming from mac80211 instead of ath9k, at least most of > the time (I'm using 60 stations, so it probably needs to make lots of > copies in the rx path). The traffic I'm generating/receiving is 1024 byte UDP > payloads. > > Does this mean I really received a packet that was 3872 bytes long, > or is the skb_copy allocating/copying empty data?
Good question. The buffer we setup for DMA should be large since we need to support AMSDU RX up to a certain bytes of RX data for the frame. Harwdware should tell us the right size for the RX'd data and the skb should be set with that size, respectively. Following this logic, skb_copy() should only allocate on the order of the required skb->len. Remember that trick we did to force the older memory leak issues by forcing an skb_copy() on every RX'd frame and then just discarding that buffer immediately? You can try to do the same and print the skb->len there, just to check what's going on. Luis _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
