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.2 required=3.0 tests=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 216C6C4360C for ; Thu, 26 Sep 2019 13:09:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F059F222C2 for ; Thu, 26 Sep 2019 13:09:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726764AbfIZNJU (ORCPT ); Thu, 26 Sep 2019 09:09:20 -0400 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:55912 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726633AbfIZNJT (ORCPT ); Thu, 26 Sep 2019 09:09:19 -0400 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id A03CC10006E; Thu, 26 Sep 2019 13:09:17 +0000 (UTC) Received: from [10.17.20.203] (10.17.20.203) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 26 Sep 2019 06:09:12 -0700 Subject: Re: CONFIG_NET_TC_SKB_EXT To: Paul Blakey , Jakub Kicinski CC: Pravin Shelar , Daniel Borkmann , Vlad Buslov , David Miller , "netdev@vger.kernel.org" , Jiri Pirko , Cong Wang , Jamal Hadi Salim , Simon Horman , Or Gerlitz References: <1569153104-17875-1-git-send-email-paulb@mellanox.com> <20190922144715.37f71fbf@cakuba.netronome.com> <68c6668c-f316-2ceb-31b0-8197d22990ae@mellanox.com> <4f99e2b6-0f09-9d2c-6300-dfc884d501a8@mellanox.com> <3c09871f-a367-56ca-0d25-f0699a7b79d0@solarflare.com> <541fde6d-01ce-edf3-84e4-153756aba00f@mellanox.com> From: Edward Cree Message-ID: <08f58572-26ed-e947-5b0c-73732ef7eb35@solarflare.com> Date: Thu, 26 Sep 2019 14:09:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <541fde6d-01ce-edf3-84e4-153756aba00f@mellanox.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.203] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24934.005 X-TM-AS-Result: No-3.266000-4.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1jmLzc6AOD8DfHkpkyUphL9IiTd2l7lf6EW6M2A15L1QIi6 yFTH7VfQssXNVaazvgK0+AmH3RJfFxLmJd2F/yFupqbreSinCdP2hUAowGKipwS4ecLQ371kAUq wO9pSIT3pJqptUa8m8FeXIe0wAGNURXNf1eTQ0pviHyvyXeXh5pbfXHbtT1BiabJxhiIFjJkWd4 rBwTzCYVSJctOIDSePm5pMGphf0ZXT1VVKbhb4L1xWWs3RUcVrg995jv1FbzMqAZlo5C3Li2ajM +Kk6cVqvpXyASBuZYSC5hlnEK02ZTXfM+vmulo5Iwk7p1qp3JYZSo6PM4LsihERaA/AH4sBLN7Y /j9rSN/gjmbI74RE4uNlgvH35nu1v1l2Uvx6idoPXo4gvwUD3Up0ODI8GjvXKrauXd3MZDV+ULr uOUpvPtEF4FuLhcGnoa6lCpSUq7tLI8vsziJZizIBT6ZW9CLp8pgGQs1Es89m+fwXMrUlSK36Xy PGjmB4YRb7LQzIelBKvg/6pXRnywbEQIfFpkwHBtlgFh29qnpKzBwu5JpklloKRXQm7FH3 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.266000-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24934.005 X-MDID: 1569503359-D1GYN67-OWWT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 26/09/2019 08:30, Paul Blakey wrote: > Ok, I thought you meant merging the rules because we do want to support > those modifications use-cases. I think the point is that your use-case is sufficiently weird and  obscure that code in the core to support it needs to be unintrusive;  and this clearly wasn't (you managed to piss off Linus...) so it  should be reverted, and held off until a more palatable solution can  be produced.  I agree with Alexei on this. Neither currently-supported-by-drivers cases nor the first step that's  likely to be added (the simple conntrack with modifications only at  the end) needs this, it's for capabilities that are farther in the  future, so there's really no need for it to be in the tree when it's  not ready, which appears to be the case at present. > In nat scenarios the packet will be modified, and then there can be a miss: > >            -trk .... CT(zone X, Restore NAT),goto chain 1 > >            +trk+est, match on ipv4, CT(zone Y), goto chain 2 > >            +trk+est, output.. I'm confused, I thought the usual nat scenario looked more like     0: -trk ... action ct(zone x), goto chain 1     1: +trk+new ... action ct(commit, nat=foo) # sw only     1: +trk+est ... action ct(nat), mirred eth1 i.e. the NAT only happens after conntrack has matched (and thus provided  the saved NAT metadata), at the end of the pipe.  I don't see how you  can NAT a -trk packet. > Also, there are stats issues if we already accounted for some actions in > hardware. AFAICT only 'deliverish' actions (i.e. mirred and drop) in TC have stats. So stats are unlikely to be a problem unless you've got (say) a mirred  mirror before you send to ct and goto chain, in which case the extra  copy of the packet is a rather bigger problem for idempotency than mere  stats ;-)