From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 994D3A3160 for <public@inbox.dpdk.org>; Thu, 10 Oct 2019 11:13:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EABE51C2A8; Thu, 10 Oct 2019 11:13:23 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 49A181C198 for <dev@dpdk.org>; Thu, 10 Oct 2019 11:13:22 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2019 02:13:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,279,1566889200"; d="scan'208";a="277707978" Received: from dpdk-virtio-tbie-2.sh.intel.com (HELO ___) ([10.67.104.74]) by orsmga001.jf.intel.com with ESMTP; 10 Oct 2019 02:13:18 -0700 Date: Thu, 10 Oct 2019 17:10:20 +0800 From: Tiwei Bie <tiwei.bie@intel.com> To: Andrew Rybchenko <arybchenko@solarflare.com> Cc: David Marchand <david.marchand@redhat.com>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Zhihong Wang <zhihong.wang@intel.com>, dev <dev@dpdk.org>, Dilshod Urazov <Dilshod.Urazov@oktetlabs.ru> Message-ID: <20191010091020.GA5729@___> 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> <CAJFAV8wDBu8WHF6wW5RvA5=oCc=N89NYhm1A6FXTFgz4SViw-g@mail.gmail.com> <e8aa95fe-a422-cf5a-c505-f6c240068e9a@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <e8aa95fe-a422-cf5a-c505-f6c240068e9a@solarflare.com> User-Agent: Mutt/1.9.4 (2018-02-28) 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Thu, Oct 10, 2019 at 11:27:53AM +0300, Andrew Rybchenko wrote: > On 10/10/19 11:23 AM, David Marchand wrote: > > On Thu, Oct 10, 2019 at 10:14 AM Andrew Rybchenko > > <arybchenko@solarflare.com> 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. > > Interesting. I'd like to know a bit more about it. I didn't know that > it is so unstable. Could someone who knows the topic well add > a bit more information about it. The spec defined automatic steering [1], but it's not very strict for the device. So it depends on the implementation. [1] https://github.com/oasis-tcs/virtio-spec/commit/f7020384521e5938cdd1351270b32b143f070d00