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=Y9pOCR4u; 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 ESMTP id BB0485A004E for ; Wed, 16 Oct 2024 18:26:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729095998; 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=pKXZRI8DDrYEX5aZk2z3cwkQuzSwojqIDJd+u7ulmCk=; b=Y9pOCR4uWO9zRi0icCVgvfK2aNbn6PqfHH5R53u948o/kGi10nI/y6cDhbuZcB49GNtI9b 3cYlsAGLSk0KKn8I+7QKr6DAhyAZwuGYfZ4LEwdRm06qv1dLVlnAI1RYipvfNFP72hEz8o CrV2F8JMY8QfLAOOiLenUkIhbhZ5/S8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-626-evrzyHNGMpSpGlEIXPGDyA-1; Wed, 16 Oct 2024 12:26:37 -0400 X-MC-Unique: evrzyHNGMpSpGlEIXPGDyA-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-431285dd196so197065e9.0 for ; Wed, 16 Oct 2024 09:26:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729095996; x=1729700796; 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=pKXZRI8DDrYEX5aZk2z3cwkQuzSwojqIDJd+u7ulmCk=; b=w9pmId/NX3pZ+kXMOLZ9l0qK+QeUIEzx+K20tZeBXQQgf4MTAlyYmKg2fjAWZoUrgK V0Xcy/KReizJ/je7jwlheyUgx6oFaEOPLboye+nH5CArAFrQDydDHuAlW+aW65D/1Q0W 5jb45UgjGVFn3p5iCCFEyJ/TqwEitUe1GBQKSv4dZAjSdADc9nBItc2i9PuwA46eFDSC Z2/Bi1zQHAZaCsbgXCSW71mvkWylRqH2QkBAcGztqyJ7FBEaO6B2lwDOZgnU2r4rrHUK NeCCVnewgb9kKymURhM9tIBXcETgZXouP40WPmiqyGX5mWbZwzzbo67R8l4bu9//Ekyf QRMg== X-Forwarded-Encrypted: i=1; AJvYcCUmakDy9iNEXiMVuApOQAgmdsDtmOZ/BsvZvBgsmvJUbWGrSsb1iF7VU93UPW0mjDwLfeY2+0Qwgc0=@passt.top X-Gm-Message-State: AOJu0Yzk1C/qwl51BIILX8Ij6IXaiGSFfy+FVjWDCAwQ2jhFU7UIvzTB bViMR9HCxax7Ns4jnmDW+EH2Wd7ZQQHdlU8bWoUzf8gYTDhOW0bnmi9hOg0+f5Rq0C+R0CeAY/B Nk7Ud0ay24sA+j946osY12dyfhy9xefI92lIww6+040A4jmiU2Q== X-Received: by 2002:a05:600c:228c:b0:42f:80f4:ab2b with SMTP id 5b1f17b1804b1-4311dee6f58mr175655635e9.19.1729095996357; Wed, 16 Oct 2024 09:26:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEP5pAQM0vJBngBUkxnJnY9yz4BRytZAETIqjT3w5h5knv7opJLdUokeWMrcdeLb1AUYGnsiA== X-Received: by 2002:a05:600c:228c:b0:42f:80f4:ab2b with SMTP id 5b1f17b1804b1-4311dee6f58mr175655455e9.19.1729095995908; Wed, 16 Oct 2024 09:26:35 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fa908fdsm4695334f8f.52.2024.10.16.09.26.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 09:26:35 -0700 (PDT) Date: Wed, 16 Oct 2024 18:26:33 +0200 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v8 7/8] vhost-user: add vhost-user Message-ID: <20241016182633.659b4933@elisabeth> In-Reply-To: <45e1f806-7516-41df-a11f-028516bfd513@redhat.com> References: <20241010122903.1188992-1-lvivier@redhat.com> <20241010122903.1188992-8-lvivier@redhat.com> <45e1f806-7516-41df-a11f-028516bfd513@redhat.com> 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: MPK2F6NZXW6M33SJBXWDQ5G3L4NDCQAW X-Message-ID-Hash: MPK2F6NZXW6M33SJBXWDQ5G3L4NDCQAW 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: David Gibson , 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 Wed, 16 Oct 2024 12:07:21 +0200 Laurent Vivier wrote: > On 15/10/2024 05:23, David Gibson wrote: > >> +/** > >> + * tcp_vu_update_check() - Calculate TCP checksum > >> + * @tapside: Address information for one side of the flow > >> + * @iov: Pointer to the array of IO vectors > >> + * @iov_used: Length of the array > >> + */ > >> +static void tcp_vu_update_check(const struct flowside *tapside, > >> + struct iovec *iov, int iov_used) > > AFAICT this is only used for the pcap path. Rather than filling in > > the checksum at a different point from normal, I think it would be > > easier to just clear the no_tcp_csum flag when pcap is enabled. That > > would, AFAICT, remove the need for this function entirely. > > To do that is a little bit complicated because we need to pass the iov array to > tcp_fill_headers4()/tcp_fill_headers6() to be able to compute the checksum of the TCP part. > > In tcp_buf, the TCP header and TCP payload are in the same iovec but with tcp_vu they can > be split on several iovecs. And if we provide the iovec , theoretically we should not > provide the TAP, IP and TCP headers via the parameters as they are in the iovec, but for > tcp_buf they have one iovec each, and with tcp_vu they are probably all in the same iovec > (the first one). So, again, it can be complicated to extract headers to update them. > > In conclusion, I update the checksum only for VU and in the case of pcap because it is > simpler (the same logic applies for udp_update_hdr4()/udp_update_hdr6()). > > I'm open to any suggestion that could do the checksum in > udp_update_hdr4()/udp_update_hdr6() (I agree with you, it should be the place to do it) > but I don't see an easy and nice way to implement it. I don't really have a suggestion here, but this is probably the first use case we met where switching to the pcapng format would make sense, as we could just mark the checksum as "offloaded" in this case: https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcapng.html#section-4.3.1 On the other hand, it comes with a lot of complexity in my opinion so I still think that it wouldn't make sense in general. -- Stefano