Return-path: Received: from mail.candelatech.com ([208.74.158.172]:37683 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753209Ab1AGWU4 (ORCPT ); Fri, 7 Jan 2011 17:20:56 -0500 Message-ID: <4D2791BD.7050502@candelatech.com> Date: Fri, 07 Jan 2011 14:20:45 -0800 From: Ben Greear MIME-Version: 1.0 To: Eric Dumazet CC: "Luis R. Rodriguez" , Johannes Berg , "ath9k-devel@venema.h4ckr.net" , "linux-wireless@vger.kernel.org" Subject: Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page. References: <1294361165-15308-1-git-send-email-greearb@candelatech.com> <1294397880.3467.1.camel@jlt3.sipsolutions.net> <4D275CCC.90905@candelatech.com> <20110107200913.GF21588@tux> <1294432018.2709.2.camel@edumazet-laptop> In-Reply-To: <1294432018.2709.2.camel@edumazet-laptop> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 01/07/2011 12:26 PM, Eric Dumazet wrote: > Le vendredi 07 janvier 2011 à 12:09 -0800, Luis R. Rodriguez a écrit : >> 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, greearb@candelatech.com wrote: >>>>> From: Ben Greear >>>>> >>>>> Patch is from Eric Dumazet, as described here: >>>>> https://patchwork.kernel.org/patch/104271/ >>>>> >>>>> Reported-by: Michael Guntsche >>>>> Signed-off-by: Eric Dumazet >>>>> Signed-off-by: Ben Greear >>>>> --- >>>>> >>>>> 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. > > > Using skb_copy() is wrong then, since it makes a copy (order-1 > allocations) > > It should use : > skb_alloc( actual_size_of_frame not the 3840 thing ...) > copy(data) We need the extra stuff copied too I think (like skb->cb). If you could provide a bit more complete example code, I'll be happy to test it... Thanks, Ben > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com