From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDF1DC433B4 for ; Fri, 14 May 2021 05:49:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C56576117A for ; Fri, 14 May 2021 05:49:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231479AbhENFuR (ORCPT ); Fri, 14 May 2021 01:50:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230109AbhENFuQ (ORCPT ); Fri, 14 May 2021 01:50:16 -0400 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80D4BC06174A for ; Thu, 13 May 2021 22:49:05 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id d25-20020a0568300459b02902f886f7dd43so12170953otc.6 for ; Thu, 13 May 2021 22:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bE06xAXCXCRjHxZIVvCKZFVX3we62E4nDMf17dk25ts=; b=N1aj48wfBA8fNXog/TNxwKCt1hOpvt3nk6RJEDP4coWUX2s7+9OH6R3QaLITJoxTrE Zzn+EXzYJhzRVDLXDunJXDPWRAQOP7W0GEDCsedZbqtO5C8ePdg5FixKLFwOhXriy6VH 0f/WGx3ISGrBqNorGa4/HjdG7FK6YohsZNy6G4jAB4l4uz+izg3LXc2SkhVwDmV+GEyP auhpYNKA4q4C2ZCYunWce4JTb6nEDPr5I00fsv+hvFpsdf9jKvsVG8IsDByybgV9u4Rg 4i6eHzJJ/52mWwaB9g+oMNmDR8u/HM6RUnuhbWWsKM3J5FXGw7XOdMVskvjFiYXhYysj ordg== 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=bE06xAXCXCRjHxZIVvCKZFVX3we62E4nDMf17dk25ts=; b=quFndevLFOHaPFGMISwBBz1s/+k+TvApfK9Enhm8DPe1QDqgvD8j5bpVKpNsqvHlLW XW8R1oQYARawHGqQHkm5S8UjCN75JYtB5eAYIWL9ny+yrIIr+vR/dMJ2k8/NZi0wY2AR ZmgByMoHdzmhHsnS0E1edMHtxGiCpJPCY8yXf6qV3NkaQ1nzyx7yc8xNMZkgL2/6BC2P gEfECsWsZEa49F7uHGclXOgNeoiP05RqFNSrrrOrQarWfZu86psZ90e6c8ZHAzZQEbW3 mEcGA5dMvN4Vb2B8Y3NPmLqDPym/gZXX75sdvz92EC3roFeU7eIc5jjcUrc99utik1LB ZB0w== X-Gm-Message-State: AOAM533wCoAn8h0aLb/ZwXVVZFVQ3kt7zaUrEtRkGqkWd/OoSTeCp1ZJ 3dZCepQCT4DXWBalFqnWcVCw0KfaM01puud+2geoiQ== X-Google-Smtp-Source: ABdhPJw6ecjfX4cA6xRIgJtvrTL3DdNwOpNQUZA+OEyZgZIY3AZNDInnxNRJJQlEAM6xDNSsTsXPqu5Gd6ve8wDX7eM= X-Received: by 2002:a9d:8ce:: with SMTP id 72mr39720820otf.220.1620971344860; Thu, 13 May 2021 22:49:04 -0700 (PDT) MIME-Version: 1.0 References: <20210511044253.469034-1-yuri.benditovich@daynix.com> <20210511044253.469034-5-yuri.benditovich@daynix.com> <89759261-3a72-df6c-7a81-b7a48abfad44@redhat.com> In-Reply-To: From: Yuri Benditovich Date: Fri, 14 May 2021 08:48:52 +0300 Message-ID: Subject: Re: [PATCH 4/4] tun: indicate support for USO feature To: Willem de Bruijn Cc: Jason Wang , Yan Vugenfirer , davem , Jakub Kicinski , mst , netdev , linux-kernel , virtualization Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 13, 2021 at 11:43 PM Willem de Bruijn wrote: > > > > > > > So the question is what to do now: > > > > > > A) > > > > > > Finalize patches for guest TX and respective QEMU patches > > > > > > Prepare RFC patches for guest RX, get ack on them > > > > > > Change the spec > > > > > > Finalize patches for guest RX according to the spec > > > > > > > > > > > > B) > > > > > > Reject the patches for guest TX > > > > > > Prepare RFC patches for everything, get ack on them > > > > > > Change the spec > > > > > > Finalize patches for everything according to the spec > > > > > > > > > > > > I'm for A) of course :) > > > > > > > > > > I'm for B :) > > > > > > > > > > The reasons are: > > > > > > > > > > 1) keep the assumption of tun_set_offload() to simply the logic and > > > > > compatibility > > > > > 2) it's hard or tricky to touch guest TX path only (e.g the > > > > > virtio_net_hdr_from_skb() is called in both RX and TX) > > > > > > > > I suspect there is _some_ misunderstanding here. > > > > I did not touch virtio_net_hdr_from_skb at all. > > > > > > > > > > Typo, actually I meant virtio_net_hdr_to_skb(). > > OK. > > 2) tun_get_user() which is guest TX - this is covered > > 3) tap_get_user() which is guest TX - this is covered > > 4) {t}packet_send() which is userspace TX - this is OK, the userspace > > does not have this feature, it will never use USO > > What do you mean exactly? I can certainly imagine packet socket users > that could benefit from using udp gso. I've just tried to understand whether we have a real functional problem due to the fact that I define the USO feature only for guest TX path. This set of patches modifies virtio_net_hdr_to_skb and Jason's comment was that this procedure is called in both guest TX and RX, there are 4 places where the virtio_net_hdr_to_skb is called, userspace TX is one of them. AFAIU userspace 'socket' and 'user' backends of qemu do not have any offloads at all so they will never use USO also. Sorry for misunderstanding if any. > > When adding support for a new GSO type in virtio_net_hdr, it ideally > is supported by all users of that interface. Alternatively, if some > users do not support the flag, a call that sets the flag has to > (continue to) fail hard, so that we can enable it at a later time. I agree of course. IMO this is what I've tried to do. I did not have in the initial plan to make Linux virtio-net to use the USO at all but this should not present any problem (if I'm not mistaken). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81DE4C433B4 for ; Fri, 14 May 2021 05:49:18 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 06C0561440 for ; Fri, 14 May 2021 05:49:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06C0561440 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B55766064E; Fri, 14 May 2021 05:49:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1Qm14hatLfi; Fri, 14 May 2021 05:49:13 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTP id 4F0B46062A; Fri, 14 May 2021 05:49:13 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24228C000E; Fri, 14 May 2021 05:49:13 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id EE384C0001 for ; Fri, 14 May 2021 05:49:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DC2D36062A for ; Fri, 14 May 2021 05:49:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oKH3OHAfL8Q for ; Fri, 14 May 2021 05:49:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by smtp3.osuosl.org (Postfix) with ESMTPS id 045F660625 for ; Fri, 14 May 2021 05:49:05 +0000 (UTC) Received: by mail-ot1-x333.google.com with SMTP id t4-20020a05683014c4b02902ed26dd7a60so15466022otq.7 for ; Thu, 13 May 2021 22:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bE06xAXCXCRjHxZIVvCKZFVX3we62E4nDMf17dk25ts=; b=N1aj48wfBA8fNXog/TNxwKCt1hOpvt3nk6RJEDP4coWUX2s7+9OH6R3QaLITJoxTrE Zzn+EXzYJhzRVDLXDunJXDPWRAQOP7W0GEDCsedZbqtO5C8ePdg5FixKLFwOhXriy6VH 0f/WGx3ISGrBqNorGa4/HjdG7FK6YohsZNy6G4jAB4l4uz+izg3LXc2SkhVwDmV+GEyP auhpYNKA4q4C2ZCYunWce4JTb6nEDPr5I00fsv+hvFpsdf9jKvsVG8IsDByybgV9u4Rg 4i6eHzJJ/52mWwaB9g+oMNmDR8u/HM6RUnuhbWWsKM3J5FXGw7XOdMVskvjFiYXhYysj ordg== 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=bE06xAXCXCRjHxZIVvCKZFVX3we62E4nDMf17dk25ts=; b=WDvyYJCnTu/isEsdR4EvEIWYwlyQM83uTzOiqpb0EnVG1oMsYIN6lOXL8cEk2zqljs DqfZE2i0WQ+yzdgu/XLIXVcnv9yQdIZbJZmPUPG6gonFij81dYdoH/UTUYslYI/9f/5W U3Xr0hVQp6l4GIP2JKOcK9saWfEQqkpyITC/1l3bKDGZtkbmqD92RqHvAPFvif9rq5ew H9Bwyp1lFiCjhWOxqprgdMXr/A0ICmmMXjkXGMn+CMx6BpdlXxv6RXRp+DCQT3R3DYon A8WalT11qNcXnl2Va2ZxEZ1xFhCLeSRTzC3WuK6b0l8eSXN5YSFrmQ0hGFLrlq2cuf1m x+xQ== X-Gm-Message-State: AOAM530vazRYlj712ctQr5bKCuQO9sfjUjOnQVWG1ICmI2ewPoGnnBe9 rMiQMJnnzNzPqKa5kWUq1LLzqXvQzGYi2Kp6rwzqCw== X-Google-Smtp-Source: ABdhPJw6ecjfX4cA6xRIgJtvrTL3DdNwOpNQUZA+OEyZgZIY3AZNDInnxNRJJQlEAM6xDNSsTsXPqu5Gd6ve8wDX7eM= X-Received: by 2002:a9d:8ce:: with SMTP id 72mr39720820otf.220.1620971344860; Thu, 13 May 2021 22:49:04 -0700 (PDT) MIME-Version: 1.0 References: <20210511044253.469034-1-yuri.benditovich@daynix.com> <20210511044253.469034-5-yuri.benditovich@daynix.com> <89759261-3a72-df6c-7a81-b7a48abfad44@redhat.com> In-Reply-To: From: Yuri Benditovich Date: Fri, 14 May 2021 08:48:52 +0300 Message-ID: Subject: Re: [PATCH 4/4] tun: indicate support for USO feature To: Willem de Bruijn Cc: mst , netdev , linux-kernel , virtualization , Yan Vugenfirer , Jakub Kicinski , davem X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Thu, May 13, 2021 at 11:43 PM Willem de Bruijn wrote: > > > > > > > So the question is what to do now: > > > > > > A) > > > > > > Finalize patches for guest TX and respective QEMU patches > > > > > > Prepare RFC patches for guest RX, get ack on them > > > > > > Change the spec > > > > > > Finalize patches for guest RX according to the spec > > > > > > > > > > > > B) > > > > > > Reject the patches for guest TX > > > > > > Prepare RFC patches for everything, get ack on them > > > > > > Change the spec > > > > > > Finalize patches for everything according to the spec > > > > > > > > > > > > I'm for A) of course :) > > > > > > > > > > I'm for B :) > > > > > > > > > > The reasons are: > > > > > > > > > > 1) keep the assumption of tun_set_offload() to simply the logic and > > > > > compatibility > > > > > 2) it's hard or tricky to touch guest TX path only (e.g the > > > > > virtio_net_hdr_from_skb() is called in both RX and TX) > > > > > > > > I suspect there is _some_ misunderstanding here. > > > > I did not touch virtio_net_hdr_from_skb at all. > > > > > > > > > > Typo, actually I meant virtio_net_hdr_to_skb(). > > OK. > > 2) tun_get_user() which is guest TX - this is covered > > 3) tap_get_user() which is guest TX - this is covered > > 4) {t}packet_send() which is userspace TX - this is OK, the userspace > > does not have this feature, it will never use USO > > What do you mean exactly? I can certainly imagine packet socket users > that could benefit from using udp gso. I've just tried to understand whether we have a real functional problem due to the fact that I define the USO feature only for guest TX path. This set of patches modifies virtio_net_hdr_to_skb and Jason's comment was that this procedure is called in both guest TX and RX, there are 4 places where the virtio_net_hdr_to_skb is called, userspace TX is one of them. AFAIU userspace 'socket' and 'user' backends of qemu do not have any offloads at all so they will never use USO also. Sorry for misunderstanding if any. > > When adding support for a new GSO type in virtio_net_hdr, it ideally > is supported by all users of that interface. Alternatively, if some > users do not support the flag, a call that sets the flag has to > (continue to) fail hard, so that we can enable it at a later time. I agree of course. IMO this is what I've tried to do. I did not have in the initial plan to make Linux virtio-net to use the USO at all but this should not present any problem (if I'm not mistaken). _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization