From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mail.toke.dk (Postfix) with ESMTPS id A56259F6CD8 for ; Tue, 21 Mar 2023 13:24:59 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=YExc8EAT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679401497; 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: in-reply-to:in-reply-to:references:references; bh=ZEM2O5AZZfhh/tv2fFyNWLmvspB6ddGG/uJLc6m+gqo=; b=YExc8EATnouPIjllzeUSYifwBr4jkyt8wJnvNLIafkRiwBBp9M2DPyIMm2tuASUShRhvx1 mLj1SlTXrky7x6UEjkzaEoVh2RCgfvNtrdNEUcT3CFXeLDTYVLe9RrXKbTEq1e4CDN4Wkw zwUvs8kfflaHKlJakF3fP1GhxSNRPZ0= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-gfIt5sWVPgWkXH19uyJGwA-1; Tue, 21 Mar 2023 08:24:56 -0400 X-MC-Unique: gfIt5sWVPgWkXH19uyJGwA-1 Received: by mail-ed1-f72.google.com with SMTP id k30-20020a50ce5e000000b00500544ebfb1so12166256edj.7 for ; Tue, 21 Mar 2023 05:24:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679401495; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZEM2O5AZZfhh/tv2fFyNWLmvspB6ddGG/uJLc6m+gqo=; b=tQ9NZcz650feDn3Sg3B5aTtIKUzIo++FBtija487DBryZ03TNai3DWKz2Ewr6fhod0 4FEx13l6TE3+PkD5phJv+GnCm7KQFP8HgKsebGy8shdvuxOHr9Ly47tJO9fOEp0I09rR 7ICbZrKpYY3Yo25FUb/bf99jASD3bPCDhLeu/N2mpaWRsfVCUWA3Ps5x64XJSFG4VohX W2xuBI0+IidYqvcCRepd++6XTUiaA2Q1Su45LDqsGBx3YQEhla1ap1WpJ99CNPrDLD8U WvIjBXbNFebUglMD+B/jrXm1CXldox/BBfY2iDuqq2IVeOtRx9E7ZsgpTG8Ic3gxGOzG 9YEg== X-Gm-Message-State: AO0yUKV+fRTwHnaZZW2ie7W5ooixM/dmmTCQV0LdYjyWjswONyIrjDrV 4kAu/G5nzNa+IcTxId8wj399LjcMjnqyOvTvgXQcaE7yh4uCjp0qjLq2dsmRVFyOrTEBhL8SiSa bLIbJlkC7AkYNDGUGzgfa X-Received: by 2002:a17:906:22d4:b0:931:a0cb:1ef1 with SMTP id q20-20020a17090622d400b00931a0cb1ef1mr2582549eja.7.1679401495090; Tue, 21 Mar 2023 05:24:55 -0700 (PDT) X-Google-Smtp-Source: AK7set827uIV36c4Q1wXEiOLcV0/nXL1g/9nodarT2GYrZjfT+RM2GjdaYDd2zEWkCpVLiPEKr/xMQ== X-Received: by 2002:a17:906:22d4:b0:931:a0cb:1ef1 with SMTP id q20-20020a17090622d400b00931a0cb1ef1mr2582528eja.7.1679401494725; Tue, 21 Mar 2023 05:24:54 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id u24-20020a17090657d800b00934823127c8sm2567103ejr.78.2023.03.21.05.24.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Mar 2023 05:24:54 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 58FFD9E3449; Tue, 21 Mar 2023 13:24:53 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jesper Dangaard Brouer , Stanislav Fomichev In-Reply-To: References: <167906343576.2706833.17489167761084071890.stgit@firesoul> <167906359575.2706833.545256364239637451.stgit@firesoul> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 21 Mar 2023 13:24:53 +0100 Message-ID: <87bkkm8f6y.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: Q47U2EMWLH43TJR4YKQ4PN2STQDZQDJW X-Message-ID-Hash: Q47U2EMWLH43TJR4YKQ4PN2STQDZQDJW X-MailFrom: toke@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: brouer@redhat.com, bpf@vger.kernel.org, netdev@vger.kernel.org, martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net, alexandr.lobakin@intel.com, larysa.zaremba@intel.com, xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com, yoong.siang.song@intel.com, boon.leong.ong@intel.com X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next V1 1/7] xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver support List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Jesper Dangaard Brouer writes: > On 17/03/2023 22.21, Stanislav Fomichev wrote: >> On 03/17, Jesper Dangaard Brouer wrote: >>> When driver doesn't implement a bpf_xdp_metadata kfunc the fallback >>> implementation returns EOPNOTSUPP, which indicate device driver doesn't >>> implement this kfunc. >> >>> Currently many drivers also return EOPNOTSUPP when the hint isn't >>> available, which is inconsistent from an API point of view. Instead >>> change drivers to return ENODATA in these cases. >> >>> There can be natural cases why a driver doesn't provide any hardware >>> info for a specific hint, even on a frame to frame basis (e.g. PTP). >>> Lets keep these cases as separate return codes. >> >>> When describing the return values, adjust the function kernel-doc layout >>> to get proper rendering for the return values. >> >>> Signed-off-by: Jesper Dangaard Brouer >> >> I don't remember whether the previous discussion ended in something? >> IIRC Martin was preferring to use xdp-features for this instead? >> > > IIRC Martin asked for a second vote/opinion to settle the vote. > The xdp-features use is orthogonal and this patch does not prohibit the > later implementation of xdp-features, to detect if driver doesn't > implement kfuncs via using global vars. Not applying this patch leaves > the API in an strange inconsistent state, because of an argument that in > the *future* we can use xdp-features to solve *one* of the discussed > use-cases for another return code. > I argued for a practical PTP use-case where not all frames contain the > PTP timestamp. This patch solve this use-case *now*, so I don't see why > we should stall solving this, because of a "future" feature we might > never get around to implement, which require the user to use global vars. > > >> Personally I'm fine with having this convention, but I'm not sure how well >> we'll be able to enforce them. (In general, I'm not a fan of userspace >> changing it's behavior based on errno. If it's mostly for >> debugging/development - seems ok) >> > > We enforce the API by documenting the return behavior, like below. If a > driver violate this, then we will fix the driver code with a fixes tag. > > My ask is simply let not have ambiguous return codes. FWIW I don't get the opposition to this patch: having distinct return codes strictly increases the amount of information that is available to the caller. Even if some driver happens to use the "wrong" return code, it's still an improvement for all the drivers that do the right thing (and, well, we can fix broken drivers). And if a BPF program doesn't care about the type of failure they can just ignore treat all error codes the same; realistically, that is what most programs will do, but that doesn't mean we can't provide the more-granular error codes to the programs that do care. My only concern with this patch is that it targets bpf-next and carries no Fixes tag, so we'll end up with a kernel release that doesn't have this change... -Toke