From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from he.sipsolutions.net ([78.46.109.217]:34845 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757175Ab0I0TKc (ORCPT ); Mon, 27 Sep 2010 15:10:32 -0400 Subject: Re: [RFC] mac80211: fix release_reorder_timeout in scan From: Johannes Berg To: "Luis R. Rodriguez" Cc: wireless , Jouni Malinen , Christian Lamparter In-Reply-To: References: <1285266471.3770.384.camel@jlt3.sipsolutions.net> <1285611630.4043.26.camel@jlt3.sipsolutions.net> <1285613669.4043.27.camel@jlt3.sipsolutions.net> <1285614371.4043.28.camel@jlt3.sipsolutions.net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Sep 2010 21:10:31 +0200 Message-ID: <1285614631.4043.29.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, 2010-09-27 at 12:09 -0700, Luis R. Rodriguez wrote: > On Mon, Sep 27, 2010 at 12:06 PM, Johannes Berg > wrote: > > On Mon, 2010-09-27 at 12:03 -0700, Luis R. Rodriguez wrote: > > > >> > We put them into the reorder buffer, but if we get a reorder timeout > >> > while scanning we'll drop the frames which isn't necessary. > >> > >> Ah, got it, thanks, good catch. Guess its not a terrible stable fix, > >> but at least important for those who care about VoIP and such. > > > > You wouldn't typically use aggregation on VO traffic, I think? > > ath9k uses aggregation for all data traffic. But it can only control TX :) Which is, of course, relevant if it's used as an AP, but for typical VO traffic I would argue that using aggregation is a bug since it'll just increase delays & jitter. johannes