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 32356A0546; Fri, 30 Apr 2021 10:39:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A91C34014F; Fri, 30 Apr 2021 10:39:00 +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 7C4614013F for ; Fri, 30 Apr 2021 10:38:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619771938; 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=6FZeaAXPjSIEo9ODEDxOYVhazh9JK74J6kmjKjLGnrI=; b=ZpXE7ROh03PqSUaWj3ZtA5tCdEPNJ7bBa8s7ja7EWKQVvDo4xetrd0F7fVD2OGBMAhS3Wh fupJmofrcrRTnkNq1xI32o4j6h/E8dvMurXwCbQ/oG7vMNt413p5p/mxdtXq3QNpXLBD0/ bMV2RJpF5vmdn2t+90p8sAO2vDvB6nA= 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-202-9XTeooyMPf-sOaPa3nR2vA-1; Fri, 30 Apr 2021 04:38:54 -0400 X-MC-Unique: 9XTeooyMPf-sOaPa3nR2vA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7734A80ED9B; Fri, 30 Apr 2021 08:38:53 +0000 (UTC) Received: from [10.36.110.52] (unknown [10.36.110.52]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 41EF51007637; Fri, 30 Apr 2021 08:38:47 +0000 (UTC) To: David Marchand Cc: dev , Olivier Matz , Flavio Leitner , Ilya Maximets , Chenbo Xia , "Stokes, Ian" References: <20210401095243.18211-1-david.marchand@redhat.com> <20210429080438.15032-1-david.marchand@redhat.com> <20210429080438.15032-5-david.marchand@redhat.com> <7a03c3ac-95bf-ff34-3485-71ec03145a05@redhat.com> <54d907c8-a49a-0ccb-2886-4a27474860c1@redhat.com> From: Maxime Coquelin Message-ID: <26a61979-bc80-704c-2899-84cd1c50a391@redhat.com> Date: Fri, 30 Apr 2021 10:38:45 +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.22 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 v2 4/4] 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" Hi David, On 4/29/21 10:21 PM, David Marchand wrote: > On Thu, Apr 29, 2021 at 3:31 PM Maxime Coquelin > wrote: >> On 4/29/21 3:30 PM, Maxime Coquelin 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 but accepting >>>> VIRTIO_NET_HDR_GSO_ECN and VIRTIO_NET_HDR_GSO_UDP too. >>>> >>>> The vhost example has been updated accordingly: TSO is applied to any >>>> packet marked LRO. >>>> >>>> Fixes: 859b480d5afd ("vhost: add guest offload setting") >> >> As I understand it, this change kind of break the ABI, but it is >> actually fixing a misuse of the mbuf API, so I think we should >> take this patch. > > Indeed, this breaks the v21 ABI. > > But the only usecase I can think of is an application using TSO / > checksum offloads *only* for traffic coming from vhost. > I say *only* for traffic coming from vhost, because to have this > application do TSO / checksum offloaing for traffic coming from a > physical port, it would comply with the mbuf API and set the PKT_TX_* > flags. > > Apart from the example/vhost, I am not sure there is such an > application that only does v2v or v2p but _not_ p2v TSO / checksum > offloading. > (Note: I am unable to use this example... it seems unhappy with the > mlx5 port I use => FPE because this driver does not support vmdq o_O) > > > I see three options: > - fix the vhost library and break the ABI that only works in an > example (this current patch), > - maintain the v21 ABI > * using symbol versioning, this adds no branch, recompiled > application use the new ABI, this can't be backported to 20.11, > * keeping the current behavior by default, but introducing a new > flag that an application would pass to rte_vhost_driver_register(). > This new flag triggers this current patch behavior but it would add an > additional branch per packets bulk in vhost dequeue path. This *could* > be backported to 20.11. The flag option seems to be the best option, as it will not break ABI so applications we don't know about using Vhost offloads won't be impacted and can add support for the behaviour in a smooth way. The hardest part with this solution is to find a proper name for that flag... Thanks, Maxime