From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=JxQ6Ou2k; 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 ESMTP id 7625D5A004C for ; Tue, 29 Oct 2024 10:10:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730193001; 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=ADbHHGlgowaaB1ojS9MRSWhma2lC+VvBVWzMOi7Bq8U=; b=JxQ6Ou2kj2oh3kuNLdTL/mNui2MzytysnR23j2x2T+Bgrak+ixnOiuoUmofAMM/VqWNcsN SP9muAEmeiBXoeCt5/o+E+EGrwlm/6sm3C9NwhaOh/MNR0YgSmAwDiQAwwiPO1Hhdckkw6 2r7wPjhKDSWaQkKQazooO/4b95kK5yM= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-_HdrPm6jMASyaG3EOQIUJw-1; Tue, 29 Oct 2024 05:10:00 -0400 X-MC-Unique: _HdrPm6jMASyaG3EOQIUJw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2fb652f40f1so29067621fa.2 for ; Tue, 29 Oct 2024 02:09:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730192998; x=1730797798; 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=ADbHHGlgowaaB1ojS9MRSWhma2lC+VvBVWzMOi7Bq8U=; b=QCVImiKwc5Nk68nZac0zVCFc/LdYah76X3pJjJtboZELKaqsoBfWb8YzHYE8++ev2w jNyiAonvNOxXwMSmBO6cwBYBngZRGCgFJdvWEqNI68ZenPxn5pHvlMaxQ3IOQ7qTt9Y4 dE6tmOmbRub6pKARwUvteDEiEukEJsdLbh/cv8e+DqyM5Y7AWnHHY2mJXtHYCc8Qf0B3 F4mgxvbIpT12Hn+NH6axGiVb+PF/elfJP58CzkV/D+x8v74Noz6MNWLn2uXzLJ159sXE 6DF1CmVZjpuej7hDSv5u7OixoekwjzIgNdrJ7z2osHKaR/+hevVc41Br9hFUiFz+NNVI iiJg== X-Forwarded-Encrypted: i=1; AJvYcCUJtw59Ul2u/5VXr+1AXrJY9s0nhOI6tPoXrHmnJEfOsajVPep6/7Pks/NXxJIzhsZj07aZ3wANydU=@passt.top X-Gm-Message-State: AOJu0YwSSJP5fUJ5mTvw29geXMdoHG8drSFpj7ORpiaBfaVUKsmBmEen OpjCnX4wQC1gAL14IrabT711nZVnIzz3my5p72JzI1FPiNFBxc2y6O3xBC8lD5x+fTHqLGm0KBQ QvZjGSy1Qr2g1b+xFNkyx4mRN7PD1VyNomt7xsTE0QcR2aR4ORA== X-Received: by 2002:a05:6512:2344:b0:539:951f:27c2 with SMTP id 2adb3069b0e04-53b34c40235mr3760271e87.61.1730192998437; Tue, 29 Oct 2024 02:09:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHLsD/RWCvDyikH+0FWXEuNP8qqKPe2LlLe/72uQNClxkFN4ghirACttPmCTPAKCKda3CIkMA== X-Received: by 2002:a05:6512:2344:b0:539:951f:27c2 with SMTP id 2adb3069b0e04-53b34c40235mr3760257e87.61.1730192997941; Tue, 29 Oct 2024 02:09:57 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38058b713fbsm11914837f8f.88.2024.10.29.02.09.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2024 02:09:56 -0700 (PDT) Date: Tue, 29 Oct 2024 10:09:54 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 1/7] tcp: Pass TCP header and payload separately to tcp_update_check_tcp[46]() Message-ID: <20241029100954.7eb6b8a9@elisabeth> In-Reply-To: References: <20241028094050.1609090-1-david@gibson.dropbear.id.au> <20241028094050.1609090-2-david@gibson.dropbear.id.au> <20241028194254.71df8d2f@elisabeth> 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: SIUXSBIQ3DTPS2KS4DDJQAAO5UHSCTNV X-Message-ID-Hash: SIUXSBIQ3DTPS2KS4DDJQAAO5UHSCTNV 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: Laurent Vivier , 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, 29 Oct 2024 15:07:56 +1100 David Gibson wrote: > On Tue, Oct 29, 2024 at 02:02:25PM +1100, David Gibson wrote: > > On Mon, Oct 28, 2024 at 07:42:54PM +0100, Stefano Brivio wrote: > > > On Mon, 28 Oct 2024 20:40:44 +1100 > > > David Gibson wrote: > > > > > > > Currently these expects both the TCP header and payload in a single IOV, > > > > and goes to some trouble to locate the checksum field within it. In the > > > > current caller we've already know where the TCP header is, so we might as > > > > well just pass it in. This will need to work a bit differently for > > > > vhost-user, but that code already needs to locate the TCP header for other > > > > reasons, so again we can just pass it in. > > > > > > We couldn't do this, and also what you're now doing in 5/7, because > > > with vhost-user the TCP header is not aligned, so we can't pass it > > > around as a pointer, see: > > > > > > > > > https://archives.passt.top/passt-dev/ZeUpxEY-sn64NLE5@zatzit/ > > > > > > and following. That one is about IP headers, but the same applies to > > > TCP and UDP headers. > > > > Hrm. I'm aware it theoretically need not be aligned, but I thought it > > was in practice.. and that we were already relying on that. > > > > In fact, I'm pretty sure the second part is true, although more subtly > > than here. v8 of the vhost-user patches calls tcp_fill_headers[46]() > > with the bp parameter set to the offset of the TCP header. If > > creating a tcphdr * there is a problem, then creating a tcp_payload_t > > * can't be any better. Ah, okay, I missed that. Still, I think we should ask gcc for an opinion (with the vhost-user series on top of this series), because those build-time pointer alignment checks are pretty reliable. > > > Of course the current solution is not elegant and it would be nice to > > > find another way to deal with it, but we couldn't come up with anything > > > better back then. > > > > > > The rest of the series looks good to me, but I'm afraid that without > > > this one and 5/7 the other changes will be a bit more complicated to > > > implement (if at all possible). > > > > Definitely. I have so ideas for approaches more robust to > > misalignment, but they're substantially more complicated. I was > > hoping we could avoid it at least for now. > > I had a closer look at that earlier message now. I believe at the > time I was aiming for fully robust handling of misaligned user > buffers. AIUI, we've given up on that for the time being: instead > we'll just *test* for suitable alignment and we can do the hard work > of handling it if it ever arises in practice. Right, and we can use the compiler to test for suitable alignment. -- Stefano