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 4AD81A3160 for ; Thu, 10 Oct 2019 10:14:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 31B011E907; Thu, 10 Oct 2019 10:14:11 +0200 (CEST) Received: from dispatchb-us1.ppe-hosted.com (dispatchb-us1.ppe-hosted.com [148.163.129.53]) by dpdk.org (Postfix) with ESMTP id 2371F1C2F8 for ; Thu, 10 Oct 2019 10:14:10 +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-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 0FB23B4006A; Thu, 10 Oct 2019 08:14:07 +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:14:01 +0100 To: Thomas Monjalon , Tiwei Bie , Ferruh Yigit CC: Maxime Coquelin , Zhihong Wang , , Dilshod Urazov References: <1569944672-24754-1-git-send-email-arybchenko@solarflare.com> <20191009104143.GA14695@___> <97813cf0-78c1-8ff3-5b36-b3423a9141ce@solarflare.com> <1888011.E2VOWpukML@xps> From: Andrew Rybchenko Message-ID: <79dd7de6-2f0d-dd66-86a7-53a04fcc2d30@solarflare.com> Date: Thu, 10 Oct 2019 11:13:56 +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: <1888011.E2VOWpukML@xps> 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-16.633700-8.000000-10 X-TMASE-MatchedRID: 9d2LtCNB3NL4ECMHJTM/ufZvT2zYoYOwC/ExpXrHizzesKlXDWQK+0eO xdt1kYZeW3UnKumFTG4HuquTyu/th0VPHDxFKiiVWTGejGdB9VLfIfhOVHn3r3P09xn0FL8Zzv+ 8/a5ZVEE4gPstGYhKNb//VCGogePztcRCUV3vQ8Q1VHP4fCovglrdKD8oHqzdabJxhiIFjJl6Zx og4kssg1P9PPsRKLESMCTmPxjI5Nw+1mUhx2/+TL1Zdxpk/Skc2u6+oPMdQ+5QKAQSutQYXDxa9 vSF/swfy8xKl0QD9YlHvPWyFe6hU2RZzgS9bzWmLCDCajDZWp1aEfFgComdjxLf1vz7ecPH8JSJ soYD/bZxKP8WPfwvnqv7xv0fPcuom7OnQfWFZEmcxB01DrjF9x5FmvZzFEQuwubD3SFbWzsr8+p /JLcH/xxTrzuysGXpK5MOrI69z1I+ZMR8T1SNlk95wQijrwBLt2ULozQ5QD6bKItl61J/ycnjLT A/UDoAoTCA5Efyn8CNo+PRbWqfRDsAVzN+Ov/sm/Q7qTf1Cucb2uOhLu1wgAj9D/e8tT12XPhub VsvpN9pem8WRMiEMQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.633700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24966.003 X-MDID: 1570695249-i17NgLe4_Ub6 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 10:42 AM, Thomas Monjalon wrote: > 09/10/2019 13:24, Andrew Rybchenko: >> On 10/9/19 1:41 PM, Tiwei Bie wrote: >>> On Wed, Oct 09, 2019 at 12:00:28PM +0300, Andrew Rybchenko wrote: >>>> And one more thought... >>>> It looks like if more than one Rx queue is configured, mq_mode must >>>> be ETH_MQ_RX_RSS and must not be ETH_MQ_RX_NONE. >>> Some apps in DPDK will set mq_mode to ETH_MQ_RX_NONE while >>> enabling multiple queue pairs, e.g.: >>> >>> https://github.com/DPDK/dpdk/blob/5b5bb56532fd5dea5d6260c0a0e405c0e32da2a0/app/test/test_link_bonding.c#L137 >>> https://github.com/DPDK/dpdk/blob/5b5bb56532fd5dea5d6260c0a0e405c0e32da2a0/app/test/test_link_bonding.c#L181-L182 >>> https://github.com/DPDK/dpdk/blob/5b5bb56532fd5dea5d6260c0a0e405c0e32da2a0/app/test/test_link_bonding.c#L3938-L3948 >>> >>> Testpmd will also set mq_mode to ETH_MQ_RX_NONE when multiple >>> Rx queues are enabled but rss_hf is empty: >>> >>> https://github.com/DPDK/dpdk/blob/5b5bb56532fd5dea5d6260c0a0e405c0e32da2a0/app/test-pmd/testpmd.c#L2935-L2938 >>> https://github.com/DPDK/dpdk/blob/5b5bb56532fd5dea5d6260c0a0e405c0e32da2a0/app/test-pmd/testpmd.c#L2945-L2948 >>> (the flow_type_rss_offloads reported by virtio-PMD is zero) >>> >>> 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. Yes, it means that testpmd should be fixed for this specific case to be able to enable RSS with rss_hf equal to 0.