From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <dev@dpdk.org>; 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 <david.marchand@redhat.com>
Date: Thu, 29 Apr 2021 22:21:06 +0200
Message-ID: <CAJFAV8zLft93Btnt2gigXwOJ0N3kX=CuLKvSCtaX9aDWqrjAWA@mail.gmail.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: dev <dev@dpdk.org>, Olivier Matz <olivier.matz@6wind.com>,
Flavio Leitner <fbl@sysclose.org>, Ilya Maximets <i.maximets@ovn.org>,
Chenbo Xia <chenbo.xia@intel.com>, "Stokes, Ian" <ian.stokes@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Thu, Apr 29, 2021 at 3:31 PM Maxime Coquelin
<maxime.coquelin@redhat.com> 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