From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XbeTEolv; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id E38E85A026F for ; Tue, 04 Nov 2025 17:09:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762272571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H3j7UytxlCuA4BBSbVzvvi1bsuODnkL+gKTnRtmuiZs=; b=XbeTEolvOxOWqIZFJqBJRut0G11zahHfemIzbnyXt9qSHgSaWdNnwwF54XBUhcNUl7LlHa TGWNXPCS2/Juwh/2vuE4jD6Tt2v6pFHdqVXVHKGalVrjGfNLDLGr0wKctVsdjXgNfYscjF RyuJ2C/DkR7suEXMxVQWWgngYzNBce0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-317-S-tHyH20MNyn06wWknlbtw-1; Tue, 04 Nov 2025 11:09:30 -0500 X-MC-Unique: S-tHyH20MNyn06wWknlbtw-1 X-Mimecast-MFC-AGG-ID: S-tHyH20MNyn06wWknlbtw_1762272569 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-47754e6bddbso8987785e9.3 for ; Tue, 04 Nov 2025 08:09:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762272569; x=1762877369; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=H3j7UytxlCuA4BBSbVzvvi1bsuODnkL+gKTnRtmuiZs=; b=SXFYYi8G35fRd1vkUjIMalLKNUBe3UoZxK6jlAPwSKnB326GksVu2isNmJJOMNxAU/ bkj1T4gdGPn+s/vUpji+XpVmLuFmVc7WmQR2JqJGoipqaJFNBePAGRMeXzxBHG5GN6A8 h6vT+ZK8TjuzWdpGGdEjK3W77noIt+glWHf/Yjsm3dWO8t7vqIg69DcJ49QGrN8VDX83 0OYMA/JwV5BW0ff2KmQP0U+69hrFToy+ENKLKzIDjvRhZLfirkfPIUkhxFsncNy08js3 tE21GlLRY+29jOtlfDZK1+1r6WfcGh8XOnF9fyV96he5d2jLwjAuzLb5ln7HmRkfiTS+ 5xXQ== X-Gm-Message-State: AOJu0YzZ/CCBW+B6+Qa/eM8Ea55zY5d6xBG4N0L687NuYEJ8xaE29Wgo cZeWL9TDqigwphZskFs6IbOsZ8I0ETCAc09oFJotfa293F0/7ZyWzHgHxXGlBICRQwVFjYfZR4J tdTpYWJp9ZQamgMLvZBmyI7021YUtS2aKo+ILHujrqKfUdFRzTs+r+w== X-Gm-Gg: ASbGncvL8OlCT2QCnpipMu2Li2xh7i8LHBaFPbmGEQawXd0iKdpgVAja4iF1VYnW/Jf JjuI0YcdNY0D+NAt7O3ZTT9doZUj6lMJ4rTSBbPY1QOvQEeLbZjs2qqO7EvHmDO7zcWKxmXl59e jU8XCs6CBkkHWT0fu329/ekA5eozdxFuKmtk0IUQXbWQOc3upLXsOqJ3U0nI36/XgaHcgHR+vDd Tzsmzykei4e1ZuR0+2QASpLeOD/LmLUEdfg3dlUQJRn3pargL1nrQBJ9mara47nR+fmB5Dqvet6 qbN91LDjpZQfcDvKKaSVbk2LD+KYv8x09iGyll/IwgU6mlTqZouxmh0ZRR+2piZZrqkZQXT/0yg 2Y+twOEbiKQ== X-Received: by 2002:a05:600c:5020:b0:471:700:f281 with SMTP id 5b1f17b1804b1-477308a15a7mr140009415e9.25.1762272568819; Tue, 04 Nov 2025 08:09:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IF8sfp8tT6ZpwMdFaOqVDpq/J9CyYvE2Y4dsFIazWP4y0AMtJvKsj7l0No8158eza/BdEkifA== X-Received: by 2002:a05:600c:5020:b0:471:700:f281 with SMTP id 5b1f17b1804b1-477308a15a7mr140009135e9.25.1762272568248; Tue, 04 Nov 2025 08:09:28 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4773c48e805sm224163335e9.4.2025.11.04.08.09.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Nov 2025 08:09:27 -0800 (PST) Date: Tue, 4 Nov 2025 17:09:26 +0100 From: Stefano Brivio To: Laurent Vivier Subject: Re: [RFC PATCH 1/3] vu_common: Stick to size of input buffer in vu_send_single() Message-ID: <20251104170926.67d62f34@elisabeth> In-Reply-To: <7e3386c8-e0cc-4dc2-9be1-c938ef757896@redhat.com> References: <20251103101629.1412331-1-sbrivio@redhat.com> <20251103101629.1412331-2-sbrivio@redhat.com> <7e3386c8-e0cc-4dc2-9be1-c938ef757896@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YFoDURCm0z_ILx_xfqxkJIQlrcSgsbhYXoBSSTac4Js_1762272569 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: RIOLHDUCPMQ3GTFB2EG4XGPB2H25RC6A X-Message-ID-Hash: RIOLHDUCPMQ3GTFB2EG4XGPB2H25RC6A X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 4 Nov 2025 16:01:07 +0100 Laurent Vivier wrote: > On 11/3/25 11:16, Stefano Brivio wrote: > > ...instead of copying, from the input buffer, the amount of available > > bytes in the buffer provided via vhost-user. > > > > The existing behaviour should be harmless due to the fact that we > > don't request overly large buffers from vhost-user, but it doesn't > > look correct to me. > > I don't understand where is the problem. > > I think the existing behaviour is correct because the iov array is padded to size in > vu_collect() by: > > if (iov->iov_len > size - current_size) > iov->iov_len = size - current_size; Ah, thanks, this is the part I missed. So the buffers could be bigger, but @frame_size set on return is <= @size. I was misled by: * @frame_size: The total size of the buffers (output) because that made me think that 'total' would be... well, the total size of the (output) buffers, not limited to what we requested. I wonder if we should fix: - this comment (I would call this "Available buffer length, up to @size, set on return") and perhaps the parameter name ("@collected"?) - the prototype. I see why UDP needs it this way, but wouldn't it be more natural to return error if the requested size is not available, and set the available buffer count as optional argument on return? The way it currently is, we're mostly ignoring the value of @frame_size (except for what we need for a comparison) in the only two cases where we actually pass a pointer. Well, we use that value in tcp_vu_sock_recv(), but just as a sum of values we already have in the caller. - or the interface altogether like I'm doing here, so that vu_collect() actually returns the size of the buffers. I think it's more natural like that but also looks a bit more complicated so I'm not necessarily fond of this What do you think? I can just fix the comment instead (feel free to do so, of course). > total can be lesser than size but in this case we exit. > > So total should be equal to input size + sizeof(struct virtio_net_hdr_mrg_rxbuf). > > And in iov_from_buf() we copy the content of the buffer according the available room in > the iovec and the size of the input buffer. Right, I see now. I wonder if 3/3 is even desired in this case, after all it's guest memory that's given to us but we don't touch in any way. If buffers are consistently much larger than what we request (for example, TCP flows with low MSS), we probably introduce substantial overhead by zeroing those bytes. I thought they were filled with random stuff because of the issue I though we had, but we don't have it, so no need to zero them either. -- Stefano