From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 8C72D5A004F for ; Fri, 26 Jul 2024 13:39:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721993991; 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=jGlgVC+inJ9VKM0qk9PIGEbBYvU/ZKu2csZFE2VUj5w=; b=JKvWq95J6yIGQ4+YCgxAskQU2dKv78ATUbo1wIxrcvx+VgLvKhPw+wRo9Ta+IhLQWwlJiF pkcbFEwZyoRNc6M8z9EJB5Bn1SECQsfvs3Q/d/rOIkCegBsU9g07bG+ac7e0wVedf7BFyA I9vWKCA7lsC1zVpAenLo89kKJU4QG6k= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-308-ay4t5Y0fMki9QllnrstBYA-1; Fri, 26 Jul 2024 07:39:49 -0400 X-MC-Unique: ay4t5Y0fMki9QllnrstBYA-1 Received: by mail-oi1-f199.google.com with SMTP id 5614622812f47-3db169af7a7so897479b6e.2 for ; Fri, 26 Jul 2024 04:39:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721993988; x=1722598788; 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=jGlgVC+inJ9VKM0qk9PIGEbBYvU/ZKu2csZFE2VUj5w=; b=GwzLSwVSKSzONApQhPV0Me3mF2NArM/FFD7XbIVir1RvHMRIU1b4f+n7OxP/ub35kX 7xh6ticW2/eVb6dl1/GVEzfZbeUBFdCP1ygDCLtydf2KmPtTFr0gVpdNCaDHzQysZ40K 6s0fPrUgGa/PC6WIPSDwfVLv+N62mcbgA3C1XlsOrxJnr3fdtiiRKMV4RrfCWkq/CMg5 nrN+g+N2ADHyST9QEFFtI7EBI3YbbRHhXyDN4uxi1w371vQD0vlJpxpcpOlLIAJw+DTW jsIlPdIFAYn450JD9yEt3+RZfOh6B5BI4t/ve7pQAowrzndyA9kbFmgPX3XxHt8ioZY2 Lm7A== X-Gm-Message-State: AOJu0Yxn2AXM+hTSzKuG7F0CiSqdp2vnSMV73kiIDzHyPMiCT+8hU/Nh siZQqzR3Oxj3tgwKu0HoVIIfb20OZrrC4CaW9sQN1zjuj6CG6aeNMa4U01nrVakLKaD4s5++zgu qCKpX8d6wLp2iAYATES3sE/3vOthGBH2vgFaA1rgpeGRVendSiYuHy9fAH5bS X-Received: by 2002:a05:6358:8a2:b0:1ac:f2aa:2ae4 with SMTP id e5c5f4694b2df-1acfb97c081mr600152855d.21.1721993988505; Fri, 26 Jul 2024 04:39:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEdabSbwj2WItLePELBo5ATHwYVJXOChrdwZu5HdKY9Ftt1xIG6f2vZbqMXpQWlfsgr89N8eg== X-Received: by 2002:a05:6358:8a2:b0:1ac:f2aa:2ae4 with SMTP id e5c5f4694b2df-1acfb97c081mr600150555d.21.1721993987990; Fri, 26 Jul 2024 04:39:47 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6bb3fa95c70sm15802226d6.99.2024.07.26.04.39.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2024 04:39:47 -0700 (PDT) Date: Fri, 26 Jul 2024 13:39:13 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 5/5] tap: Improve handling of partially received frames on qemu socket Message-ID: <20240726133913.6cfa11f5@elisabeth> In-Reply-To: <20240726072031.3941305-6-david@gibson.dropbear.id.au> References: <20240726072031.3941305-1-david@gibson.dropbear.id.au> <20240726072031.3941305-6-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ZPSONENSRWVO5VCMGQGAJYK3BSMN7H7A X-Message-ID-Hash: ZPSONENSRWVO5VCMGQGAJYK3BSMN7H7A 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 Fri, 26 Jul 2024 17:20:31 +1000 David Gibson wrote: > Because the Unix socket to qemu is a stream socket, we have no guarantee > of where the boundaries between recv() calls will lie. Typically they > will lie on frame boundaries, because that's how qemu will send then, but > we can't rely on it. > > Currently we handle this case by detecting when we have received a partial > frame and performing a blocking recv() to get the remainder, and only then > processing the frames. Change it so instead we save the partial frame > persistently and include it as the first thing processed next time we > receive data from the socket. This handles a number of (unlikely) cases > which previously would not be dealt with correctly: > > * If qemu sent a partial frame then waited some time before sending the > remainder, previously we could block here for an unacceptably long time > * If qemu sent a tiny partial frame (< 4 bytes) we'd leave the loop without > doing the partial frame handling, which would put us out of sync with > the stream from qemu > * If a the blocking recv() only received some of the remainder of the > frame, not all of it, we'd return leaving us out of sync with the > stream again > > Caveat: This could memmove() a moderate amount of data (ETH_MAX_MTU). This > is probably acceptable because it's an unlikely case in practice. If > necessary we could mitigate this by using a true ring buffer. I don't think that that memmove() is a problem if we have a single recv(), even if it happens to be one memmove() for every recv() (guest filling up the buffer, common in throughput tests and bulk transfers), because it's very small in relative terms anyway. I think the ringbuffer would be worth it with multiple recv() calls per epoll wakeup, with EPOLLET. -- Stefano