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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D26FBC433E0 for ; Tue, 2 Feb 2021 19:36:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8E20F64E08 for ; Tue, 2 Feb 2021 19:36:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239883AbhBBTgU (ORCPT ); Tue, 2 Feb 2021 14:36:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:51286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239877AbhBBTfj (ORCPT ); Tue, 2 Feb 2021 14:35:39 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A3F3A64E39; Tue, 2 Feb 2021 19:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612294498; bh=WC5Lt7FO1YCCTlx62ZrKm1lIJjAacPhiw1YwF3tHUJ8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HeNWkMoDFzRTV5ILjCtPyxS6/ZeLWABp9ipxmY0mPZ/HqVYwm1x44OnL02CuYAft2 0EGKzulbkp2NFOKpDhRuaVz3N5g0mFFusjnVHWRRe5jnP/9VDWTNDEqdsGJF8FeBL/ CyfzeTZumODueoaPmZ0kNC0qooUOGKGecoYVs8/f1AywzzH4vYqfWuw0hPvPkjE5C/ cW3q5thnzxvZqv3rHYFXaRY0F4oEACAj5kYumtwCT/Q0aIhyMeZ17Xym/ehOtsPNWt yQ2Iuum6N1R/+rvPtqIS+2YNkCFjX7MrOuOxcXwGMsC8LaI8YQT03Fk+yP4S/jYq3J GVb3sSo1u2gEQ== Date: Tue, 2 Feb 2021 11:34:56 -0800 From: Jakub Kicinski To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Cc: Marek Majtyka , Saeed Mahameed , David Ahern , Maciej Fijalkowski , John Fastabend , Jesper Dangaard Brouer , Daniel Borkmann , Maciej Fijalkowski , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Andrii Nakryiko , Jonathan Lemon , Alexei Starovoitov , Network Development , "David S. Miller" , hawk@kernel.org, bpf , intel-wired-lan , "Karlsson, Magnus" , jeffrey.t.kirsher@intel.com Subject: Re: [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set Message-ID: <20210202113456.30cfe21e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <87bld2smi9.fsf@toke.dk> References: <20201204102901.109709-1-marekx.majtyka@intel.com> <878sad933c.fsf@toke.dk> <20201204124618.GA23696@ranger.igk.intel.com> <048bd986-2e05-ee5b-2c03-cd8c473f6636@iogearbox.net> <20201207135433.41172202@carbon> <5fce960682c41_5a96208e4@john-XPS-13-9370.notmuch> <20201207230755.GB27205@ranger.igk.intel.com> <5fd068c75b92d_50ce20814@john-XPS-13-9370.notmuch> <20201209095454.GA36812@ranger.igk.intel.com> <20201209125223.49096d50@carbon> <1e5e044c8382a68a8a547a1892b48fb21d53dbb9.camel@kernel.org> <6f8c23d4ac60525830399754b4891c12943b63ac.camel@kernel.org> <87h7mvsr0e.fsf@toke.dk> <87bld2smi9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 02 Feb 2021 13:05:34 +0100 Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Marek Majtyka writes: >=20 > > Thanks Toke, > > > > In fact, I was waiting for a single confirmation, disagreement or > > comment. I have it now. As there are no more comments, I am getting > > down to work right away. =20 >=20 > Awesome! And sorry for not replying straight away - I hate it when I > send out something myself and receive no replies, so I suppose I should > get better at not doing that myself :) >=20 > As for the inclusion of the XDP_BASE / XDP_LIMITED_BASE sets (which I > just realised I didn't reply to), I am fine with defining XDP_BASE as a > shortcut for TX/ABORTED/PASS/DROP, but think we should skip > XDP_LIMITED_BASE and instead require all new drivers to implement the > full XDP_BASE set straight away. As long as we're talking about > features *implemented* by the driver, at least; i.e., it should still be > possible to *deactivate* XDP_TX if you don't want to use the HW > resources, but I don't think there's much benefit from defining the > LIMITED_BASE set as a shortcut for this mode... I still have mixed feelings about these flags. The first step IMO should be adding validation tests. I bet^W pray every vendor has validation tests but since they are not unified we don't know what level of interoperability we're achieving in practice. That doesn't matter for trivial feature like base actions, but we'll inevitably=20 move on to defining more advanced capabilities and the question of "what supporting X actually mean" will come up (3 years later, when we don't remember ourselves).