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 6BD70A3160 for ; Thu, 10 Oct 2019 10:28:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D3871E954; Thu, 10 Oct 2019 10:28:06 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id AB6C11E954 for ; Thu, 10 Oct 2019 10:28:04 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 6FAFD80069; Thu, 10 Oct 2019 08:28:03 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 10 Oct 2019 09:27:56 +0100 To: David Marchand CC: Thomas Monjalon , Tiwei Bie , Ferruh Yigit , Maxime Coquelin , Zhihong Wang , dev , Dilshod Urazov 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> From: Andrew Rybchenko Message-ID: Date: Thu, 10 Oct 2019 11:27:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24966.003 X-TM-AS-Result: No-11.536700-8.000000-10 X-TMASE-MatchedRID: byfwvk+IcRn4ECMHJTM/ubDT1dbmL1eM69aS+7/zbj+qvcIF1TcLYPU5 Yv2ESTAsgIh8l/Ap5BH3UUaGTeUpABE9t96AiQVyolVO7uyOCDVgsFOoKOJn5gdC9P1Le8dQCPI vP3uOlZdC8QifgGKImDPUs9laO6gRNKnO1vGWufVSxYp8x/dFp6m9/6ObPjnDy5JfHvVu9IvwlI myhgP9tnEo/xY9/C+eq/vG/R89y6ibs6dB9YVkSZzEHTUOuMX3HkWa9nMURC7C5sPdIVtbOyvz6 n8ktwf/AYe5KzAUnG4uWlWHXeK0FPVimO8vZqd3RDrySO71mmo4ZdBTniOkUlc/CedjlcvkQJ8C S6DhaNiTLUrwqOMDXDly6r+/8Rij3hAN5/Rqfy4zvWHRIxWXwn0tCKdnhB58vqq8s2MNhPCy5/t FZu9S3Ku6xVHLhqfxIAcCikR3vq8IGHzMSFZtvhRd5/zkZZeGvdW8WYWwH+JSrj5MuEWnQbovNZ xU1gmV X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--11.536700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24966.003 X-MDID: 1570696084-fOSVh5lCgSJZ 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 10/10/19 11:23 AM, David Marchand wrote: > 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. 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. > I prefer we describe this behavior as something else than RSS.