From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 686F83CB49 for ; Fri, 22 Jan 2021 19:34:24 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1611362059; bh=qdScobOvFquKItKHwNzcEBvhSFjg2tahqcXaU/QTwX0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i9shFc/WaMcdhQ8xqMAp/unimpKkf8Arz8DDcmZBaEwx5nlnk00xprTU7KUbRsrkV rF0Cs+8YATfMCNCf/oDPTaSQWk/eV/XGyMZDMoolmrfpTTRlYUZgOCYH5nUhVW8ENS 86jGoAxnimA4MOfynzaJ2G+I1AcGbXBbMrre4TL13KUi5llKPT69K87M2Mlj+ODkNE 3ngBrNrDlfOTfM31yWcun/6opv7PR82FKJZXrEwyA/RHdFPvefyVA3FF/fMUuhigFV YQxvpdxmKn0X1mYJBD6PPLeByKs9oG+py51HMdPMc4Yb7Qx87EXO7nxPc7mSjQ/wMG +WnCdLVlkoCvw== To: Hal Murray , bloat@lists.bufferbloat.net Cc: Hal Murray In-Reply-To: <20210122233710.1B911406061@ip-64-139-1-69.sjc.megapath.net> References: <20210122233710.1B911406061@ip-64-139-1-69.sjc.megapath.net> Date: Sat, 23 Jan 2021 01:34:19 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zh104hkk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] Measuring CoDel X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2021 00:34:24 -0000 Hal Murray writes: > Toke said: >> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as >> in, we have not been able to measure it), when otherwise doing forwarding >> using the regular Linux stack. > > I may be able to help with that. > > Are you familiar with Dick Sites' KUtrace? > Stanford Seminar - KUtrace 2020 > https://www.youtube.com/watch?v=2HE7tSZGna0 Nope - but from a quick glance it looks similar to what you can do with 'perf'? :) > The catch is that I've never used CoDel so somebody will have to teach > me how to setup a test environment, and then show me the chunks in the > kernel you want to measure. To measure the CoDel algorithm, I guess the thing to measure would be codel_dequeue(): https://elixir.bootlin.com/linux/latest/source/include/net/codel_impl.h#L142 However, that has loops in it that depend on flow state, so its execution time will vary some. For fq_codel it would be the fq_codel_enqueue() and fq_codel_dequeue() functions, but they have a similar problem: https://elixir.bootlin.com/linux/latest/source/net/sched/sch_fq_codel.c Also, the larger problem is that the overhead of these drown in all the other processing the kernel does for each packet (none of the queueing-related functions even register on a 'perf' report when forwarding packets. Still, might be interesting to see, who knows? So feel free to take a stab at it :) -Toke