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 41F57A0524; Tue, 13 Apr 2021 17:27:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B59E0161121; Tue, 13 Apr 2021 17:27:39 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 8EB3016111F for ; Tue, 13 Apr 2021 17:27:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618327657; 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=Lbtd8EJFUuerv3Bbwl7c83G/hY10ax001PYJ2AhJsEI=; b=ihubvJFd40spIGpH34wMCeQEOQpky3nU7uYL0vp2QKnuycx2E/+lS2BQq/2LCTu8D9U35i dm1RovMFuWq8lYAuZ7clsFAZ6GfBx7CzMIUxzkXj+aiPmeYvTae6HAjQAq0DTuATyYazO3 JMVapHftXLKC36qo6WfWgWJZmT72e00= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-572-CCX5DmLSPoyKZxqyomBY1Q-1; Tue, 13 Apr 2021 11:27:36 -0400 X-MC-Unique: CCX5DmLSPoyKZxqyomBY1Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58F7E107ACC7; Tue, 13 Apr 2021 15:27:35 +0000 (UTC) Received: from [10.36.110.28] (unknown [10.36.110.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DAA519726; Tue, 13 Apr 2021 15:27:29 +0000 (UTC) To: Flavio Leitner , David Marchand Cc: dev@dpdk.org, olivier.matz@6wind.com, i.maximets@ovn.org, Chenbo Xia , Jijiang Liu , Yuanhan Liu References: <20210401095243.18211-1-david.marchand@redhat.com> <20210401095243.18211-6-david.marchand@redhat.com> From: Maxime Coquelin Message-ID: <15cf74f2-4ec2-a641-9bdb-8d93a135a216@redhat.com> Date: Tue, 13 Apr 2021 17:27:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 5/5] vhost: fix offload flags in Rx path 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 Sender: "dev" On 4/8/21 8:38 PM, Flavio Leitner wrote: > On Thu, Apr 01, 2021 at 11:52:43AM +0200, David Marchand wrote: >> The vhost library current configures Tx offloading (PKT_TX_*) on any >> packet received from a guest virtio device which asks for some offloading. >> >> This is problematic, as Tx offloading is something that the application >> must ask for: the application needs to configure devices >> to support every used offloads (ip, tcp checksumming, tso..), and the >> various l2/l3/l4 lengths must be set following any processing that >> happened in the application itself. >> >> On the other hand, the received packets are not marked wrt current >> packet l3/l4 checksumming info. >> >> Copy virtio rx processing to fix those offload flags. >> >> The vhost example needs a reworking as it was built with the assumption >> that mbuf TSO configuration is set up by the vhost library. >> This is not done in this patch for now so TSO activation is forcibly >> refused. >> >> Fixes: 859b480d5afd ("vhost: add guest offload setting") > > There is change that before ECN was ignored and now it is invalid. > I think that's the right way to go, but not sure if virtio blocks > the negotiation of that feature. No, I just tested and the feature gets negotiated. Disabling it in Vhost lib should be avoided to avoid breaking live-migration. It might be safer to revert back to older behavior for it, i.e. just ignore the bit. I don't think it is ever set, because otherwise we would have had lots of reports since the Vhost log would be flooded with: VHOST_LOG_DATA(WARNING, "unsupported gso type %u.\n", hdr->gso_type); David, what do you think? > Reviewed-by: Flavio Leitner > > fbl >