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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 D1FD1C43603 for ; Wed, 18 Dec 2019 19:50:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FDE72082E for ; Wed, 18 Dec 2019 19:50:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IDZBHq0s" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727474AbfLRTu2 (ORCPT ); Wed, 18 Dec 2019 14:50:28 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:45528 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726698AbfLRTu2 (ORCPT ); Wed, 18 Dec 2019 14:50:28 -0500 Received: by mail-wr1-f65.google.com with SMTP id j42so3566516wrj.12 for ; Wed, 18 Dec 2019 11:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fU0K104stEqCabDcHL05vs2+3PCVuM6D4oC4kCEqvzM=; b=IDZBHq0sbrkjRl3Ip6LOuUMLan/T+gCsJz+nKb1dT9y3wcDLSnC/lnhbD+Y33NqdHm 5sCJHRKoUQBt7uWuWmD6KbgyQsjqrZquMgLJtxFe7K2lXQH5LuiWSaMPgA2QzbapJOhd IiNflHOMMzkRyGbKf1GDxxUxT/hm8Jq5CtF0RKU7x/DRxjUWyoLda6XXwTaVi7OXEJRj PQ25pK8G9D+KyxMXt1eAADTHyfstQ1mhArgm4PuVUNFP55l75chFX5eRtXtBCJlCNMt0 FwwF1xxXifovKz3OWZZTMOA8r3D13jruZQW1YlLKVLyP5nTgSEbpKtI/THdzFANE7ry3 px7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fU0K104stEqCabDcHL05vs2+3PCVuM6D4oC4kCEqvzM=; b=bB3tZh06KDPaBoM1jaQswaZUcl8MoG0WvOmE5qliqcIs5G1Q7o0guBtMCMrRFNjjlq bD5uOkXLHHhSJnnu1JjDaDRbDEBL49pNP7RTtugDfq+nrrFINdjkhKZy79VNhd3eGLIv hZg98GQ0MCirsGCM2YR7aJxUc6BRE5COjdsAkmyPl7p52sSctbytvP6UFK+weplTsYBY zcqNQq1O4qDITaACEiaBrTKCEZySBvr64kIrixSKZtzbPQWBATFUmMKOPHUO2C6PBG7o KVM8ewbqVLo2eSK6wYc+waomDsZ1WKqlxhotGV94QzUD07hn2M/oTm0vc33S2YEybt5R tKGA== X-Gm-Message-State: APjAAAXTGZho28FVJiNgEwJqjRu61b6QmnEm+hCuJkMqbmFXwUnwR+uz d51grharWP2uDdu77lFNfizYa3SC X-Google-Smtp-Source: APXvYqzMiNGqfHsMm30W3scYGZFarIKaEBh/l4Xz8opVV3gCr1d84VGgkDqhSxRXLj2A+W7uTf0+fA== X-Received: by 2002:adf:9c8a:: with SMTP id d10mr4729927wre.156.1576698626274; Wed, 18 Dec 2019 11:50:26 -0800 (PST) Received: from [192.168.8.147] (197.171.185.81.rev.sfr.net. [81.185.171.197]) by smtp.gmail.com with ESMTPSA id c2sm3728917wrp.46.2019.12.18.11.50.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2019 11:50:25 -0800 (PST) Subject: Re: [PATCH net-next v3 07/11] tcp: Prevent coalesce/collapse when skb has MPTCP extensions To: Mat Martineau , netdev@vger.kernel.org, mptcp@lists.01.org References: <20191217203807.12579-1-mathew.j.martineau@linux.intel.com> <20191217203807.12579-8-mathew.j.martineau@linux.intel.com> From: Eric Dumazet Message-ID: <5fc0d4bd-5172-298d-6bbb-00f75c7c0dc9@gmail.com> Date: Wed, 18 Dec 2019 11:50:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191217203807.12579-8-mathew.j.martineau@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 12/17/19 12:38 PM, Mat Martineau wrote: > The MPTCP extension data needs to be preserved as it passes through the > TCP stack. Make sure that these skbs are not appended to others during > coalesce or collapse, so the data remains associated with the payload of > the given skb. > This seems a very pessimistic change to me. Are you planing later to refine this limitation ? Surely if a sender sends TSO packet, we allow all the segments being aggregated at receive side either by GRO or TCP coalescing.