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 A6FB4C433E0 for ; Wed, 24 Mar 2021 14:51:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7CAE361A18 for ; Wed, 24 Mar 2021 14:51:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236383AbhCXOvJ (ORCPT ); Wed, 24 Mar 2021 10:51:09 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:31849 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236343AbhCXOvD (ORCPT ); Wed, 24 Mar 2021 10:51:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616597462; 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=qwqc010LQRL9qP/xrAIAyc+UAyyvJ/OsN6lHYuFZfWc=; b=N32mkmEwfqKyGXZDH1SLU//5HVTdBvN4vZx4qwjAI+20Ac/y3e2pNa4ZJFoskCLx0LvO9j jO4inKfMnEllNcWdx0DWIMA6XOtPJ0zJkxiPdISf73kNguA3FwJGK8vOvmEQG2QqtS9wGJ 8v3l+D28gvW3WiiwJ+F7wV2REDMip84= 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-578--Ayr5fs4Oc2_hS6JNCQVIg-1; Wed, 24 Mar 2021 10:51:00 -0400 X-MC-Unique: -Ayr5fs4Oc2_hS6JNCQVIg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8030E87A83A; Wed, 24 Mar 2021 14:50:59 +0000 (UTC) Received: from ovpn-115-125.ams2.redhat.com (ovpn-115-125.ams2.redhat.com [10.36.115.125]) by smtp.corp.redhat.com (Postfix) with ESMTP id BE77A196A8; Wed, 24 Mar 2021 14:50:57 +0000 (UTC) Message-ID: <7974ce16adc27164afa63170483bb4371894c5e1.camel@redhat.com> Subject: ! From: Paolo Abeni To: Willem de Bruijn Cc: Network Development , "David S. Miller" , Jakub Kicinski , Steffen Klassert , Alexander Lobakin Date: Wed, 24 Mar 2021 15:50:56 +0100 In-Reply-To: References: <661b8bc7571c4619226fad9a00ca49352f43de45.1616345643.git.pabeni@redhat.com> 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.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 2021-03-23 at 21:54 -0400, Willem de Bruijn wrote: > > I did not look at that before your suggestion. Thanks for pointing out. > > > > I think the problem is specific to UDP: when processing the outer UDP > > header that is potentially eligible for both NETIF_F_GSO_UDP_L4 and > > gro_receive aggregation and that is the root cause of the problem > > addressed here. > > Can you elaborate on the exact problem? The commit mentions "inner > protocol corruption, as no overaly network parameters is taken in > account at aggregation time." > > My understanding is that these are udp gro aggregated GSO_UDP_L4 > packets forwarded to a udp tunnel device. They are not encapsulated > yet. Which overlay network parameters are not, but should have been, > taken account at aggregation time? The scenario is as follow: * a NIC has NETIF_F_GRO_UDP_FWD or NETIF_F_GRO_FRAGLIST enabled * an UDP tunnel is configured/enabled in the system * the above NIC receives some UDP-tunneled packets, targeting the mentioned tunnel * the packets go through gro_receive and they reache 'udp_gro_receive()' while processing the outer UDP header. without this patch, udp_gro_receive_segment() will kick in and the outer UDP header will be aggregated according to SKB_GSO_FRAGLIST or SKB_GSO_UDP_L4, even if this is really e.g. a vxlan packet. Different vxlan ids will be ignored/aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Please let me know if the above is more clear. Thanks! Paolo