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=QMRekeCh; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id AB4DE5A0285 for ; Mon, 02 Jun 2025 15:36:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1748871364; 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=kLcGN+4lNfb2Rnkio9+ZMv84QRZkgoOnP9QiBy8T5t0=; b=QMRekeChZaydCCzPu9KWg724p6rLBQbHHSUh6zOYFg07L4dgLXHcRwUZfEsRiho8FoGVci R+PpFubxa+YYyOK0NRIhn4VebxeO4ZTWHISnjcfepsH0L9CkU+DsSfCArBbhuK1V8jzIW1 VkRLqnc9LmOHpL7QfqS6bVufyeQ4CWg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-688-ZmZPK0B3NSyHGqSjlz9LqA-1; Mon, 02 Jun 2025 09:36:02 -0400 X-MC-Unique: ZmZPK0B3NSyHGqSjlz9LqA-1 X-Mimecast-MFC-AGG-ID: ZmZPK0B3NSyHGqSjlz9LqA_1748871361 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-39ee4b91d1cso2487342f8f.0 for ; Mon, 02 Jun 2025 06:36:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748871360; x=1749476160; 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=kLcGN+4lNfb2Rnkio9+ZMv84QRZkgoOnP9QiBy8T5t0=; b=naOMpOOe6Fji7Z2Ma2awqxkaCLRnmhfOk+YfgfqG7fOijq5zUS5xBLKEBnG+lXP56f l0GhipGkwidR4fq+pUubogbWb5Dk76R05hNJs3xKmD+UicKtXb2+6x8YoWFx5apS8d37 O96jR0tnEAiNtNrbKPpQMM4JdeyxeEc0gWA9ml2VrQOKXypQ0Sx2ZAcT/xrJWIm98ESC 8Yk58+t3B5avtWR+cfICU5J3PlXihAOoeK3h/BKQU6X8Ey6Lr7DyKMQ9rjxXC16fibJy m3c6ui0W3xakkm/OfZL+wzO4Q+IZsDZ5mbNmZosBUgyEEnpoygbsNMDdU48sZ5zgaccM W2TQ== X-Gm-Message-State: AOJu0YwtZa6CxZBr8FAWEKWl5u/kdZUbVZ0IIjvCp+pB0AM3G2ECgY/B k4+u7ba/ZeKgpEBW/ETaSu2gnWVOWfSl/26nGRolTa8gsO4io6Ol/KYcDAOQHmsiCrHmPZ27RDb fBa73DZi43WUtQdxMFSLp9gGNRz8xl3iSId/RiyVrF9bJ5Xp4kMH+AHwaxvkezaQGqRLEaKoLAf pqnzdkFAovH6F1EEHTuOrE+m7Ub+2gUjJsKRYu X-Gm-Gg: ASbGncs05sjrdzmPs3+Qnab5glc9jvyczFJQ+io06MJmhH7TgxR5Fz62DEVRlmcsZdS WVLs8I3M72XdVPZnzHcwev223rUJBcfzyYLQaUi0HpTVdLbMRFJZmwKyeB3imjIOe8/TdoYPRkY 0SpX16n83ChgLc+PIj7IK27zoaxcif7mODImnggR90KuDW6RIJ5QTrn/SJLRofwgg9zYZ+fwGrE iOI/x/S/3h3pWiIHayWIUcjYFNXaeCDrejFhjcr+kLVQl/a32BJeKaVXlv6W3Tmxlf6CpzUR7G5 wf2bcjn6e768Th1mu+aQmpIK8I2GU8W/CU/cTR7tEFMT2mg+Ho0= X-Received: by 2002:adf:f58a:0:b0:3a4:f7e7:3630 with SMTP id ffacd0b85a97d-3a4f7e7365dmr9668877f8f.15.1748871360022; Mon, 02 Jun 2025 06:36:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEkuG0SWIaiAKVjlNXlbcnHgVYt4NicnHvrPvxfz/5DUhOPIIa2pgARGiCCK2HEcGqUMNyuyw== X-Received: by 2002:adf:f58a:0:b0:3a4:f7e7:3630 with SMTP id ffacd0b85a97d-3a4f7e7365dmr9668853f8f.15.1748871359537; Mon, 02 Jun 2025 06:35:59 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f00a017esm14618490f8f.89.2025.06.02.06.35.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 06:35:58 -0700 (PDT) Date: Mon, 2 Jun 2025 15:35:57 +0200 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v5 29/29] packet: use buf to store iovec array Message-ID: <20250602153557.5ffe9345@elisabeth> In-Reply-To: References: <20250417165136.2688884-1-lvivier@redhat.com> <20250417165136.2688884-30-lvivier@redhat.com> <20250526162146.52d68c66@elisabeth> 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: 0RqzvLsWW2NdieoSqN3X0-GJGhJII64EXZUNafAXSBU_1748871361 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 2MAZD7UK4VX4G4VQBTKQPG7SFKU5U37B X-Message-ID-Hash: 2MAZD7UK4VX4G4VQBTKQPG7SFKU5U37B 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 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, 27 May 2025 15:16:04 +0200 Laurent Vivier wrote: > On 26/05/2025 16:21, Stefano Brivio wrote: > > On Thu, 17 Apr 2025 18:51:36 +0200 > > Laurent Vivier wrote: > > > >> When we use vhost-user we don't use the memory buffer > >> of the pool to store the packet, so we can use it to > >> store iovec array that points to the memory provided > >> by vhost-user. > >> > >> Signed-off-by: Laurent Vivier > >> --- > >> packet.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++++------ > >> 1 file changed, 147 insertions(+), 16 deletions(-) > >... > >> +/** > >> + * packet_iov_next_idx() - Give the the next available iovec index > >> + * @p: Pointer to packet pool > >> + * @idx: Index of packet descriptor in pool > >> + * @func: For tracing: name of calling function > >> + * @line: For tracing: caller line of function call > >> + * > >> + * Return: the next available iovec index > >> + */ > >> +static size_t packet_iov_next_idx(const struct pool *p, size_t idx, > >> + const char *func, int line) > >> +{ > >> + size_t iov_idx, iov_cnt; > >> + > >> + if (idx == 0) > >> + return 0; > > > > I'm a bit lost here. Why is 0 a special value now? > > See below: we use "idx - 1" > > > > >> + > >> + iov_idx = packet_iov_idx(p, idx - 1, &iov_cnt, func, line); > >> + > >> + return iov_idx + iov_cnt; > >> +} > >> + > > The next available iovec index for a given packet index is computed using the information > from the previous packet index: > > We take first available iovec index after the iovecs used by the previous packet. > > The next available iovec index is the iovec index base of the previous packet plus all the > iovecs used by the previous packet: > > next available iovec index = (base iovec index of previous packet) + (number of iovec used > by previous packet) > > So, for the first packet (packet index 0), the first available iovec index is 0, we can't > compute it from the previous packet because it doesn't exist (and all the iovec are free > and available) Ah-ha, thanks, I followed through the whole path again and it makes sense now. Maybe we could change the comment to @idx, or say "subsequent" instead of next... but I can't come up with a good idea at the moment. -- Stefano