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 36E02A0032; Fri, 18 Feb 2022 11:22:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B843440150; Fri, 18 Feb 2022 11:22:29 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id E385440141 for ; Fri, 18 Feb 2022 11:22:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645179748; x=1676715748; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=XaSaqjEOZmHKGfypqo/FZ5gIfeo7pD8H0YOBHPJUD/w=; b=IirFEzz1KsmV/UkVMNvz2erX7qRXf3yYSpj+sJbAWRj+TZ3wM3gdaUqx 5PXC7FYMLH6uaehXtqyRX39IGqkr/tHMQGqGUThVcx0I05S5R/1RMtbAu ZJ33SJ7Bao9v+jyl1WdYj43jQ8bXbh4QOWYFDv4dfCqZBWavmbuK2nuVc n7LZyxb3lkKkVZd15pwR82rBTLOeuJEOUA2TuTwdL4cl8pOlCM5XDYq+p k+hzv+JhI4aZC0irMWOuNqRhIkPypJ/of//5My7TdBZ1zLxW9PV9wLJkf 41UuJPBc96lDF6ijXMLBHyJgin18hy9KOCi6mO+quXTkOEAtTp2vHE3N8 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="238504802" X-IronPort-AV: E=Sophos;i="5.88,378,1635231600"; d="scan'208";a="238504802" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 02:22:26 -0800 X-IronPort-AV: E=Sophos;i="5.88,378,1635231600"; d="scan'208";a="546224272" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.13.174]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 18 Feb 2022 02:22:25 -0800 Date: Fri, 18 Feb 2022 10:22:22 +0000 From: Bruce Richardson To: "Ma, WenwuX" Cc: "Burakov, Anatoly" , "dev@dpdk.org" , "Hu, Jiayu" , "Wang, Yinan" , "He, Xingguang" Subject: Re: [PATCH] examples/multi_process: add options to control port configuration Message-ID: References: <20220217151755.442306-1-wenwux.ma@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 On Fri, Feb 18, 2022 at 10:10:58AM +0000, Ma, WenwuX wrote: > > > > -----Original Message----- > > From: Richardson, Bruce > > Sent: 2022年2月18日 17:42 > > To: Ma, WenwuX > > Cc: Burakov, Anatoly ; dev@dpdk.org; Hu, > > Jiayu ; Wang, Yinan ; He, > > Xingguang > > Subject: Re: [PATCH] examples/multi_process: add options to control port > > configuration > > > > On Fri, Feb 18, 2022 at 06:49:19AM +0000, Ma, WenwuX wrote: > > > > > > > > > > -----Original Message----- > > > > From: Richardson, Bruce > > > > Sent: 2022年2月17日 17:06 > > > > To: Ma, WenwuX > > > > Cc: Burakov, Anatoly ; dev@dpdk.org; Hu, > > > > Jiayu ; Wang, Yinan ; He, > > > > Xingguang > > > > Subject: Re: [PATCH] examples/multi_process: add options to control > > > > port configuration > > > > > > > > On Thu, Feb 17, 2022 at 03:17:55PM +0000, Wenwu Ma wrote: > > > > > The default values of rx mq_mode and rx offloads for port will > > > > > cause symmetric_mp startup failure if the port do not support rss or > > csum. > > > > > Therefore, we added two new options --rx-mq-mode and > > > > > --rx-offloads, through which the user can set the values > > > > > appropriately according to the situation to make app startup normally. > > > > > > > > > > Signed-off-by: Wenwu Ma --- > > > > > > > > The idea seems reasonable enough, but I think the implementation > > > > requiring the user to pass in special "magic numbers" for the > > > > offload values is not a good idea. Perhaps add in a separate flag for "no- > > csum" to disable that. > > > > > > > > For the no-rss case, can you explain how you would see this app > > > > being used in the absense of RSS support to distribute traffic among > > > > the separate processes? > > > > > > When app run in qemu vm and the backend is dpdk vhost, it will report > > error below: > > > "virtio_dev_configure(): RSS support requested but not supported by the > > device" > > > > Sure, I understand that. But how does it make sense to run multiple copies of > > the app if RSS cannot be used to spread the traffic between the instances? > > in test case, vhost backend has 2 queues, and we set fwd as txonly, and in vm, we run app as follows > > ./examples/multi_process/symmetric_mp/build/symmetric_mp -l 1 -n 4 --proc-type=auto -- -p 3 --num-procs=2 --proc-id=0 > ./examples/multi_process/symmetric_mp/build/symmetric_mp -l 2 -n 4 --proc-type=secondary -- -p 3 --num-procs=2 --proc-id=1 > > So, instance 0 receive pkts in queue 0, and instance 1 receive pkts in queue 1. > Interesting. So with vhost/virtio, the distribution of the traffic to queues in entirely controls by the backend without the virtio PMD being able to control it? Anyway, if we want to allow running the app without rss, I would echo the comment I made about "csum", in that we probably just want a suitably named flag for it, rather than just requiring magic numbers from the user. Two options therefore I'd suggest: 1. just make the app ignore errors with csum and RSS - if they are not supported by a NIC, just log a warning and run the app anyway, reconfiguring the NIC without them. Only quit the app if the second reconfiguration fails. 2. Add explicit --no-csum and --no-rss flags. I would actually tend towards the first option as more usable, but the second could work too. /Bruce