From owner-freebsd-wireless@FreeBSD.ORG Mon Oct 29 17:38:14 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 B4633C3D for ; Mon, 29 Oct 2012 17:38:14 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by mx1.freebsd.org (Postfix) with ESMTP id 562928FC15 for ; Mon, 29 Oct 2012 17:38:14 +0000 (UTC) Received: from [98.138.90.55] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 Received: from [98.138.226.31] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1351532287; bh=LM9cqYzZn55ZOV7/b3pl/8d+o4VoguqXOvn7kj4rCAI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=TF7Xu/QO6X63h9Z4ySNSgR1dCzfqxezXHmMf+foO2o3vSVEU0/mh9WdpdpZw/L2Ak5SjxpiDXSYigYb1c2IkXQ96yFFqtx1KOJj8AzE0sFcBn7VY059sPko691wV6nasXGAAMhAcjzQAx/T/1MlcvHjMTF4JM8/QYRB1NFRIaI0= X-Yahoo-Newman-Id: 653555.32931.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8zBtlvMVM1ny58J_AnS7cI97H1NarIBQwK6o4iTzjokaJSP ZaJHGjXBt7xXF3K7X02xwvmi38VLgOtcr3NpG7wK6ymgcgKa5I2rnwyTiVAc nUdS4xBa_eWVAcv7n8_x0z9HrBcLBRBIHJvcw8iF3KD8ssduhCQSkcKlfZH9 GFnsiOWw3_KbiGtBJHnmzJ8rtcVl9HXiJduBvPNFmrc15rM_x.cw5vDreuj. vBH_FMV5Tu7s38lLnx2tLYvbQv9_x2vX1sKVBhdcap_rJaR2u7XtdLwNGGgE OiYrd1kXcbre8hUbpKQ8oCAnrfp_QXqxCCTwa5XMUpfTwAXO5zG.6Q_rIL06 Tg8yTOTP3U2WD_OqUfHjzjK_CxlPsp_FWrW5Pg3Hev62ArLZtihtWqbZ17fE nWMZRoCNLlC5FKukcUxCskSmlNFytNAdPvq.qhXayPHHALNuke69iaWLTYeU W4YoGY2oU1TUikTVmnFA- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp202.mail.ne1.yahoo.com with SMTP; 29 Oct 2012 10:38:07 -0700 PDT Received: by mail-vb0-f54.google.com with SMTP id l1so1981853vba.13 for ; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.36 with SMTP id c4mr39497747vdt.6.1351532286228; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) Received: by 10.58.182.72 with HTTP; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) In-Reply-To: <508E50A3.1030008@networx.ch> References: <508E50A3.1030008@networx.ch> Date: Mon, 29 Oct 2012 11:38:06 -0600 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: PseudoCylon To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, 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 17:38:14 -0000 On Mon, Oct 29, 2012 at 3:47 AM, Andre Oppermann wrote: > On 29.10.2012 04:53, Adrian Chadd wrote: >> >> On 28 October 2012 20:43, PseudoCylon wrote: >> >>> Cannot we just add custom hand off function to ieee80211_start()? >> >> >> Yes. That's the general idea. But what I don't want to do is have it >> just wake up the driver TX taskqueue - well, unless we have to. >> >> That means we'll have two context switches for each frame being >> transmitted and that as a concept just sucks. Plan B vap->iv_ifp->if_transmit = ieee80211_transmit; ieee80211_transmit() /* new */ { /* Alternatively, we can make a list of param and attach mbuf to it. */ HANDOFF(parent->if_snd, m); ieee80211_new_tx(vap, m); } /* enque packet, but keep working on the same mbuf */ ieee80211_new_tx(vap, m) { encap; if (fragment) insert_fragmented_packet_to_queue; /* don't forget about a fragmented packet */ for (; m->m_nextpkt != NULL; m = m->m_nextpkt) parent->if_new_tx(vap, m); } /* keep working on the same mbuf */ driver_new_tx(vap, m) { do_descriptor_stuff; m->m_flags |= ALL_SET; /* * If, for instance, processing of queue #5 packet finished before queue #1, * #5 packet will stay in queue until all of preceding packets get processed. */ if (parent->if_sc->sc_tx == NOT_RUNNING && ifq_head->m_flags & ALL_SET) driver_pass2hw(parent); } /* finally, process mbuf from the head of queue */ driver_pass2hw() { /* only one thread to dequeue */ if (atomic_compset(&sc->sc_tx, NOT_RUNNING, RUNNING) == 0) return; for (;;) { DEQUEUE(ifq, m); if (!(m->m_flags & ALL_SET)) { PREPEND(); break; } /* * want to do seq stuff somewhere in ieee80211_*(), * but I guess this is the only place could do. */ do_seqnum_stuff; /* simply put a packet onto dma-able memory area */ pass2hw; } sc->sc_tx = NOT_RUNNING; } No additional context switching, no long-held lock, but first queue first tx. AK >> >> See my (very recent) email to -wireless - I broke TCP throughput quite >> substantially by moving ath(4) TX into the taskqueue. I thought the >> problem was _just_ going to be how overlapping, direct dispatch TX >> could be preempted by the RX tasklet and TX completion, but there's >> obviously more going on. > > > I can't believe that TCP is getting broken by just introducing some > additional delay in the TX path. That can't add more than 300ms, > can it? There must be something else going on. Most likely either > severe packet loss (the m_nextpkt leak you mentioned earlier) or > severe packet re-ordering. > > So don't rule out the TX taskqueue concept quite yet. > > -- > Andre >