From owner-freebsd-wireless@FreeBSD.ORG Sat Jun 2 09:11:22 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 7909D1065672 for ; Sat, 2 Jun 2012 09:11:22 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id 495AD8FC0A for ; Sat, 2 Jun 2012 09:11:22 +0000 (UTC) Received: from [98.139.91.69] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2012 09:11:16 -0000 Received: from [208.71.42.196] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2012 09:11:16 -0000 Received: from [127.0.0.1] by smtp207.mail.gq1.yahoo.com with NNFMP; 02 Jun 2012 09:11:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1338628275; bh=iT3nx6OBaqsrOeG8UtWLH/ip7wxCCJ54vVG+MfpCGfw=; 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:Content-Transfer-Encoding; b=rYG19j4HAoCsoCxrR0MsreLHTKOOBYZgk9qgXFmQRKrEhHUH1bovyVo4FrFh8L6M7ae+7SRzP3B9ehX+t88WmODAn/HeGaU5qI2AL1KkNEsY23eAkUxMzvMK5RQGHnnPScjBtFBaz3SSGTx3+tI1ETOh02pLWgWm04KIl2IW8fM= X-Yahoo-Newman-Id: 984186.34155.bm@smtp207.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 89mLOJ4VM1mCMiStTzLRzPF3pRVxlJCdhLGU_8bbZWfV6o8 QuQngd7pDxAVxhAb9Vcf7Sw7WYnwYpDirdouS4qOuIU4Mp241XPjLBlWPOAI Aps3S0oM81lJ2WylTddrkaJX7DzvaUuNLthsgxfewjUDLjjr9ryaGWwrQt62 VS841fX7AfivC.dlRZYjIawHvgATj3uvZ0oEgQQ3MP3fxq1f1XfO6bTlEI9L UZGLo8mUCL4QJvYKogTW2mue_JiZ9074ELNUSWZPiXZBcAAObOGX5t8eSruF faLU2v2xww3NQE9ajSnUntKHBeqN6lIWOojV1v_8.WDTEjspJOkObzRD1W9z zdBZSxQE1SuEX0dhl5JYO7S8cSD5yyb5u.u8oAj5tDjUGKlTOktOEugR5cyj te9QNbFHr6tzZcAoge_15fi_mk7z3m5._kowy6A8tW6.NB8faWBywXw-- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-ob0-f182.google.com (moonlightakkiy@209.85.214.182 with plain) by smtp207.mail.gq1.yahoo.com with SMTP; 02 Jun 2012 02:11:15 -0700 PDT Received: by obcni5 with SMTP id ni5so5321890obc.13 for ; Sat, 02 Jun 2012 02:11:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.40.71 with SMTP id v7mr5859791obk.5.1338628275229; Sat, 02 Jun 2012 02:11:15 -0700 (PDT) Received: by 10.182.165.69 with HTTP; Sat, 2 Jun 2012 02:11:15 -0700 (PDT) Date: Sat, 2 Jun 2012 03:11:15 -0600 Message-ID: From: PseudoCylon To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org Subject: Re: if_start / if_transmit handling and packet ordering - how can I guarantee it? 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: Sat, 02 Jun 2012 09:11:22 -0000 > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 1 Jun 2012 00:46:02 -0700 > From: Adrian Chadd > Subject: if_start / if_transmit handling and packet ordering - how can > =A0 =A0 =A0 =A0I guarantee it? > To: freebsd-net@freebsd.org > Cc: freebsd-wireless@freebsd.org > Message-ID: > =A0 =A0 =A0 =A0 > Content-Type: text/plain; charset=3DISO-8859-1 > > Ok, so now that I've mostly tried to lucidly dump what's going on- > what do people think about holding the locks for (potentially) so > long? I know iwn(4) holds the driver lock for as long as it can for > _everything_, so it avoids this issue. But again, I don't really like > the idea of holding a lock for this long. Nether do I. Basically, this is how things go with holding a lock. if_start() { LOCK(); for (;;) { add_slot(); if (++queue_counter > MAX) break; } UNLOCK(); } _txeof() or usb_bulk_callback() { LOCK(); clear_slot(); queue_counter--; UNLOCK(); if_start(); } When if_start() is called first time, it will loop until slots get full. This is guaranteed because both functions want the lock, so no slot will be cleared until if_start() exits. When _txeof() is called, it frees one slot. Then calls if_start(). After enqueuing one frame, slots get full again. Then, _txeof() frees one slot, if_start() adds one ... So, the driver processes one frame at a time. The packet order is maintained, but it seems wasting memory for queue slots. > Does anyone else have any > other ideas? Maybe... If we guarantee only one thread/process runs the if_start(), we won't have to hold the lock for that long. i.e if_start() { if (!atomic_cmpset(&running, 0, 1)) return; for(;;) { if (full) { running =3D 0; break; } } } > FWIW - I temporarily converted the ath driver to make ath_start() > enqueue a taskqueue task, which then did all of the TX inside the > taskqueue. I have tried the similar thing with run(4), because I thought calling taskqueue_enqueue() is better than calling if_start() in usb_bulk_callback(). (if_start() is a big process.) I got extra bandwidth (forget the actual number). > I unfortunately > then become very, very susceptible to scheduling latency I had to use a private taskqueue instead of shared one to over come the latency. Other than that, it worked well, at least under 1 ap + 1 sta both use run(4) environment. AK