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 A9A6BA0524; Thu, 29 Apr 2021 22:21:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 28122410DD; Thu, 29 Apr 2021 22:21:26 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id E0441410D7 for ; Thu, 29 Apr 2021 22:21:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619727684; 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: in-reply-to:in-reply-to:references:references; bh=UU6EBARORquhiF9drADUjcVTpzr3bFVUrmVyzelQujs=; b=Ee2J+PtFD8mqY8kWK8JYAhVS3kcYv3gG6K7mOuVDtpywxWYifEvDjQbqOZ23u1uqWBCuYb LKkqjwxU3kdnqKOOaf+hC0CG2aQXJBKSFiSgb7P3AQ+Z0BDHselfRXPlMmZul3VUwexmv/ lYjMUaC4vvDkTDcTIFzExD6tGg++7Ok= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-517-f1R5352rN8q2XWqCBmucbw-1; Thu, 29 Apr 2021 16:21:18 -0400 X-MC-Unique: f1R5352rN8q2XWqCBmucbw-1 Received: by mail-vs1-f71.google.com with SMTP id n10-20020a67ac4a0000b0290227113abed7so728268vsh.16 for ; Thu, 29 Apr 2021 13:21:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UU6EBARORquhiF9drADUjcVTpzr3bFVUrmVyzelQujs=; b=pPRB1xKU+fyXIkzamdJ0ClbY7ly7kj6qztgaHSIxwiZnaQsraDYzVxCOK6V4+n04Ys 520397oDpDY6JU0rI7J273mkKrwQDb0NRsHqmUnINQ99C4GkoAafb5nlWLf5lCmgtRrC JkCkmFJWlBA5V5l0u2fAjE+NhcwavFk6UH+PzxXkF+Zl00eboRy4tW9ocpmx2vCQg4wY 9NlMnMa1ZilYd+vR7pxe5e5fXoehqbtv2QFymsPaTb01uWwA0caiZDOJr925Ea+J+Cjt FA1Ry33qrj+NOl8oAeamkKaTVCPdtRGtyBmX17gMivNoxkXDxEqVDGSxRc+O5X0AGIie 24Vw== X-Gm-Message-State: AOAM533gjfjYyLxUys4lYDXsmIi66p9hnqznutREHXGZWH+X+8ROeRUa cqX71wtwdzXpjxzWPR5qnXPBj9FV2kFJBs7qMOI77vHEkvTNkaQF4F/6wB4sHVdKtGMXEVKXAZE 8+allYoCTbUUjhvSvQoM= X-Received: by 2002:a05:6102:127b:: with SMTP id q27mr2528007vsg.27.1619727677645; Thu, 29 Apr 2021 13:21:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnFDvuVSOJ2PdJvfbK01entko9QZd7ST403JeycIhsMKHjCaUVwouFQOQ36VIozZRuDh+Fp9L07GuDbAdUTXU= X-Received: by 2002:a05:6102:127b:: with SMTP id q27mr2528000vsg.27.1619727677480; Thu, 29 Apr 2021 13:21:17 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <54d907c8-a49a-0ccb-2886-4a27474860c1@redhat.com> From: David Marchand Date: Thu, 29 Apr 2021 22:21:06 +0200 Message-ID: To: Maxime Coquelin Cc: dev , Olivier Matz , Flavio Leitner , Ilya Maximets , Chenbo Xia , "Stokes, Ian" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" 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. -- David Marchand