From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 11DEBA0C50; Fri, 16 Jul 2021 15:52:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C13C04067B; Fri, 16 Jul 2021 15:52:52 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 2EB8640151 for ; Fri, 16 Jul 2021 15:52:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626443571; 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=5AuDLQjPr5F/PuKP11GrA+wU5UMmUW/BKe+ZzKeSRPA=; b=APBfMGbY3GMCBvIDX1X+6ZaYFHX5hn2gbFE2lkGFbSoWC8avwUIH2jYJKHo6NHOtWvwuEB Ln1XxCCNlDimoVlIWOTFFaS522Il6M7TdpHPyS7gpp4KspI1axAlPMpbvP0rnNf6DK+NF/ ZoTFgBYwfCiB8slGVGS1LsudnNa5sDM= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-pUJF7dpuOve3xvn_NF-eyA-1; Fri, 16 Jul 2021 09:52:50 -0400 X-MC-Unique: pUJF7dpuOve3xvn_NF-eyA-1 Received: by mail-ua1-f71.google.com with SMTP id 76-20020ab003d20000b029029db3c53817so3757030uau.22 for ; Fri, 16 Jul 2021 06:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5AuDLQjPr5F/PuKP11GrA+wU5UMmUW/BKe+ZzKeSRPA=; b=j0XLlkpdcQb3KdjRDh0RwGH1zNkhMp5E5KFzJ1mms6W1sqjWweGWl/qQpPRwSDZxXS YahneDKky6TajSR6aXXSk2aRMl/VoInoEa7W9OoQ4n2L1wX14Hr32VjSB5MnpupzvY3X o7dnKFH6sweMTlGoty8VFIFb2dfG33/4skIaehLO+VLxtvVZQRzr+0IPsf9kTi1INnqM GvdfiMNcsvO+sjw7G/EDHDYcKstq1zUoCkEOkpkrXz8S+K1HqxialC3mJ/hK3AAS5Hzz ikLSJk7+jU7F4okCz91rX28+R4epZQ6ElWRLzmy5RKZvd1PBmwD9oGIQbg2PEyFrmZjQ z+6g== X-Gm-Message-State: AOAM530P70EKx4jDKcHtDNDrbPQgsll2rBL4EbDALBJJDPlvhxeZeYT1 Gche3Qfd1O2yBX9aVBHWr2aHwz8TM1nN8nTpiXMpnw1/fHsCHyfPY+z9Ud1fPdseQDGTQ+5ehgm l1qn7CerfrnB7vAirWYI= X-Received: by 2002:a1f:d487:: with SMTP id l129mr11842638vkg.9.1626443569739; Fri, 16 Jul 2021 06:52:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxIkszeelxuO4ABJ7ONkkiuGnTgRHMuG25Zjdyek4KaZwLE+QKZGmLf9a3y4m7c/sLT+63eKap8rx9kFWLy+Vw= X-Received: by 2002:a1f:d487:: with SMTP id l129mr11842603vkg.9.1626443569483; Fri, 16 Jul 2021 06:52:49 -0700 (PDT) MIME-Version: 1.0 References: <20210602083110.5530-1-yuanx.wang@intel.com> <20210705181151.141752-1-wenwux.ma@intel.com> <20210705181151.141752-4-wenwux.ma@intel.com> In-Reply-To: From: David Marchand Date: Fri, 16 Jul 2021 15:52:37 +0200 Message-ID: To: "Hu, Jiayu" Cc: Maxime Coquelin , "Ma, WenwuX" , "dev@dpdk.org" , "Xia, Chenbo" , "Jiang, Cheng1" , "Wang, YuanX" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v5 3/4] vhost: support async dequeue for split ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jul 16, 2021 at 3:45 PM Hu, Jiayu wrote: > > - I don't like this threshold, this is too low level and most users will only see > > the shiny aspect "better performance" without understanding the > > consequences. > > By default, it leaves the door open to a _bad_ behavior, that is packet > > reordering. > > At a very minimum, strongly recommend to use 0 in the API. > > That's a good point. But there are some reasons of open this value to users: > - large packets will block small packets, like control packets of TCP. > - dma efficiency. We usually see 20~30% drops because of offloading 64B copies to > dma engine. > - the threshold is not only related to hardware, but also application. The value decides > which copies are assigned to which worker, the CPU or the DMA. As async vhost works > in an asynchronous way, the threshold value decides how many works can be done in > parallel. It's not only about what DMA engine and what platform we use, but also what > computation the CPU has been assigned. Different users will have different values. > > I totally understand the worry about reordering. But simple iperf tests show positive > results with setting threshold in our lab. We need more careful tests before modifying > it, IMHO. If you need more time, then please take it. The dma generic API could have an impact on this feature too. Why the rush for merging this now? -- David Marchand