From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 29 03:43:24 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DFCBD7D for ; Mon, 29 Oct 2012 03:43:24 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm29-vm6.bullet.mail.gq1.yahoo.com (nm29-vm6.bullet.mail.gq1.yahoo.com [98.136.216.181]) by mx1.freebsd.org (Postfix) with ESMTP id B7D418FC18 for ; Mon, 29 Oct 2012 03:43:23 +0000 (UTC) Received: from [98.137.12.188] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 Received: from [208.71.42.208] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 Received: from [127.0.0.1] by smtp219.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1351482196; bh=ifpcIiW55wLwBqyTqcAYkIvvIRYtPZAF7e12E/Tof6M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=w5kIi6s1FskAfPsFGJJNLH/fhxtmC+/enk/qABEmeZtymoQUvczLexvjAZhpNEfnrDD7VpC6Nzm7rQKgyuuZg5Rmp1+yv3VVEHo10QeUGqRvKQkp5h6D9LUjPOPDyN4UNC2rUR1rFZXJ3dCdvAOJrWTeoD5QVkWS/BM9rTy7jqo= X-Yahoo-Newman-Id: 538426.35644.bm@smtp219.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aNQbV10VM1nE8rtzqacKdq3yhdzyPmDpIUNLtROR3ElaVvH vYfKiAfctFBAfZcdrqXbdrzGT89gGtw9amossiuBPyd7DqrVmyHP4r1jNdBM apORDQuCzQFOHXTyxQ6mqkFH_aXPiyin5H3If7o0wdVXhuPBMS5exSdqMvc4 9QThc1Mwgrf0gQ62c1sPAYKVVL1FOhBhOCBR3oz2H4qkbPvpPv0d7HmY.DI1 xnws2FUaTI.fM6Dsu8UaTPi1MRSf2t.hJ82R.GJDHPB..H1LHZ23Hjmo0Vkm wsZ6C_drna8jjUIGkQHuEhEUJ5eKrYzZYuBqXOzwWOrBzaBnJMmO0ZGOv2BQ grPhM8kyssQyZynxAyBCJF8VxLOxnTRC8h.B_jq.8bSpZtfIZnseh38cEJOw 1wfXF3RcIB.gCbMqIGrJ2ZKxVgjihP1QUclYWuWT1tUtWiKGtZrVhdfpqCd. Zw0v9V_9FJ7LVJ4rzJe5LWMOpHzAZDkgklULDI6G9IbtxAboHXgLHO_RAm6Q HNtVhj11HE5Jw X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp219.mail.gq1.yahoo.com with SMTP; 28 Oct 2012 20:43:16 -0700 PDT Received: by mail-vb0-f54.google.com with SMTP id l1so1074477vba.13 for ; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.33.229 with SMTP id u5mr256765vei.0.1351482195306; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) Received: by 10.58.182.72 with HTTP; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) Date: Sun, 28 Oct 2012 21:43:15 -0600 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: PseudoCylon To: Adrian Chadd , freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-arch@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 03:43:24 -0000 > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 27 Oct 2012 16:18:11 -0700 > From: Adrian Chadd > To: freebsd-wireless@freebsd.org > Cc: FreeBSD Net , freebsd-arch@freebsd.org > Subject: request for help: 'fixing' the 802.11 TX path > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > > I'd like to try and sort out the last remaining niggles in the 802.11 > code - this email is focusing on the TX path. > > The TX path has a few problems: > > * there's a normal versus raw TX path (for raw frames, management > frames, etc) - the raw path doesn't necessarily queue frames into the > raw TX queue, so it's a kind of "side path" to the driver. This causes > frame ordering problems with things like sequence number allocation. > * there's limited locking in the TX path, primarily because you can't > _really_ fine grain lock the TX path. Since you have multiple TX > thread contexts all sending into the same driver queue and that queue > has to share incrementing sequence number, aggregate status and CCMP > encryption replay counters, you _have_ to either use some long-held > mutexes to enforce this _or_ throw all sending into a TX thread and > run that. > * raw TX requires some extra state to be glued (the bpf_params info); > I'd like to glue that into mbufs as an option, so the driver can use > those instead of interpreting their own 802.11 header contents. > > And the one I'd like to discuss here: > > * Fragment transmission is totally broken and causes mbufs to be just > leaked. The problem with sending fragments (at least for the ath > drivr) is the packet duration calcluation requires the _next_ fragment > to be available. > > Now, this is a design hold-over from the previous, pre-vap scheme. The > driver netif would be handed a raw mbuf frame, which it would then > pass through the net80211 encapsulation code and that would > potentially generate 802.11 fragments. The rest of the driver TX path > would then see that it was handed a fragment list and TX those. > Fragments were chained together using m_nextpkt, like a normal mbuf > list. > > This doesn't happen any longer. The net80211 vap gets the raw frame, > which then sends that to the driver netif after doing the vap and > 802.11 state / encapsulation work. But since all the wifi drivers use > if_start() right now, m_nextpkt gets blanked on both encap and decap.. > and thus things leak. > > Now I can't really see a way around this, without doing dirty hacks > with mbuf attributes to link the fragments together. The only clean > way I can see is to force all wifi drivers to use if_transmit(), and > then have if_transmit() interpret a chain of frames as "the fragment > list." Cannot we just add custom hand off function to ieee80211_start()? ieee80211_start() { encap; IF_LOCK(parent->if_snd); do_seqnum_stuff; /* We can also queue mgt packets to the same queue */ for (m0 = m; m0->m_nextpkt != NULL; m0 = m0->m_nextpkt); ifq_tail = m0; IF_UNLOCK(); taskqueue_enqueue(taskqueue, parent->if_new_tx_function); /* or wake(); */ } Because of IF_LOCK, queued packets and seq num should be in order. Then, the driver only need to dequeue and Tx. The drivers can tell if the packet is a fragmented packet or a standalone packet from ieee80211 header or we can add a new member to bpf_params. AK