From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4503541B8C; Tue, 31 Jan 2023 09:18:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F806427EE; Tue, 31 Jan 2023 09:18:15 +0100 (CET) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by mails.dpdk.org (Postfix) with ESMTP id CB6DC40DFB for ; Tue, 31 Jan 2023 09:18:11 +0100 (CET) Received: by mail-ej1-f45.google.com with SMTP id ml19so15692921ejb.0 for ; Tue, 31 Jan 2023 00:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=Vea35mctDmZAGEY/GFwFR8o6yP+LZ3D2VvXqQ6DQkxc=; b=dR6O5Qum18ahD82I1Zu0RbCedOtzC7/g0fZ/E9SYBUFKXYbCUdWQ5HAOpsQ6b23znd CVWCNegVoCToEHsz8/ymB2JU4B/gKBqaEmfLD+F4z+Q5KlFBDXbCoGW/lCLjhhSc7Mt6 dzcZj2Pi8vhs3cfWBNe16hDPYIXNsi1PVZ6BvccDK/TxuQ3+KVYS6AhAsKfSdJr8DWbS m4Lt+/+wyqUPGzPyQapZXUXQtVxYODY/GUEE3ZpGRcCbfNB6FJi1pGlC9QiFmsC1e2iN 0NpFFF2+yYKtvtgJmLBBy54aBG3XQM87L9yYlwBp4GvB5hN3VN5fjA0bD59Z1eVeystD aGhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vea35mctDmZAGEY/GFwFR8o6yP+LZ3D2VvXqQ6DQkxc=; b=YGjhWIuk4qe5ed/gtoRuTMkLGLRy1gR/w7MG/TFlj18tvQ9oW1lQSXMfWeSb2HT5A2 LmZEFyHD2jgOy0ea51mJxooIkGPEYhmb6zdXMG8tT4Hl+LZCCj9QqTaPpMzerfYjk17m g4ybK7Tsxhav3rGTTNCpKBgxwLZreudNoWxLVPgmbB876V1oVbZpOWjMQ2mJDP7gL2lf tK2W8JOY1idsNZ8vlDENpRL45gkYTuV9SSoN40vfbPrMCk9VKxgs6i05StyQPbha2gl/ f7kym50A71gRGCDSKJSuHOCZs44TGfOij1vogHdlr9h+kpO+q7f+vsSUK9CHzWULAFPa H/kQ== X-Gm-Message-State: AO0yUKULrXcT7VH/H2byCQYXBFXhRfIofSIVwcHSNvwXTl2l1d3o4duD DiqOXSS3I0pF5V42KEnHbgQ= X-Google-Smtp-Source: AK7set/UtZZQlngxiZt3eGxcbeW9vYFmszlE/j4tWUHjX7PZWFujl7Wrtgg4MUS9lZiqr0IdlZDPHg== X-Received: by 2002:a17:907:b603:b0:872:84dd:8903 with SMTP id vl3-20020a170907b60300b0087284dd8903mr2704044ejc.59.1675153091568; Tue, 31 Jan 2023 00:18:11 -0800 (PST) Received: from smtpclient.apple ([176.89.195.60]) by smtp.gmail.com with ESMTPSA id k2-20020a170906970200b008775b8a5a5fsm7956074ejx.198.2023.01.31.00.18.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Jan 2023 00:18:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Levend Sayar Mime-Version: 1.0 (1.0) Subject: Re: Google Virtual NIC (GVE) PMD Date: Tue, 31 Jan 2023 11:17:59 +0300 Message-Id: <9B795DFE-EE56-4F51-9896-8DEFDB63E85B@gmail.com> References: Cc: Ferruh Yigit , dev@dpdk.org, Jeroen de Borst , Rushil Gupta , Jordan Kimbrough In-Reply-To: To: "Guo, Junfeng" X-Mailer: iPhone Mail (20D47) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Thanks for the reply Junfeng. I will check the document you mentioned. I don't know the command 'cksum set ip hw 0', but it looks like to me as "ha= rdware will NOT do checksum'. There is a gateway between VMs at GCP as you mentioned. My test application g= enerates UDP packets. I am checking the offloading capacity of the NIC and behaving accordingly. S= ince GVE says IP checksum capability, I am offloading that. My packets have 0 as an IP checksum. In this case, I can not see any packet a= t the destination with tcpdump. Since I do not have a chance to see what is happening at the gateway, I only= check packet transmission at the destination VM. If I calculate IP checksums by myself, I see the packets at the destination.= So according to my observations, the gateway does not do such an IP checksu= m correction. My second observation is GVE does UDP checksum if you offload. Normally I am= not using a checksum at UDP and use zero as the checksum. Best, Levend Telefonumdan g=C3=B6nderildi > Guo, Junfeng =C5=9Funlar=C4=B1 yazd=C4=B1 (31 Oca 2= 023 09:52): >=20 > =EF=BB=BF >=20 >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Wednesday, January 18, 2023 23:32 >> To: Levend Sayar ; Guo, Junfeng >> >> Cc: dev@dpdk.org; Jeroen de Borst ; Rushil >> Gupta ; Jordan Kimbrough >> Subject: Re: Google Virtual NIC (GVE) PMD >>=20 >>> On 1/18/2023 1:47 PM, Levend Sayar wrote: >>> Hi all. >>>=20 >>> PMD for Google Virtual NIC says it is capable of IPV4 TX checksum >>> offloading. >>>=20 >>>=20 >> https://github.com/DPDK/dpdk/blob/main/drivers/net/gve/gve_ethdev.c >> #L285 >>>=20 >> > c#L285> >>>=20 >>> But according to my tests on Google Cloud, it is not doing that ipv4 >>> checksum tx offload. >>> I only managed to send a packet via DPDK if I calculate the checksum >> myself. >>>=20 >>> Do you have any idea about that? >=20 > Thanks for the feedback! >=20 > I tried to use this loopback typo in csum fwd mode based on this doc: > "https://doc.dpdk.org/dts/test_plans/checksum_offload_test_plan.html" > During the dpdk ports forwarding, the received pkts at tester side can hav= e > correct csum after setting with 'csum set ip hw 0'. >=20 > Also, on GCP, the gateway between VMs will correct the wrong L3 chksum > values by default when passing the pkts. >=20 > Could you please provide more details for your test cases?=20 > So that we can have more information to verify this. Thanks! >=20 >=20 >>>=20 >>=20 >> cc'ed gve maintainers. >=20 > Thanks Ferruh for the forwarding! >=20