From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54D3FC433EF for ; Tue, 24 May 2022 08:20:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232100AbiEXIUz convert rfc822-to-8bit (ORCPT ); Tue, 24 May 2022 04:20:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231334AbiEXIUy (ORCPT ); Tue, 24 May 2022 04:20:54 -0400 X-Greylist: delayed 559 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 24 May 2022 01:20:53 PDT Received: from mail.oldum.net (86-87-34-132.fixed.kpn.net [86.87.34.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2B7AF5DBDC for ; Tue, 24 May 2022 01:20:53 -0700 (PDT) Received: from [10.1.0.200] (unknown [10.1.0.200]) by mail.oldum.net (Postfix) with ESMTPA id 46BFAA7531; Tue, 24 May 2022 08:10:36 +0000 (UTC) Message-ID: <2380b79f721caf9e6b99aa680b9b29c76fd4e2f4.camel@oldum.net> Subject: Re: [PATCH v4 00/12] remove msize limit in virtio transport From: Nikolay Kichukov To: Dominique Martinet Cc: Christian Schoenebeck , v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org, Eric Van Hensbergen , Latchesar Ionkov , Greg Kurz , Vivek Goyal Date: Tue, 24 May 2022 10:10:31 +0200 In-Reply-To: References: <29a54acefd1c37d9612613d5275e4bf51e62a704.camel@oldum.net> <1835287.xbJIPCv9Fc@silver> <5111aae45d30df13e42073b0af4f16caf9bc79f0.camel@oldum.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello Dominique, On Mon, 2022-01-24 at 20:07 +0900, Dominique Martinet wrote: > Nikolay Kichukov wrote on Mon, Jan 24, 2022 at 11:21:08AM +0100: > > It works, sorry for overlooking the 'known limitations' in the first > > place. When do we expect these patches to be merged upstream? > > We're just starting a new development cycle for 5.18 while 5.17 is > stabilizing, so this mostly depends on the ability to check if a msize > given in parameter is valid as described in the first "STILL TO DO" > point listed in the cover letter. > > I personally would be happy considering this series for this cycle > with > just a max msize of 4MB-8k and leave that further bump for later if > we're sure qemu will handle it. > We're still seeing a boost for that and the smaller buffers for small > messages will benefit all transport types, so that would get in in > roughly two months for 5.18-rc1, then another two months for 5.18 to > actually be released and start hitting production code. > > > I'm not sure when exactly but I'll run some tests with it as well and > redo a proper code review within the next few weeks, so we can get > this > in -next for a little while before the merge window. > Did you make it into 5.18? I see it just got released...