From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B674A3160 for ; Thu, 10 Oct 2019 10:23:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1E3191E917; Thu, 10 Oct 2019 10:23:41 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id DAA781E910 for ; Thu, 10 Oct 2019 10:23:39 +0200 (CEST) Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2E10450F63 for ; Thu, 10 Oct 2019 08:23:39 +0000 (UTC) Received: by mail-vk1-f200.google.com with SMTP id p63so1825080vkf.3 for ; Thu, 10 Oct 2019 01:23:39 -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=2hqy7Gsn784kHOFwnKM/O8R/9laM7FUyqI1wSBEAhIg=; b=ZbGXt8hY3OePwABmS//xFGAg85mYmI6Px1DW2cnLVVE1PDYj/Dw4jChmX8vfM06o2/ 9O/h5KCvTOwuNPQL9kHAReAFUJCvYiiPmuxucWliFan2iS5JnJHGpABTlfnjKovIa7Mo dN39D0+x7BOsmUy8ZYcYbatjKqFoIJabQfLx28MDWpwCbgp1vvK/Mg/rs/sxjLUXp1Km J8sjzte7/F7rxAb1Q0q/QsdpLXkw3Kyy6xIegtuG0rFsQy1yW7YrIv8OoYY92mk0dgAA 9TV+DmnF1tjn5gvfSvxMe6tM3gQ44ZQhdyUpp7zi1D/xWTLUze7HRmlkK3jW128uDH5W WUdw== X-Gm-Message-State: APjAAAWcwydUZnADna9eKbOPP4Is9Q91hAquS1td6b++5tQ5awFD5XQ8 fdSyNozz182Tsh2vwgUNqNrw3B+fRg5kTk9PsZbRbT1Lhnt4FVilZKTuCZWVLYRkYyH2TXWZPfS UD3V1+uqCkp8bVM1EaS0= X-Received: by 2002:a05:6122:10d4:: with SMTP id l20mr4764004vko.18.1570695818347; Thu, 10 Oct 2019 01:23:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqw19ZLL1g3uny/D3KFJyz4R1mVIgMU6vZ/JnFWYt83IG7MDXBbx8T2WNdyabLaLwg6OehDWpjxlRT0EbCCYlCw= X-Received: by 2002:a05:6122:10d4:: with SMTP id l20mr4763994vko.18.1570695818062; Thu, 10 Oct 2019 01:23:38 -0700 (PDT) MIME-Version: 1.0 References: <1569944672-24754-1-git-send-email-arybchenko@solarflare.com> <20191009104143.GA14695@___> <97813cf0-78c1-8ff3-5b36-b3423a9141ce@solarflare.com> <1888011.E2VOWpukML@xps> <79dd7de6-2f0d-dd66-86a7-53a04fcc2d30@solarflare.com> In-Reply-To: <79dd7de6-2f0d-dd66-86a7-53a04fcc2d30@solarflare.com> From: David Marchand Date: Thu, 10 Oct 2019 10:23:26 +0200 Message-ID: To: Andrew Rybchenko Cc: Thomas Monjalon , Tiwei Bie , Ferruh Yigit , Maxime Coquelin , Zhihong Wang , dev , Dilshod Urazov Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 3/3] net/virtio: reject unsupported Rx multi queue modes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Thu, Oct 10, 2019 at 10:14 AM Andrew Rybchenko wrote: > > On 10/10/19 10:42 AM, Thomas Monjalon wrote: > > 09/10/2019 13:24, Andrew Rybchenko: > >> On 10/9/19 1:41 PM, Tiwei Bie wrote: > >>> My understanding is that, setting mq_mode to ETH_MQ_RX_NONE means > >>> no method is enforced on how to route packets to MQs. > >> I'm not sure. It is definitely a place to be improved in > >> ethdev documentation. Thomas, Ferruh, what do you think? > >> Is it really a definition of ETH_MQ_RX_NONE? > > I think it means everything go to queue 0. > > I understand it this way as well. > > > The comment says no DCB, RSS or VMDQ. > > It looks like the "NONE" value has been abused for some custom steering. > > We have two options: > > - document NONE as a possible case of custom steering > > - add a new CUSTOM value > > I'd prefer to say that ETH_MQ_RX_RSS with rss_hf equal to 0 means > unspecified/unknown steering. If application just want to spread > traffic across many Rx queues, it is natural choice to say that > it want RSS, but do not care about spreading algorithm etc. > It allows driver use recommended defaults if rss_hf is controllable, > or just spread in virtio case. RSS is about maintaining affinity of a "flow" (as in packets sharing the same l3/l4 tuples) to a specific queue. Here, we can have packets from a same flow on any queue depending on what happened on the vhost side. I prefer we describe this behavior as something else than RSS. -- David Marchand