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 BFCE5A00C3 for ; Wed, 8 Jun 2022 10:14:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B632A4021D; Wed, 8 Jun 2022 10:14:32 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 1CC6B4021D for ; Wed, 8 Jun 2022 10:14:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654676070; 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=BskHzUalK0eXjgzucfv3vTW/fVovrSY7Nict1R7aX8k=; b=Xh0MCiIx5NuYQNOED3/dEfn8pTYjyxjquKBwoEM15Suh6MJDmyYc/Jn7/jL4vm3ywcOMVj Ym1OHpy3QHaRL3N6MuXRYaE+zqeOkFxi0G4d3KJV4OkLXSJfd9rVGIAVK6V7aHNRS2S3j5 rveFr6w/J2uUZXMzmVmP1PZC/UouuEQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-596-yfI4r5RyNCCyQT3f6nzD5w-1; Wed, 08 Jun 2022 04:14:29 -0400 X-MC-Unique: yfI4r5RyNCCyQT3f6nzD5w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 45865811E83; Wed, 8 Jun 2022 08:14:29 +0000 (UTC) Received: from [10.39.208.20] (unknown [10.39.208.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2A6F18EA0; Wed, 8 Jun 2022 08:14:27 +0000 (UTC) Message-ID: Date: Wed, 8 Jun 2022 10:14:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 6/6] net/vhost: perform SW checksum in Tx path To: "Ma, WenwuX" , "dev@dpdk.org" , "jasowang@redhat.com" , "Xia, Chenbo" , "david.marchand@redhat.com" , "Matz, Olivier" Cc: "stable@dpdk.org" References: <20220505102729.821075-1-maxime.coquelin@redhat.com> <20220505102729.821075-7-maxime.coquelin@redhat.com> <4948f8e2-5fc9-2821-4120-3fdb4111ddd3@redhat.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hi Wenwu, On 6/6/22 11:44, Ma, WenwuX wrote: > > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: 2022年6月2日 17:07 >> To: Ma, WenwuX ; dev@dpdk.org; >> jasowang@redhat.com; Xia, Chenbo ; >> david.marchand@redhat.com; Matz, Olivier >> Cc: stable@dpdk.org >> Subject: Re: [PATCH 6/6] net/vhost: perform SW checksum in Tx path >> >> Hi Wenwu, >> >> Sorry, I missed your review. >> >> On 5/7/22 05:20, Ma, WenwuX wrote: >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin >>>> Sent: 2022年5月5日 18:27 >>>> To: dev@dpdk.org; jasowang@redhat.com; Xia, Chenbo >>>> ; david.marchand@redhat.com; >>>> olivier.matz@6wind.com >>>> Cc: stable@dpdk.org; Maxime Coquelin >>>> Subject: [PATCH 6/6] net/vhost: perform SW checksum in Tx path >>>> >>>> Virtio specification supports guest checksum offloading for L4, which >>>> is enabled with VIRTIO_NET_F_GUEST_CSUM feature negotiation. >> However, >>>> the Vhost PMD does not advertise Tx checksum offload capabilities. >>>> >>>> Advertising these offload capabilities at the ethdev level is not >>>> enough, because we could still end-up with the application enabling >>>> these offloads while the guest not negotiating it. >>>> >>>> This patch advertizes the Tx checksum offload capabilities, and >>>> introduces a compatibility layer to cover the case >>>> VIRTIO_NET_F_GUEST_CSUM has not been negotiated but the >> application >>>> does configure the Tx checksum offloads. This function performs the L4 Tx >> checksum in SW for UDP and TCP. >>>> Compared to Rx SW checksum, the Tx SW checksum function needs to >>>> compute the pseudo-header checksum, as we cannot knwo whether it >> was >>>> done before. >>>> >>>> This patch does not advertize SCTP checksum offloading capability for >>>> now, but it could be handled later if the need arises. >>> >>> In virtio_enqueue_offload(), if RTE_MBUF_F_TX_IP_CKSUM is set, we will >>> performs the L3 Tx checksum, why do not we advertise IPV4 checksum >> offloading capability? >>> Will we advertise it later? >>> >> >> Indeed, we have an IPv4 SW checksum fallback in Vhost library. >> We could think about adding the capability, but that's not urgent I think. Do >> you have a use-case where it is needed? >> > The GRO/GSO library doesn't re-calculate IPv4 checksums for merged/fragmented packets, it will cause iperf in the vm to fail. Can you please elaborate? If we don't expose the IPv4 checksum availability, it would be done by the application using the Vhost PMD, so the result will be the same from the VM point of view. Am I missing something? Thanks, Maxime >> Regards, >> Maxime >