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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 01104C47258 for ; Wed, 24 Jan 2024 02:44:00 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 41CC02B063 for ; Wed, 24 Jan 2024 02:44:00 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 148AA9867D4 for ; Wed, 24 Jan 2024 02:44:00 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id EC4619867D0; Wed, 24 Jan 2024 02:43:59 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D735E9867D2; Wed, 24 Jan 2024 02:43:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=hengqi@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0W.EQG0T_1706064233; Message-ID: <323575e1-339b-4c13-92df-c552c0858fb0@linux.alibaba.com> Date: Wed, 24 Jan 2024 10:43:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "Michael S. Tsirkin" , Parav Pandit Cc: "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , Jason Wang , Xuan Zhuo References: <1705323962-96063-1-git-send-email-hengqi@linux.alibaba.com> <3977e2c2-f514-4b51-a646-6f729df7403d@linux.alibaba.com> <20240122022002-mutt-send-email-mst@kernel.org> <20240123020653-mutt-send-email-mst@kernel.org> From: Heng Qi In-Reply-To: <20240123020653-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [virtio-comment] Re: [virtio-dev] Re: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] [PATCH v2] virtio-net: support setting coalescing params for multiple vqs 在 2024/1/23 下午3:15, Michael S. Tsirkin 写道: > On Tue, Jan 23, 2024 at 05:55:02AM +0000, Parav Pandit wrote: >>> From: Michael S. Tsirkin >>> Sent: Monday, January 22, 2024 1:06 PM >>> >>> On Mon, Jan 22, 2024 at 05:03:38AM +0000, Parav Pandit wrote: >>>>>>>> The right test on Linux to do without rtnl lock which is anyway >>>>>>>> ugly and >>>>>>> wrong semantic to use blocking the whole netdev stack. >>>>>>>> (in case if you used that). >>>>>>> Do you have any good directions and attempts to remove rtnl_lock? >>>>>>> >>>>>> I think per device lock instead of rtnl is first step that we can start with. >>>> Wil check internally who if someone already started working on it. >>> I feel the issue is at the conceptual level. >> Not for requests which are initiated by the kernel stack (non user initiated). > So how is this different? Is it basically just because > tweaking coalescing in unexpected ways is considered mostly > harmless? DIM sends configurations frequently, which is try best. > >>> Yes some drivers will take a command >>> and just queue it for execution later, but this means that errors can not be >>> propagated back at all. Imagine device with mac >>> 0x123 in promisc mode. Now commands: >>> >>> 1- program MAC 0xabcdef >>> 2- disable promisc mode >>> >> User initiated commands error can be propagated when the command completes. >> Enqueuing command is at the different bottom level in the driver. >> >>> If command 1 fails but 2 proceeds then packets with MAC 0xabc will be >>> dropped. >>> >>> Any attempts to batch arbitrary commands will have this issue - be it at driver >>> or device level. >>> >> There is no suggestion to batch arbitrary commands from the driver side. >> The suggestion is to batch VQs notification coalescing from the driver side. >> >>> So, here's my question: what exactly is the guest behaviour that is driving this >>> work? Is it with a linux guest? >> At least looks to me yes based on the partial patches which are taking rtnl lock on netdim's worker callbacks. >> >>> which commands does userspace issue that we >>> need to send multiple vq coalescing commands? >> None. >> >>> If all you want is to send >>> same config to all VQs then why not just use >>> VIRTIO_NET_CTRL_NOTF_COAL_RX_SET as opposed to >>> VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET ? >> Only kernel stack initiated VQ notification coalescing changes. >> Since every VQ has different values, VIRTIO_NET_CTRL_NOTF_COAL_RX_SET is not sufficient. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/