From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8817B3B29E for ; Thu, 19 Mar 2020 19:12:39 -0400 (EDT) Received: by mail-il1-x12b.google.com with SMTP id h3so3957742ils.3 for ; Thu, 19 Mar 2020 16:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=8tIjZuN9rh2podx7JmtN1DkVaxWhdrC3eUHwKc4qQmQ=; b=ouha6rauwCtJyKZ6FgWUvoXgU8A0VwRhX373hYCtXZSrDfyglq0xTJZuwdLDk65pGs ixVPJafqZwC3ZoB7Nttqaxlkz3rvHtP3KgsRZHLG7hN95Vvmr7Axc77gjViqZwlT0NNL h74r7cw7wrho60QOMFhzZr+VpDNQeVvl+flgp5rPPjNXWGLwJYWyRDtGId6ODWNDuLEd HIqmw5A2knRHqhDb5nxVqxyvKXmUNDF1AI9xgXVmtukHBnd2vOyZVBk2KwV6CuXErtQR AftUCEhTnhsvptM0zY1QeV/JkH3hGqPCHP/EQcGULK6XqeOa15MP1hNwVqUk+SeUpKYM s5BQ== 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:content-transfer-encoding; bh=8tIjZuN9rh2podx7JmtN1DkVaxWhdrC3eUHwKc4qQmQ=; b=COIo9LxhcOWIClBWRa76tjv2siAz8v+3Wbihg2hpCi9AxAS5ZLo0qdoY5UX99rurCL q1OqLfa61oEOd8iCe0cNliTJ6EREX7JbXc8rln16wFceS2N9HUk6pc+1x4fpdvvS6u0N P2aJdrB7NAayuxRo2tIka6g3agdfbnTVJvxvrfPw3K3aU1sjvoMyggcgcfBpMVyE+6Xp 0J5gpyv2OqtGe50GuQ+Od7oXBzTqn3c56smGx5eMWsOAkDjhvF2fDTpbI+daGBqSR3b3 6esG/HD94PF33ffmpAZTyclJGbbHVVnWu2hRxlSRgyA6Hn9GVYnPFCGqY7kOrXGxsra5 BWLQ== X-Gm-Message-State: ANhLgQ1lpxwodw/jfunwZTBCdNZFPyhO3YocuXvdDQJp/b0QfnhfjBaF OaqW1tPfF2ZBsCClNPCDicK4iTLnJjLJPym0gTB++ici X-Google-Smtp-Source: ADFU+vvQTtYOVGYoh4eFoK1lSHkUyXB1d/jdofj62kPrSG+Zi06NI9VXvr78FoWZrV8fBprS0YzReBeY45TKVR/dm+w= X-Received: by 2002:a92:dd0e:: with SMTP id n14mr5931637ilm.0.1584659558837; Thu, 19 Mar 2020 16:12:38 -0700 (PDT) MIME-Version: 1.0 References: <1584524612-24470-1-git-send-email-ilpo.jarvinen@helsinki.fi> <1584524612-24470-10-git-send-email-ilpo.jarvinen@helsinki.fi> <6940af98-7083-15c7-dcea-54eb9d040a3d@gmail.com> In-Reply-To: From: Dave Taht Date: Thu, 19 Mar 2020 16:12:27 -0700 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] Fwd: [RFC PATCH 09/28] gso: AccECN support X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 23:12:39 -0000 ---------- Forwarded message --------- From: Ilpo J=C3=A4rvinen Date: Thu, Mar 19, 2020 at 3:49 PM Subject: Re: [RFC PATCH 09/28] gso: AccECN support To: Eric Dumazet Cc: Netdev , Yuchung Cheng , Neal Cardwell , Olivier Tilmans On Wed, 18 Mar 2020, Eric Dumazet wrote: > On 3/18/20 2:43 AM, Ilpo J=C3=A4rvinen wrote: > > From: Ilpo J=C3=A4rvinen > > > > Handling the CWR flag differs between RFC 3168 ECN and AccECN. > > Take it into account in GSO by not clearing the CWR bit. > > > > Signed-off-by: Ilpo J=C3=A4rvinen > > > > Does it means TCP segmentation offload is disabled on all the NIC > around ? On general level, yes. HW TSO should be disabled with AccECN (or when CWR flag is set for an incoming packet). The reason is how CWR flag is handled by RFC 3168 ECN-aware TSO. It splits the segment such that CWR is cleared starting from the 2nd segment which is incompatible how AccECN handles the CWR flag. With AccECN, CWR flag (or more accurately, the ACE field that also includes ECE & AE flags) changes only when new packet(s) with CE mark arrives so the flag should not be changed within a super-skb. The new feature flag is necessary to prevent such TSO engines happily clearing CWRs (if the CWR handling feature cannot be turned off). If NIC is completely unaware of RFC3168 ECN (doesn't support NETIF_F_TSO_ECN) or its TSO engine can be set to not touch CWR flag despite supporting also NETIF_F_TSO_ECN, TSO could be safely used with AccECN on such NIC. I've little expertise on TSO HW so I don't know if some/what NICs can do it. Nonetheless, there's nothing fundamental preventing TSO being enabled with AccECN by NICs (if either of those conditions is met). In the cases, where TSO would fail to keep its hands off CWR flag, it should fallback to GSO which has always on AccECN support (similar to always on ECN support). I think that the current GSO changes are capable of handling AccECN skbs. For the other parts of the idea above I'm not so sure. There is this NETIF_F_GSO_SOFTWARE with comment that seems to indicate it's doing what I want but I'm not fully sure if adding a flag there is enough to achieve the desired effect? On the rx side, supporting both RFC3168 and AccECN style CWR handling is slightly more complicated (and possibly not worth the effort given CWRs should be relatively rare with RFC3168-style ECN). > Why tun driver is changed and not others ? I think I didn't really understand why tun.c plays with the TSO_ECN flag until now (after finding a related comment from tap.c) and so that change now doesn't make much sense for me now any more. So I'll just remove that part. > I believe you need to give much more details in changelog in general, > because many changes are not that obvious. I'll try to. Thanks. -- i. --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729