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 EB97EA00C3; Wed, 8 Jun 2022 10:14:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DDEA140689; Wed, 8 Jun 2022 10:14:34 +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 1F1C04069C for ; Wed, 8 Jun 2022 10:14:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654676072; 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=ZAjEgwiyOxG3o/mWkpGngXtnLEbsx2y4UNKP4KYSCANuzpZdDpV0KGnWyJJIXpxeyYhZA8 7joZh2cz+bqUQH1MhWrt/a0XDC/6DhdyO+2cyXNjixLQwHJ90Vw9bK8qLOQ4OFpcPUs0ga QMjSVBcmQnivUjEkmMN2b17n/+gRqzM= 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: 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 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 >