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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 C5683C433DB for ; Wed, 10 Feb 2021 10:59:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88BD864E37 for ; Wed, 10 Feb 2021 10:59:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230417AbhBJK7G (ORCPT ); Wed, 10 Feb 2021 05:59:06 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:28243 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229834AbhBJKzX (ORCPT ); Wed, 10 Feb 2021 05:55:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612954437; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QNdS4uaIcL7T8BO9ZPW9arckpg/ta/zEzSVdZa8TFqs=; b=cdaHsWvAFYW1AEhOhkTHnXN7dHpa9wL3FV6BM6p3r3K84QRuLPk+aE+H42ETIdXF+Ney9t aXQ/q9iRNHUI+PZRzUICpq6be1Gt96GkIGpDCa4I5KEDC2GyGv9i0QSbSEEX3XyeBc5yt1 cjuYsxep85emjhC893L0R972A/foEJc= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-251-qkePynrlMaCNGGn2buYYYA-1; Wed, 10 Feb 2021 05:53:55 -0500 X-MC-Unique: qkePynrlMaCNGGn2buYYYA-1 Received: by mail-ej1-f69.google.com with SMTP id ar1so2313941ejc.22 for ; Wed, 10 Feb 2021 02:53:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=QNdS4uaIcL7T8BO9ZPW9arckpg/ta/zEzSVdZa8TFqs=; b=I6N0+VorPVgOPPZO5bl//ZnGM40MI1N+9cKOoiexqH5qo4zmLrZvnMs6QB4FFidM9H kvm33cXLk2mZLsx34wO0NPuW0qpdld/PHUZUchS9TPUFcRMzBs6AOHOVUcGEYaJJvTmV dhLP0JeZ1N8z+dh4zmoalrgtuUzkTXA2f3W6yHagKSGqeuDZtd8cZ6MJVmn1RL3ioFRB 5CiqcjgS0geGwO7iwXgi2NfKhgJLkLFlxPsmyVnUXFtwzTFZY+Tt4H27EOD1l5jpVaGu BvKzr5xLS0Ro7QqbJ6sfiwMhV91fpbTRHJhVPz7SPvRamVef+a8+MUeoslBfpo9MxBgB 1Zdg== X-Gm-Message-State: AOAM533n5wezv/uUHp+uaMxsyTnbgn3nXjQWxZFbSSA2uFYb0y45cvG/ FoMGkIJF2eLxBuyDetXOJT4jzFsJShrIjxfbh6jo5RTIZ3l/SH1WVxhyostUm+25WvyxgEOAc5a eoOIBmRjNHDHC X-Received: by 2002:a17:906:854f:: with SMTP id h15mr2314413ejy.2.1612954434537; Wed, 10 Feb 2021 02:53:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJy9kxjrkvs0lMRtZKb7eZ5+PmgxP+XOmQ4alp1vZxt2LBpsa3XZxhu0QXOHuBKYBoklVFBcjg== X-Received: by 2002:a17:906:854f:: with SMTP id h15mr2314389ejy.2.1612954434350; Wed, 10 Feb 2021 02:53:54 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id c6sm694540edx.62.2021.02.10.02.53.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 02:53:53 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 7B6561804EE; Wed, 10 Feb 2021 11:53:53 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski , Marek Majtyka Cc: 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 In-Reply-To: <20210203090232.4a259958@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201204102901.109709-1-marekx.majtyka@intel.com> <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> <20210202113456.30cfe21e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210203090232.4a259958@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 10 Feb 2021 11:53:53 +0100 Message-ID: <874kikry66.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: bpf@vger.kernel.org Jakub Kicinski writes: > On Wed, 3 Feb 2021 13:50:59 +0100 Marek Majtyka wrote: >> On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote: >> > On Tue, 02 Feb 2021 13:05:34 +0100 Toke H=C3=B8iland-J=C3=B8rgensen wr= ote:=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 sho= uld >> > > get better at not doing that myself :) >> > > >> > > 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 a= s 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 stil= l 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...=20=20 >> > >> > 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 >> > 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).=20=20 >>=20 >> I am a bit confused now. Did you mean validation tests of those XDP >> flags, which I am working on or some other validation tests? >> What should these tests verify? Can you please elaborate more on the >> topic, please - just a few sentences how are you see it? > > Conformance tests can be written for all features, whether they have=20 > an explicit capability in the uAPI or not. But for those that do IMO > the tests should be required. > > Let me give you an example. This set adds a bit that says Intel NICs=20 > can do XDP_TX and XDP_REDIRECT, yet we both know of the Tx queue > shenanigans. So can i40e do XDP_REDIRECT or can it not? > > If we have exhaustive conformance tests we can confidently answer that > question. And the answer may not be "yes" or "no", it may actually be > "we need more options because many implementations fall in between". > > I think readable (IOW not written in some insane DSL) tests can also=20 > be useful for users who want to check which features their program / > deployment will require. While I do agree that that kind of conformance test would be great, I don't think it has to hold up this series (the perfect being the enemy of the good, and all that). We have a real problem today that userspace can't tell if a given driver implements, say, XDP_REDIRECT, and so people try to use it and spend days wondering which black hole their packets disappear into. And for things like container migration we need to be able to predict whether a given host supports a feature *before* we start the migration and try to use it. I view the feature flags as a list of features *implemented* by the driver. Which should be pretty static in a given kernel, but may be different than the features currently *enabled* on a given system (due to, e.g., the TX queue stuff). The simple way to expose the latter would be to just have a second set of flags indicating the current configured state; and for that I guess we should at least agree what "enabled" means; and a conformance test would be a way to do this, of course. I don't see why we can't do this in stages, though; start with the first set of flags ('implemented'), move on to the second one ('enabled'), and then to things like making the kernel react to the flags by rejecting insertion into devmaps for invalid interfaces... -Toke From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?= Date: Wed, 10 Feb 2021 11:53:53 +0100 Subject: [Intel-wired-lan] [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set In-Reply-To: <20210203090232.4a259958@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201204102901.109709-1-marekx.majtyka@intel.com> <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> <20210202113456.30cfe21e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210203090232.4a259958@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Message-ID: <874kikry66.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: Jakub Kicinski writes: > On Wed, 3 Feb 2021 13:50:59 +0100 Marek Majtyka wrote: >> On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote: >> > On Tue, 02 Feb 2021 13:05:34 +0100 Toke H?iland-J?rgensen wrote: >> > > 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 :) >> > > >> > > 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 >> > 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). >> >> I am a bit confused now. Did you mean validation tests of those XDP >> flags, which I am working on or some other validation tests? >> What should these tests verify? Can you please elaborate more on the >> topic, please - just a few sentences how are you see it? > > Conformance tests can be written for all features, whether they have > an explicit capability in the uAPI or not. But for those that do IMO > the tests should be required. > > Let me give you an example. This set adds a bit that says Intel NICs > can do XDP_TX and XDP_REDIRECT, yet we both know of the Tx queue > shenanigans. So can i40e do XDP_REDIRECT or can it not? > > If we have exhaustive conformance tests we can confidently answer that > question. And the answer may not be "yes" or "no", it may actually be > "we need more options because many implementations fall in between". > > I think readable (IOW not written in some insane DSL) tests can also > be useful for users who want to check which features their program / > deployment will require. While I do agree that that kind of conformance test would be great, I don't think it has to hold up this series (the perfect being the enemy of the good, and all that). We have a real problem today that userspace can't tell if a given driver implements, say, XDP_REDIRECT, and so people try to use it and spend days wondering which black hole their packets disappear into. And for things like container migration we need to be able to predict whether a given host supports a feature *before* we start the migration and try to use it. I view the feature flags as a list of features *implemented* by the driver. Which should be pretty static in a given kernel, but may be different than the features currently *enabled* on a given system (due to, e.g., the TX queue stuff). The simple way to expose the latter would be to just have a second set of flags indicating the current configured state; and for that I guess we should at least agree what "enabled" means; and a conformance test would be a way to do this, of course. I don't see why we can't do this in stages, though; start with the first set of flags ('implemented'), move on to the second one ('enabled'), and then to things like making the kernel react to the flags by rejecting insertion into devmaps for invalid interfaces... -Toke