From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7F76E201322 for ; Sun, 27 Nov 2011 01:48:12 -0800 (PST) Received: by ghbz2 with SMTP id z2so6850676ghb.16 for ; Sun, 27 Nov 2011 01:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P+8lsfRTGn1s2EODigQD3TuRWT1PLAw6/xSxEpKOz1g=; b=DKeHXGRzycogucBsyZ1Pg+1tnyM9kZJsfG8tcZx3QXIujWOTgofCFSm7ixis1RER0E dfp/fdn9YAQDNuzF+U965mZbKZ+w8xqnrQ8n3IUHCETa4gjjr7H2jpMC5yCRWfSwRb5l xf2LOWrvsdLBT6E9w0uZ/3NJ5H+8/V1YhO25E= MIME-Version: 1.0 Received: by 10.182.31.68 with SMTP id y4mr7972195obh.66.1322387289172; Sun, 27 Nov 2011 01:48:09 -0800 (PST) Received: by 10.182.193.65 with HTTP; Sun, 27 Nov 2011 01:48:09 -0800 (PST) Date: Sun, 27 Nov 2011 10:48:09 +0100 Message-ID: Subject: timestamping at the mac80211 layer before it hits tc? From: Dave Taht To: linux-wireless , bloat-devel , netdev@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 09:48:12 -0000 My crazy idea at the moment is that since things can spend inordinate amounts of time in the txqueue in wireless in particular, that moving (tcp and packet) timestamping to where it enters the queue rather than hits the wireless device would make a difference. Unless that's already how it works. http://www.bufferbloat.net/issues/304#change-1186 The secondary fallout of that is an easier way to expire (probably rescheduled) packets that have spent too much time in queue. Eric had put up a (rfc) tc filter a while back that dumped a timestamp into the private block of the skb... but... I kind of like the idea of reusing the existing hwtstamps concept for the period "queue entrance to queue exit", as a queue is a 'device', IMHO. from linux/skbuff.h * hwtstamps can only be compared against other hwtstamps from * the same device. * * This structure is attached to packets as part of the * &skb_shared_info. Use skb_hwtstamps() to get a pointer. */ struct skb_shared_hwtstamps { =A0 =A0 =A0 =A0ktime_t hwtstamp; =A0 =A0 =A0 =A0ktime_t syststamp; }; Sign me, lost in a myriad of data paths on a sunday afternoon, wearing an asbestos s= uit -- Dave T=E4ht SKYPE: davetaht http://www.bufferbloat.net