From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 25FA11FF163 for <inbox@lore.proxmox.com>; Thu, 19 Dec 2024 09:05:48 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D6DC12D569; Thu, 19 Dec 2024 09:05:44 +0100 (CET) Message-ID: <f665fcbe-6ce3-44ad-b63b-b2b22d927958@proxmox.com> Date: Thu, 19 Dec 2024 09:05:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Friedrich Weber <f.weber@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20241025111304.99680-1-f.weber@proxmox.com> <20241025111304.99680-2-f.weber@proxmox.com> <9ffcd2a7-54c6-43b4-8e11-3a8f7bdbdfeb@proxmox.com> <b5a7b0e5-91db-4fd1-8783-815c8b71a7fd@proxmox.com> Content-Language: en-US In-Reply-To: <b5a7b0e5-91db-4fd1-8783-815c8b71a7fd@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH storage 1/2] fix #5779: rbd: allow to pass custom krbd map options X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 30/10/2024 17:49, Friedrich Weber wrote: > [...] > > Yeah, I see the point. > > Of course, another alternative is enabling `rxbounce` unconditionally, > as initially requested in [1]. I'm a hesitant to do that because from > reading its description I'd expect it could have a performance impact -- > it's probably small, if any, but this should probably be checked before > changing the default. > I took another look at this: When rxbounce was first introduced, there was a discussion whether krbd could enabled automatically switch to "rxbounce mode" if needed [0]. I asked upstream whether this seems realistic [1], and they responded it's very unlikely to happen. So the cleanest solution from a user point of view might be if PVE automatically passes rxbounce only when mapping disks of Windows VMs. But as Fabian points out [2], this would require some way to pass this information to the storage layer. Of course always passing rxbounce is still an option. Upstream confirmed there is a theoretical performance impact, but it might be negligible in practice [0]. So if benchmarks show the impact is indeed negligible, we could go for that route. But even with benchmarks done carefully, there is a chance that they fail to catch a performance impact on some types of workloads. So in order to not disturb setups that currently work fine without rxbounce, I have a slight preference for only passing rxbounce when needed, even if that requires some architectural changes. [0] https://lore.kernel.org/all/894a36483c241e0cc5154e09e8dd078f57a606d5.camel@kernel.org/ [1] https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/ZSXCXPTLMQPV27Y7I375OBR7CN56LDGH/ [2] https://lore.proxmox.com/pve-devel/1234079298.5156.1730294987348@webmail.proxmox.com/ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel