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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10D8CC636D3 for ; Thu, 9 Feb 2023 00:52:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229841AbjBIAwm (ORCPT ); Wed, 8 Feb 2023 19:52:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229737AbjBIAwm (ORCPT ); Wed, 8 Feb 2023 19:52:42 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06E1712061; Wed, 8 Feb 2023 16:52:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8EB7FB81FE3; Thu, 9 Feb 2023 00:52:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB9CEC433EF; Thu, 9 Feb 2023 00:52:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675903956; bh=qQfNa8Ga6wjwcMS3AVNUxkLw48SuvlRiozdFyCSUCKU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RjTxCHy0JUqLTOeaDv8MCZyoy0qe+LiOXlBIWYbU8YnLrHP6rbrxYwq4ZWbjMeDmV KMvrV9mJgOuXqfhsJZaFneGmeVs8X4EHrQ9g6v8XSUc5ejQgiDDfsKTVUNhU1KgK7w cWXW6EIO9NMccFp+Lx7Rz/m/sPp9nY6A+fgXuOebcmjvf2gf4PDMgc2Y0fvd7daKuK VmfVuY/kLOpVltspwjSONB+eF2knOHJEM5UWGjuZrnl0pUcLi/4abLCTBn5uHKNWSY /E8ayenI37KlKVoFmPox0icivVrDNk6heSwPPYLNvaRw0dMIk4lMIu9EcsYr+RLYj1 7yd0Y1XBpC6SQ== Date: Wed, 8 Feb 2023 16:52:34 -0800 From: Jakub Kicinski To: Saeed Mahameed Cc: Jason Gunthorpe , Leon Romanovsky , "David S. Miller" , Paolo Abeni , Eric Dumazet , Saeed Mahameed , linux-rdma@vger.kernel.org, netdev@vger.kernel.org Subject: Re: pull-request: mlx5-next 2023-01-24 V2 Message-ID: <20230208165234.3002ff25@kernel.org> In-Reply-To: References: <20230203131456.42c14edc@kernel.org> <20230203174531.5e3d9446@kernel.org> <20230206163841.0c653ced@kernel.org> <20230207140330.0bbb92c3@kernel.org> <20230208151922.3d2d790d@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 8 Feb 2023 16:36:18 -0800 Saeed Mahameed wrote: >>> I honestly have no idea why you are so fixated on TC, or what it has >>> to do with RDMA. >> >> It's a strong justification for having full xfrm offload. >> You can't forward without full offload. > > This pull has nothing to do with "full" xfrm offload, > For RoCE to exist it has to rely on netdev attributes, such as > IP, vlan, mac, etc .. in this series we do the same for ipsec, > we setup the steering pipeline with the proper attributes for > RoCE to function. I think I already admitted that the exact patches in the PR are of secondary importance. > I don't see it will be reasonable for the rdma user to setup these > attributes twice, once via netdev API and once via rdma APIs, > this will be torture for that user, just because rdma bits are not allowed > in netdev, it's exactly that, some rdma/roce bits purely mlx5_core logic, > and it has to be in mlx5_core due to the sharing of hardware resources > between rdma and netdev. That's very understandable because for you as the upstream maintainer of mlx5 either side of the equation (netdev or rdma) are "your users". Whether we need to be concerned about their comfort is much less obvious to netdev maintainers.