From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A4B4C00144 for ; Wed, 27 Jul 2022 02:15:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233013AbiG0CPB (ORCPT ); Tue, 26 Jul 2022 22:15:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230245AbiG0CPA (ORCPT ); Tue, 26 Jul 2022 22:15:00 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E695420186 for ; Tue, 26 Jul 2022 19:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658888099; x=1690424099; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=GQlaCUMYg+wmQxu3iW5BvdbUBZUH1MBwOdVTDD4M1v8=; b=Cv7wbuudLUxScjWno+F/ULjPEUPX/XItHEyq7zqyOtlzpO5Wv9Ba8Qco G5kbddGJGoI0mtSmbpv4mYj6fJQrbjuIRqdDwJTsyf3vrgwwCHwpVNYd8 6/tZNuhjWYnifP9pe3/hczebhi/T33TkbWJ7k/yk6U9jEYNG0u2U/k1fa ySkc5qdVprFQGE9MTrJopfvV7LzfEmCWnpJp8FJAvSLtMaooft0r+Q2Je TOBCV+ZT6teRE6oMAmC/EswNsiZBn/gz5YwmEK1xVBSVcyg3k6ne3fVrd E08Qpp31PBfY7QQd13D6mlIwtDJ5izJO1aJMYFmx03pcLcGEFTOvTQyoJ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10420"; a="286879660" X-IronPort-AV: E=Sophos;i="5.93,194,1654585200"; d="scan'208";a="286879660" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2022 19:14:59 -0700 X-IronPort-AV: E=Sophos;i="5.93,194,1654585200"; d="scan'208";a="658979102" Received: from lingshan-mobl.ccr.corp.intel.com (HELO [10.249.171.153]) ([10.249.171.153]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jul 2022 19:14:56 -0700 Message-ID: <19681358-fc81-be5b-c20b-7394a549f0be@intel.com> Date: Wed, 27 Jul 2022 10:14:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.11.0 Subject: Re: [PATCH V3 5/6] vDPA: answer num of queue pairs = 1 to userspace when VIRTIO_NET_F_MQ == 0 Content-Language: en-US To: Parav Pandit , "jasowang@redhat.com" , "mst@redhat.com" Cc: "virtualization@lists.linux-foundation.org" , "netdev@vger.kernel.org" , "xieyongji@bytedance.com" , "gautam.dawar@amd.com" References: <20220701132826.8132-1-lingshan.zhu@intel.com> <20220701132826.8132-6-lingshan.zhu@intel.com> <00c1f5e8-e58d-5af7-cc6b-b29398e17c8b@intel.com> <1246d2f1-2822-0edb-cd57-efc4015f05a2@intel.com> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 7/26/2022 11:56 PM, Parav Pandit wrote: >> From: Zhu, Lingshan >> Sent: Tuesday, July 12, 2022 11:46 PM >>> When the user space which invokes netlink commands, detects that _MQ >> is not supported, hence it takes max_queue_pair = 1 by itself. >> I think the kernel module have all necessary information and it is the only >> one which have precise information of a device, so it should answer precisely >> than let the user space guess. The kernel module should be reliable than stay >> silent, leave the question to the user space tool. > Kernel is reliable. It doesn’t expose a config space field if the field doesn’t exist regardless of field should have default or no default. so when you know it is one queue pair, you should answer one, not try to guess. > User space should not guess either. User space gets to see if _MQ present/not present. If _MQ present than get reliable data from kernel. > If _MQ not present, it means this device has one VQ pair. it is still a guess, right? And all user space tools implemented this feature need to guess