From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 68C253B29E; Wed, 28 Jun 2023 17:53:53 -0400 (EDT) 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=1687989232; bh=PLwiVRUPiYONer607l8EIH86a9+JIEWaztKI5Kom+/k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZBK17eRERpeQoIn9qtGztI42SdwG3qmlnnOmbQ/dSFdsVaYNzFLrid05qL01fHcoK 7kHIyae/BewguOPM8EFWIcxJPw+E1g2Hi1+5dv7dLYvYSwNVOgcWRQpobjk+UpC3S7 KAqt6E8ssZaSV1icJeCCIxbXl2pil4HNicnDK4jfGWPIfnuSl/O83t+i71K+uM8fze vCBOvzdpbfN0D7ERuVE3n1Fez8uN6/Tge84gBoubRy4N0/B60kJ1gtKvSWFtn0ncjP JKA6bGGB4t+eSNa3Ljzl71nQBS+jEMIHxfHv6tEFpodpHCunVZV2aK/tWPFwmRvnna ZC10XfgmxoN2A== To: "David P. Reed" , Dave Taht via Cake Cc: cake@lists.bufferbloat.net, bloat@lists.bufferbloat.net In-Reply-To: <1687962752.39077378@mobile.rackspace.com> References: <1687962752.39077378@mobile.rackspace.com> Date: Wed, 28 Jun 2023 23:53:51 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877crngsnk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2023 21:53:53 -0000 "David P. Reed via Bloat" writes: > (One such nightmare can be seen in LKML... Search for > dpreed@deepplum.com patch emails. I tried hard, was worn down, then > gave up, since I found a way to avoid the bug, in virtualization code > on x86, and gave up on getting it fixed after a year. Life is too > short. Went looking, since I think it's important to learn from such process failures (and you're certainly not the first to opine that getting patches into the kernel is challenging). I'm assuming you're referring to this series, right? https://lore.kernel.org/all/20200704203809.76391-4-dpreed@deepplum.com/ Which, to me, looks like it was pretty close to being accepted; another revision would probably have made the cut... ...In fact it seems those patches were later resurrected by Sean as part of this series, six months later: https://lore.kernel.org/all/20201231002702.2223707-1-seanjc@google.com/ One of the patches retained your authorship and made it into the kernel in this commit: https://git.kernel.org/torvalds/c/53666664a305 So wouldn't necessarily call that a complete failure :) Seems the main process issue you hit here was a subsystem that was too resource constrained on the review side, which does sadly happen. The kernel process tends to heavily favour convenience of reviewers for the same reason (which is one of the reasons it can be off-putting to outsiders, so it's a bit of a chicken and egg situation...) -Toke