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=EndB1Uil; 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 3F12D5A026F for ; Tue, 04 Nov 2025 17:24:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762273466; 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:autocrypt:autocrypt; bh=PWX7LxzPgz9aoY7JKINwKf5UWZjLFJIpNEGmKtpz/Ic=; b=EndB1UilQmuIDjrGWe4KgU773KjN5tRTXvwXEalbV4PyqJfXdh7QUHD/dMlbn0ApLXc9rZ BuXEejCCbodq7BWMEcjhsQE+CZkcrwS773vBbKtOphu7eMEqmcctjA6/SyioDrdghbEGNQ jpo48j06oGXYyB7opbuskaywBp7k73I= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-539-NtFVWYIPNgWtTARnNqYc_A-1; Tue, 04 Nov 2025 11:24:16 -0500 X-MC-Unique: NtFVWYIPNgWtTARnNqYc_A-1 X-Mimecast-MFC-AGG-ID: NtFVWYIPNgWtTARnNqYc_A_1762273452 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-42814749a6fso4244424f8f.2 for ; Tue, 04 Nov 2025 08:24:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762273452; x=1762878252; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PWX7LxzPgz9aoY7JKINwKf5UWZjLFJIpNEGmKtpz/Ic=; b=upeUsg6PIYgwDB9ACxKr6AIoVQMDB+WAwpm7SnmSeqQoZzfTF9TNmMmhkP9U7LZDwb V7xomlc+tXL8T7Ncg/lIOf6h7OJARzOnvvmCXI7KXADWy7oIS+e0m/zBcEFVinyrOHzh UZcbSs11U/kPL6xgCrNE+n/eqOwx3IQ8y/npR5Nx/XR4+PlPV2djRhwk+SVrzUDFljUx gMMXx0MRntzPJI6ipNQYO3Zi11Tt3PmLNS+/p7wdstX8m96oFT7WuVW2GouwWKMQDm1z LEdFJqHa0FPdr2E6HncM7W+hYOdDz3qTE7t0gU9avbCEMalxoe7z4dDM6NWwPmCU47A5 4hdQ== X-Gm-Message-State: AOJu0Yw3GQR59IdA/NE+X0SUDW0FPIXQbt+nNmtdeLMLCC0ry3uI1YqI NT6yyy06UlRBtVj9Jh+ReJhXUh+P6SZ6tX7KwmB/tfT7hIghI1aTZtQAB7SrqKLpKQoB9/qIzpl L58AW4uB3BJ+wxCngFX0uB7MPJa/li2jJRmUHpj1tnr2I9hoo9PmmfA== X-Gm-Gg: ASbGnctBOxHdgrJFfU45Mj4OIzxQBNp70SWvuduKmhyIMQifYhI6Fo3zlI+2vKOtguz 8CvJz/5mJzjJBeJQyQoRC5dO/r7AUCTDxpkuEyBwWRJoTC2rCHU3+zKvOPzlrXmWLK6yOeXbFaG Oo0U6eKvLgqh1jwMXI2iqLYuUL+6zfbp7jgg0Ib/RParsaUZCdUYR/m8kGM82bVqmCDZk2jkHOU ynH8CiAQu5h+XKDXRj/U/bVdq9DEKTVGjmgpK8vAJ8V+y3d5OpegSKdtZExGPw8p3DhIiLUEFOJ Nm0EWkY5PMrhB+5j9EX0RmPGrjqVlP+RHAGj60+HW8hgdGIth9ILtpbsMvp8Djmy2IYI+mR0FUf bc+8bTXSq10iEOOTKPLzlMBgC7EmdiI18RiOQLg== X-Received: by 2002:a05:600c:3149:b0:477:942:7521 with SMTP id 5b1f17b1804b1-477307e285dmr150235555e9.14.1762273451825; Tue, 04 Nov 2025 08:24:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IEybapz33ug9yHWyf0F7F3JAV4dtdgz8UBUFcGuuVBF4xoz+phnyKfxv0nRJfUAHq5YlLht/Q== X-Received: by 2002:a05:600c:3149:b0:477:942:7521 with SMTP id 5b1f17b1804b1-477307e285dmr150235145e9.14.1762273451233; Tue, 04 Nov 2025 08:24:11 -0800 (PST) Received: from ?IPV6:2a01:e0a:e10:ef90:343a:68f:2e91:95c? ([2a01:e0a:e10:ef90:343a:68f:2e91:95c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-429dc1f5be4sm5247915f8f.31.2025.11.04.08.24.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Nov 2025 08:24:10 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2025 17:24:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/3] vu_common: Stick to size of input buffer in vu_send_single() To: Stefano Brivio References: <20251103101629.1412331-1-sbrivio@redhat.com> <20251103101629.1412331-2-sbrivio@redhat.com> <7e3386c8-e0cc-4dc2-9be1-c938ef757896@redhat.com> <20251104170926.67d62f34@elisabeth> From: Laurent Vivier Autocrypt: addr=lvivier@redhat.com; keydata= xsFNBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABzSNMYXVyZW50IFZp dmllciA8bHZpdmllckByZWRoYXQuY29tPsLBeAQTAQIAIgUCVgVQgAIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQ8ww4vT8vvjwpgg//fSGy0Rs/t8cPFuzoY1cex4limJQfReLr SJXCANg9NOWy/bFK5wunj+h/RCFxIFhZcyXveurkBwYikDPUrBoBRoOJY/BHK0iZo7/WQkur 6H5losVZtrotmKOGnP/lJYZ3H6OWvXzdz8LL5hb3TvGOP68K8Bn8UsIaZJoeiKhaNR0sOJyI YYbgFQPWMHfVwHD/U+/gqRhD7apVysxv5by/pKDln1I5v0cRRH6hd8M8oXgKhF2+rAOL7gvh jEHSSWKUlMjC7YwwjSZmUkL+TQyE18e2XBk85X8Da3FznrLiHZFHQ/NzETYxRjnOzD7/kOVy gKD/o7asyWQVU65mh/ECrtjfhtCBSYmIIVkopoLaVJ/kEbVJQegT2P6NgERC/31kmTF69vn8 uQyW11Hk8tyubicByL3/XVBrq4jZdJW3cePNJbTNaT0d/bjMg5zCWHbMErUib2Nellnbg6bc 2HLDe0NLVPuRZhHUHM9hO/JNnHfvgiRQDh6loNOUnm9Iw2YiVgZNnT4soUehMZ7au8PwSl4I KYE4ulJ8RRiydN7fES3IZWmOPlyskp1QMQBD/w16o+lEtY6HSFEzsK3o0vuBRBVp2WKnssVH qeeV01ZHw0bvWKjxVNOksP98eJfWLfV9l9e7s6TaAeySKRRubtJ+21PRuYAxKsaueBfUE7ZT 7zfOwU0EVgUmGQEQALxSQRbl/QOnmssVDxWhHM5TGxl7oLNJms2zmBpcmlrIsn8nNz0rRyxT 460k2niaTwowSRK8KWVDeAW6ZAaWiYjLlTunoKwvF8vP3JyWpBz0diTxL5o+xpvy/Q6YU3BN efdq8Vy3rFsxgW7mMSrI/CxJ667y8ot5DVugeS2NyHfmZlPGE0Nsy7hlebS4liisXOrN3jFz asKyUws3VXek4V65lHwB23BVzsnFMn/bw/rPliqXGcwl8CoJu8dSyrCcd1Ibs0/Inq9S9+t0 VmWiQWfQkz4rvEeTQkp/VfgZ6z98JRW7S6l6eophoWs0/ZyRfOm+QVSqRfFZdxdP2PlGeIFM C3fXJgygXJkFPyWkVElr76JTbtSHsGWbt6xUlYHKXWo+xf9WgtLeby3cfSkEchACrxDrQpj+ Jt/JFP+q997dybkyZ5IoHWuPkn7uZGBrKIHmBunTco1+cKSuRiSCYpBIXZMHCzPgVDjk4viP brV9NwRkmaOxVvye0vctJeWvJ6KA7NoAURplIGCqkCRwg0MmLrfoZnK/gRqVJ/f6adhU1oo6 z4p2/z3PemA0C0ANatgHgBb90cd16AUxpdEQmOCmdNnNJF/3Zt3inzF+NFzHoM5Vwq6rc1JP jfC3oqRLJzqAEHBDjQFlqNR3IFCIAo4SYQRBdAHBCzkM4rWyRhuVABEBAAHCwV8EGAECAAkF AlYFJhkCGwwACgkQ8ww4vT8vvjwg9w//VQrcnVg3TsjEybxDEUBm8dBmnKqcnTBFmxN5FFtI WlEuY8+YMiWRykd8Ln9RJ/98/ghABHz9TN8TRo2b6WimV64FmlVn17Ri6FgFU3xNt9TTEChq AcNg88eYryKsYpFwegGpwUlaUaaGh1m9OrTzcQy+klVfZWaVJ9Nw0keoGRGb8j4XjVpL8+2x OhXKrM1fzzb8JtAuSbuzZSQPDwQEI5CKKxp7zf76J21YeRrEW4WDznPyVcDTa+tz++q2S/Bp P4W98bXCBIuQgs2m+OflERv5c3Ojldp04/S4NEjXEYRWdiCxN7ca5iPml5gLtuvhJMSy36gl U6IW9kn30IWuSoBpTkgV7rLUEhh9Ms82VWW/h2TxL8enfx40PrfbDtWwqRID3WY8jLrjKfTd R3LW8BnUDNkG+c4FzvvGUs8AvuqxxyHbXAfDx9o/jXfPHVRmJVhSmd+hC3mcQ+4iX5bBPBPM oDqSoLt5w9GoQQ6gDVP2ZjTWqwSRMLzNr37rJjZ1pt0DCMMTbiYIUcrhX8eveCJtY7NGWNyx FCRkhxRuGcpwPmRVDwOl39MB3iTsRighiMnijkbLXiKoJ5CDVvX5yicNqYJPKh5MFXN1bvsB kmYiStMRbrD0HoY1kx5/VozBtc70OU0EB8Wrv9hZD+Ofp0T3KOr1RUHvCZoLURfFhSQ= In-Reply-To: <20251104170926.67d62f34@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Io2aQ6Tc-zNUL0FzF2T8f1R-v_sS-qZjMUxQNWydkHM_1762273452 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 6GIK2RWEUF6A3QOVOYYGGQPVER2CTWVT X-Message-ID-Hash: 6GIK2RWEUF6A3QOVOYYGGQPVER2CTWVT X-MailFrom: lvivier@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 11/4/25 17:09, Stefano Brivio wrote: > 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). There is a problem in the code as it's not obvious how it works (some part are a little bit touchy...). So I think it needs to be changed, not especially in the logic but in the clarity. I would say that it would be more natural to return an error if the requested size is not available. Choose the solution you prefer to be clear for you but avoid to change the behaviour as it can introduce unexpected results... Thanks, Laurent