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 328A1A0C50; Fri, 16 Jul 2021 10:14:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E270340151; Fri, 16 Jul 2021 10:14:48 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 456C64014D for ; Fri, 16 Jul 2021 10:14:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626423286; 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=6bQiqDzlHYfrjqZUQNLhpCEKWfwW+49kpUoo3VtK168=; b=b6imCDneTN2q/pSI2CEwBFZjwljadJP5EM70SO96uToOkHXt5CeDAf8Wa22g6z3PPHYD4+ uf8IkiJ4c/5C7ELvBXtTyTA/lJycVsCMvuxtyXb57TSd5Nm6aMk5L4jdgZxAdC0dAXVeLU +/tv5ZxojQhA1qugFYzZpi3l6FetIeA= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-174-n2czm-QSOQS4izZibj9MlQ-1; Fri, 16 Jul 2021 04:14:45 -0400 X-MC-Unique: n2czm-QSOQS4izZibj9MlQ-1 Received: by mail-vk1-f200.google.com with SMTP id z125-20020a1fe2830000b029025c947168ffso2023167vkg.16 for ; Fri, 16 Jul 2021 01:14:45 -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=6bQiqDzlHYfrjqZUQNLhpCEKWfwW+49kpUoo3VtK168=; b=qLwhOewMjdhsi7PZAA+75J/wFPB+/MrIitkYAietwybQKe7EFSiZ/xwurNc9zQ8GLe bbB3FGnvA8AjYPKJybAcXQa2/rjsKg8OiE5aWjuLvqvM7pcRECo9+JglUBPUlXAT5dZM VIYZqw55zbG3lkXno1N4GetEy/TC8In9hv8lEaYYkzWPGOcF8wBLeQzE4lmd+mevvhvX b4lNHqnr+k9fAGGgS89Sp7VBHua3UheR7crpQSy0ucuSloOm0etBCuK/RhBUGK4RWu1r JoZgPgPzql+Dr+ZREFbvcWaL+LhGYIw3NZhDSblEun30qsIlt2QBwqAyVxntvY9wUntP uymA== X-Gm-Message-State: AOAM533VmGzE4BETGfYit7C7VrDPAbYuFdkwcI5cwyXfKtYMKCebuqCR pQhaNpR5HUG37YhFj/ODk1D37LkN04loL283lGHOEnBVzDk+75ioIn9VsKOArDuYzF7n3bHEtSH 87vHbjHHviiZZKdnyxJ8= X-Received: by 2002:a67:df85:: with SMTP id x5mr11627575vsk.17.1626423284994; Fri, 16 Jul 2021 01:14:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrZYl38e/vjSQeRzE01PoJbsPWlgZHSOdoUAP/Ca6m5035PhnLmlXUEHx+jj5B/oGLJCmp1ZxfzMY2OR8cs1M= X-Received: by 2002:a67:df85:: with SMTP id x5mr11627568vsk.17.1626423284814; Fri, 16 Jul 2021 01:14:44 -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 10:14:33 +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 Wed, Jul 14, 2021 at 8:50 AM Hu, Jiayu wrote: > > Are we ensuring packets are not reordered with this way of working? > > There is a threshold can be set by users. If set it to 0, which presents all > packet copies assigned to the DMA, the packets sent from the guest will > not be reordered. - I find the rte_vhost_async_channel_register() signature with a bitfield quite ugly. We are writing sw, this is not mapped to hw stuff... but ok this is a different topic. - 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. -- David Marchand