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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 8422CC433DB for ; Tue, 12 Jan 2021 09:27:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 37EB122DFB for ; Tue, 12 Jan 2021 09:27:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405854AbhALJ1v (ORCPT ); Tue, 12 Jan 2021 04:27:51 -0500 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:11346 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387783AbhALJ1u (ORCPT ); Tue, 12 Jan 2021 04:27:50 -0500 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Tue, 12 Jan 2021 01:27:10 -0800 Received: from [172.27.12.183] (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Jan 2021 09:27:07 +0000 Subject: Re: [net-next 08/15] net/mlx5e: CT: Preparation for offloading +trk+new ct rules To: Marcelo Ricardo Leitner , Roi Dayan CC: Saeed Mahameed , "David S. Miller" , Jakub Kicinski , , Paul Blakey , Saeed Mahameed References: <20210108053054.660499-1-saeed@kernel.org> <20210108053054.660499-9-saeed@kernel.org> <20210108214812.GB3678@horizon.localdomain> <218258b2-3a86-2d87-dfc6-8b3c1e274b26@nvidia.com> <20210111235116.GA2595@horizon.localdomain> From: Oz Shlomo Message-ID: Date: Tue, 12 Jan 2021 11:27:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210111235116.GA2595@horizon.localdomain> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610443630; bh=m+1jTPunNoBDrWF+1ZU6ibPljI+fSAmAA9rDhmrQazE=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=jkzsCkx79MqozvwIsT6UMIXYlTbyZkndBt2q3v3joEqIubN05B1UwvmZoDS0e/TbP H19+IaugX9hig5Hg5sv6FkZiMtAmg7BaX0hH5nHE1BZyrj93bZjKUkn/Vn1D6FuTaa M/VB/VouwJY2BSLeE3yi+z5juH/9rkYY71hLeScn0ZmWPHRrx88mtiGffErpx2Wf7x yqzcPoNWIKHfGXa990JZsGFqN5JssIXueLtb+eBI4bj6zPSGbCfggpd6zSWciKXq9I UZelBaYtcKuEiAStnAMjGQyhm9Q+FeereP9T5Hq/AuGQ9G5qTvHo62UOVLJoCrZMbF oVmrX4tNwvobA== Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 1/12/2021 1:51 AM, Marcelo Ricardo Leitner wrote: > On Sun, Jan 10, 2021 at 09:52:55AM +0200, Roi Dayan wrote: >> >> >> On 2021-01-10 9:45 AM, Roi Dayan wrote: >>> >>> >>> On 2021-01-08 11:48 PM, Marcelo Ricardo Leitner wrote: >>>> Hi, >>>> >>>> On Thu, Jan 07, 2021 at 09:30:47PM -0800, Saeed Mahameed wrote: >>>>> From: Roi Dayan >>>>> >>>>> Connection tracking associates the connection state per packet. The >>>>> first packet of a connection is assigned with the +trk+new state. The >>>>> connection enters the established state once a packet is seen on the >>>>> other direction. >>>>> >>>>> Currently we offload only the established flows. However, UDP traffic >>>>> using source port entropy (e.g. vxlan, RoCE) will never enter the >>>>> established state. Such protocols do not require stateful processing, >>>>> and therefore could be offloaded. >>>> >>>> If it doesn't require stateful processing, please enlight me on why >>>> conntrack is being used in the first place. What's the use case here? >>>> >>> >>> The use case for example is when we have vxlan traffic but we do >>> conntrack on the inner packet (rules on the physical port) so >>> we never get established but on miss we can still offload as normal >>> vxlan traffic. >>> >> >> my mistake about "inner packet". we do CT on the underlay network, i.e. >> the outer header. >=20 > I miss why the CT match is being used there then. Isn't it a config > issue/waste of resources? What is CT adding to the matches/actions > being done on these flows? >=20 Consider a use case where the network port receives both east-west encapsul= ated traffic and=20 north-south non-encapsulated traffic that requires NAT. One possible configuration is to first apply the CT-NAT action. Established north-south connections will successfully execute the nat actio= n and will set the +est=20 ct state. However, the +new state may apply either for valid east-west traffic (e.g. = vxlan) due to source port=20 entropy, or to insecure north-south traffic that the fw should block. The u= ser may distinguish=20 between the two cases, for example, by matching on the dest udp port. >> >>>>> >>>>> The change in the model is that a miss on the CT table will be forwar= ded >>>>> to a new +trk+new ct table and a miss there will be forwarded to >>>>> the slow >>>>> path table. >>>> >>>> AFAICU this new +trk+new ct table is a wildcard match on sport with >>>> specific dports. Also AFAICU, such entries will not be visible to the >>>> userspace then. Is this right? >>>> >>>> =C2=A0=C2=A0 Marcelo >>>> >>> >>> right. >=20 > Thanks, > Marcelo >=20