From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 1 05:43:13 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32D541065702 for ; Mon, 1 Oct 2012 05:43:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E64DF8FC16 for ; Mon, 1 Oct 2012 05:43:12 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so4742505obb.13 for ; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ZQrDuJAIxxsy1ZAYMdFLiuvavEmj5CZ3uYqyk6R2hYo=; b=iWvR3LzcTkkZfMxowPjG1Mq4Lb++5c7AP9/qpcMk/o/gEbi2hGwOzUtylZ9lrMbxCv eLKdVy+w8SAgpI6y8MAN31pgcgW5kvHvPbBPLgQObQsO5HFOw01L3cuSJi9yg9H+TnCV 6ELOSm+sKkv6I0NsZbims9/UrvIoJTqVT6+NT5aLVEstHIDlLmpXXR5Z6e1jABGvUKji GdcENvO77Eq0X6Zn5OHCJtSiooFgB5wzzLbg1Zl9nbdG6BUqMbhw6BVlARwuMKIISY1R FlKYpOXTo0Qd1XOvYyLMLyN0+ZjSFDhXXbWi7d4Grkh1w4QnVd7BaIny8drGWDmZBzZz uNpA== MIME-Version: 1.0 Received: by 10.60.20.8 with SMTP id j8mr10742426oee.127.1349070192278; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.8.98 with HTTP; Sun, 30 Sep 2012 22:43:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 Sep 2012 22:43:12 -0700 X-Google-Sender-Auth: xTKaDtg29N8RTpKv8qKYC1h5v4E Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [RFC] Methodize the net8021 power save hooks X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 05:43:13 -0000 .. oh and I should add: * Review all the MORE bit uses with traffic in the PSQ and the software queue when leaking frames out via PS-POLL. That's complicated as it has to check all TIDs for the existance of frames to TX, rather than a specific TID/AC. Adrian On 30 September 2012 22:39, Adrian Chadd wrote: > Hi, > > I'm about to start tinkering with ath(4) power save support and I'd > like to introduce some net80211 changes to support this. > > * Methodize the STA and node power save functions, so the driver can > stop/start the software queues as needed; > * Push PS-POLL frame leaking into a method, so the driver can override > this if something is in a local queue. > > Since the driver may have some software queued frames for it, the > driver needs to be able to leak these frames out correctly before the > power-save queue frames are transmitted. > > My initial change to ath(4) will be to pause and unpause the node when > the net80211 stack calls iv_node_ps() so the driver doesn't bother > transmitting to a node that's asleep. > > There's a bunch of other needed changes that I'll then do in some > follow-up work: > > * The TIM/ATIM doesn't know about what's in the software queue, so I'm > going to have to introduce some further methods to allow the driver to > update the TIM/ATIM as needed; > * There's a M_PWR_SAV mbuf flag that means "this came from the power > save queue". I need to see what/how drivers should treat this; > * When a frame is sent via the PS-POLL method whilst a STA is asleep, > the TIDs may be paused and as such the node won't transmit. In this > case, frames pushed from the power save queue to the driver should > immediately be transmitted, rather than punted to the software queue. > * I also need to verify that the CABQ traffic is being set correctly- > ie, the CABQ traffic all has the MORE bit appropriately set or > cleared. > * For nodes that are being sent PS-POLL (and later, uAPSD) delivered > frames, they should be put "next" on the TX queue, ahead of any other > TIDs that are being scheduled. That way their frame goes out next (or > has a good chance to), versus being behind all the other currently > transmitting (but not in power save) nodes. This should allow the > device to quickly receive the frame and go back to sleep. > I'm going to leave the next set of changes until I've done the first > bit of work and verified it's working. I'll likely make that behaviour > configurable because I'm worried that the incomplete PS-POLL upgrades > will break mobile devices that try to stay in PS-POLL and "leak" > frames (versus things like my MBP that just go in/out of power save > and don't use PS-POLL at all.) > > > > adrian