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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 3B094C433E0 for ; Wed, 13 Jan 2021 18:39:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E9AFE20771 for ; Wed, 13 Jan 2021 18:39:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728356AbhAMSi5 (ORCPT ); Wed, 13 Jan 2021 13:38:57 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:30482 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728305AbhAMSi5 (ORCPT ); Wed, 13 Jan 2021 13:38:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610563050; 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=JYLa2cOxqmc+CvxuI8h3Yk6+SIJRgLOEwT+NkOwhWow=; b=MgASPrcigAmzVflg+S9+jyGkd5+teMwkpBJGvSK094mMZpA5nTr/3zvTPkHaPv4SVzehgY l3kq6UM3UMqZ9HQ+U/34uE+rgRS+j1G7caXjSdo6YfvbKrFmayeguLvFIOveTdipQFl0ik uRU9DOz/LEG1LQ1/QT6Gt1MiWbdfbB4= 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-362-rBzvAVxYO7q4tdJY0Df7tw-1; Wed, 13 Jan 2021 13:37:27 -0500 X-MC-Unique: rBzvAVxYO7q4tdJY0Df7tw-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 EF673180E460; Wed, 13 Jan 2021 18:37:23 +0000 (UTC) Received: from ovpn-115-228.ams2.redhat.com (ovpn-115-228.ams2.redhat.com [10.36.115.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 01AA319C47; Wed, 13 Jan 2021 18:37:19 +0000 (UTC) Message-ID: <532f2d63cc7b842f6d75a22da277c2a841dcb40e.camel@redhat.com> Subject: Re: [PATCH v2 net-next] udp: allow forwarding of plain (non-fraglisted) UDP GRO packets From: Paolo Abeni To: Alexander Lobakin , "David S. Miller" , Jakub Kicinski Cc: Alexander Duyck , Eric Dumazet , Edward Cree , Willem de Bruijn , Steffen Klassert , Dongseok Yi , Alexey Kuznetsov , Hideaki YOSHIFUJI , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 13 Jan 2021 19:37:18 +0100 In-Reply-To: <20210113103232.4761-1-alobakin@pm.me> References: <20210113103232.4761-1-alobakin@pm.me> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2021-01-13 at 10:32 +0000, Alexander Lobakin wrote: > Commit 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") actually > not only added a support for fraglisted UDP GRO, but also tweaked > some logics the way that non-fraglisted UDP GRO started to work for > forwarding too. > Commit 2e4ef10f5850 ("net: add GSO UDP L4 and GSO fraglists to the > list of software-backed types") added GSO UDP L4 to the list of > software GSO to allow virtual netdevs to forward them as is up to > the real drivers. > > Tests showed that currently forwarding and NATing of plain UDP GRO > packets are performed fully correctly, regardless if the target > netdevice has a support for hardware/driver GSO UDP L4 or not. > Add the last element and allow to form plain UDP GRO packets if > there is no socket -> we are on forwarding path. If I read correctly, the above will make UDP GRO in the forwarding path always enabled (admin can't disable that, if forwarding is enabled). UDP GRO can introduce measurable latency for UDP packets staging in the napi GRO hash (no push flag for UDP ;). Currently the admin (for fraglist) or the application (for socket-based "plain" GRO) have to explicitly enable the feature, but this change will impact every user. I think we need at lest an explict switch for this. Cheers, Paolo