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 C4AEF5A0082 for ; Thu, 16 Feb 2023 08:43:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676533392; 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=v4TjMcV7vzGa5FJ8RB1L7vUxR4QHIGr+RciIgVqttz0=; b=hZpxMxMhsbueLxyu8kbW+c3MUWmlK/7ogABrfuyxJYKCEE4wMIN5RCl8Fz9bMi429UhCvw EWss1cJeUF6a3OXmckCchyRBjE1Emtv9tq4cAXLaY6bPwacLVPp99Bg497SNcAcKXz2chY tfeMUQ4A3EbbEg5Y+ZksHioM59mHMso= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-68-enInJEl8ObS3TUF7c9KBkw-1; Thu, 16 Feb 2023 02:43:11 -0500 X-MC-Unique: enInJEl8ObS3TUF7c9KBkw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3D4831C05AC2; Thu, 16 Feb 2023 07:43:11 +0000 (UTC) Received: from maya.cloud.tilaa.com (unknown [10.33.32.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A4FB2026D4B; Thu, 16 Feb 2023 07:43:10 +0000 (UTC) Date: Thu, 16 Feb 2023 08:43:00 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 1/4] tap: Don't pcap frames that didn't get sent Message-ID: <20230216084300.0c73da63@elisabeth> In-Reply-To: References: <20230127051110.2513363-1-david@gibson.dropbear.id.au> <20230127051110.2513363-2-david@gibson.dropbear.id.au> <20230215131725.02d3c6fd@elisabeth> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: JQ4U7PUFVBLWQOTH2L6B5CTXTB73SZGE X-Message-ID-Hash: JQ4U7PUFVBLWQOTH2L6B5CTXTB73SZGE 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.3 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 Thu, 16 Feb 2023 16:20:44 +1100 David Gibson wrote: > On Wed, Feb 15, 2023 at 01:17:25PM +0100, Stefano Brivio wrote: > > On Fri, 27 Jan 2023 16:11:07 +1100 > > David Gibson wrote: > > > > > In tap_send_frames() we send a number of frames to the tap device, then > > > also write them to the pcap capture file (if configured). However the tap > > > send can partially fail (short write()s or similar), meaning that some > > > of the requested frames weren't actually sent, but we still write those > > > frames to the capture file. > > > > > > We do give a debug message in this case, but it's misleading to add frames > > > that we know weren't sent to the capture file. Rework to avoid this. > > > > To be really "correct", I guess we should also truncate messages in > > captures if they were sent partially, by returning the number of bytes > > sent from tap_send_frames_{pasta,passt}() and then modifying the > > argument to pcap_frame() in the pcap_multiple() loop. > > True.. that only applies for the pasta case, though. For passt we > always send a whole frame, or the stream would get out of sync. Actually, I was thinking of the passt case too: the send() in tap_send_remainder() might fail -- but then, contrary to what I wrote, there's nothing to truncate, because the socket back-end in QEMU doesn't deliver partial frames either. So this patch is actually correct in that regard. Unrelated: given that QEMU is going to have a "reconnect" option: http://patchwork.ozlabs.org/project/qemu-devel/patch/20230119101645.2001683-1-lvivier@redhat.com/ perhaps, if tap_send_remainder() fails, we should now close the socket to give the guest the best chances to recover? Compared to terminating the process, this has the advantage of keeping the whole state. -- Stefano