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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B08CC433F5 for ; Wed, 8 Sep 2021 21:06:24 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 085C660187 for ; Wed, 8 Sep 2021 21:06:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 085C660187 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:51480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO4lz-0006cH-7t for qemu-devel@archiver.kernel.org; Wed, 08 Sep 2021 17:06:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO4kd-0005HV-0e for qemu-devel@nongnu.org; Wed, 08 Sep 2021 17:04:59 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:48560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO4ka-0005BT-Vu for qemu-devel@nongnu.org; Wed, 08 Sep 2021 17:04:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631135095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m4KmfA/ZtkMKCcQ/pLSR1y8RQX+Jov2uo1wuvXq3YYo=; b=fYEURiSp+f585TSF7l3uoSiFQeXpQF2Pg4Oli9NeizcPdzXvnxEC/rFsD/YNkYcGdWEqNC f5itn+/vPp2DyTfXej9K3kWKDamNBDp78m7QtHyO+Mlqtl9lqIBD7g5yf+EB6yxoHImgLQ jEO3dtJb/UMJmgFEIdngeILyRxU6IYc= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-431-_JhCBwykOSKjnpds0cZLqg-1; Wed, 08 Sep 2021 17:04:52 -0400 X-MC-Unique: _JhCBwykOSKjnpds0cZLqg-1 Received: by mail-il1-f200.google.com with SMTP id w12-20020a92ad0c000000b00227fc2e6eaeso2793361ilh.4 for ; Wed, 08 Sep 2021 14:04:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=m4KmfA/ZtkMKCcQ/pLSR1y8RQX+Jov2uo1wuvXq3YYo=; b=yyptNE7puwZ151mQ/cRIMEKGPg0/AanRi3qZxHv0e/ARLF62bG0McbgM4u+qlUgUu2 JObG6h0VTheZapSkzhWop1H8isj4blsKt8RAqaZUIutL3EYHzMFUxsaTfr9FpgnK7eZf 0VpHq56T9pQTXO+hk76T4zOJuz7GEf/YJL0ktI5Owg4xqaQ27XH39asflIDmghy97plY WyPhSMZcaU3BeLYLEQiMe6fALF2nFvf69FFx3SQycVHbHWnhbCVzqgGkTn4AYFD6Ob6D 5Ehxsm4/QJXP4cHt2QlB5j05Q9WCLLk8umxe6DTisk6TNEB5aEtS9mI1cbJTJ3RXJ0Xw LYmA== X-Gm-Message-State: AOAM5312Ti2+eqgDzeBzHAV7jWiuad9h3LcdTUr4DlwJVO3Rfm+F7ibm rskRI0pgRmWoR2Xc0SD4Vm032bS/GxSsQtUkNZa6TVlutKNuhJFIdgaDyOdErBlZ73YQMaeADSO W1XkeOR6R1U/Elh8= X-Received: by 2002:a92:130e:: with SMTP id 14mr165642ilt.129.1631135091701; Wed, 08 Sep 2021 14:04:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8lavzCqpfM0rMnMKCFbd+aW9gpYa9ojJTbYJlnyoMFRpfpl5+8nmZG+ZougGeMBHIZ9wkbg== X-Received: by 2002:a92:130e:: with SMTP id 14mr165619ilt.129.1631135091488; Wed, 08 Sep 2021 14:04:51 -0700 (PDT) Received: from t490s ([2607:fea8:56a3:500::ad7f]) by smtp.gmail.com with ESMTPSA id g8sm99617ild.31.2021.09.08.14.04.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Sep 2021 14:04:50 -0700 (PDT) Date: Wed, 8 Sep 2021 17:04:49 -0400 From: Peter Xu To: Leonardo Bras Soares Passos Subject: Re: [PATCH v1 2/3] io: Add zerocopy and errqueue Message-ID: References: <20210831110238.299458-1-leobras@redhat.com> <20210831110238.299458-3-leobras@redhat.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.393, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Elena Ufimtseva , John G Johnson , Jagannathan Raman , qemu-block@nongnu.org, Juan Quintela , qemu-devel , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , "Dr. David Alan Gilbert" , Paolo Bonzini , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Fam Zheng Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Sep 08, 2021 at 05:13:40PM -0300, Leonardo Bras Soares Passos wrote: > On Tue, Sep 7, 2021 at 1:44 PM Peter Xu wrote: > > > > On Thu, Sep 02, 2021 at 03:59:25AM -0300, Leonardo Bras Soares Passos wrote: > > > I also suggested something like that, but I thought it could be good if we could > > > fall back to io_writev() if we didn't have the zerocopy feature (or > > > the async feature). > > > > > > What do you think? > > > > That fallback looks safe and ok, I'm just not sure whether it'll be of great > > help. E.g. if we provide an QIO api that allows both sync write and zero-copy > > write (then we do the fallback when necessary), it means the buffer implication > > applies too to this api, so it's easier to me to just detect the zero copy > > capability and use one alternative. Thanks, > > > > -- > > Peter Xu > > > > I was thinking this way (async method with fallback) we would allow code using > the QIO api to just try to use the io_async_writev() whenever the code > seems fit, and > let the QIO channel layer to decide when it can be used > (implementation provides, > features available), and just fallback to io_writev() when it can't be used. Sure, I think it depends on whether the whole sync/async interface will be the same, e.g., when async api needs some callback registered then the interface won't be the same, and the caller will be aware of that anyways. Otherwise it looks fine indeed. Thanks, -- Peter Xu