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 06D9BC4332F for ; Thu, 17 Nov 2022 20:17:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239613AbiKQURX (ORCPT ); Thu, 17 Nov 2022 15:17:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234510AbiKQURV (ORCPT ); Thu, 17 Nov 2022 15:17:21 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0EC727EBEF; Thu, 17 Nov 2022 12:17:21 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id n21so7903285ejb.9; Thu, 17 Nov 2022 12:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=55YgtW2dMJrW7AwFItwqgAI16CPRs4yKm+bUdhCtkUQ=; b=nCp04v7sWKLKn615/jPd8VEMBxuFVEWvTogyYWLkiSNBFp05G2vvuKELsYtP8x1v1O g1zzw43ziLoWLElgZkQ4NSGFaIbjRfIN53astbdHu0L5uIEvqVZ2wYqZ9nxwv0qRnPr1 9CuMjwEMj5zhfO2sDxTDulWKMXPKvzRXjNh6eGU3RaoaFybwGT468W3gA6sn1KjEP/2M mnoF7YmNxaJyrJfFup+QNMn8cw+CAdOyMP+zyDHekLqD+ZXK9bowlZMRyFNBIUlBWu7N 5hXGfXbcNC9DNUrJFhWmfhHsbf5EI2v1S5CmJ/P2gA/wn+pESMJBs5F6jXUYQorRwa7m uqLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=55YgtW2dMJrW7AwFItwqgAI16CPRs4yKm+bUdhCtkUQ=; b=mJVcXvy59PAMbgfZcIWtSPwDdVu3SgQW+DspjPOrTMprm2j4qEsCZ/Nr6lzM+jMybO ypag7Mh8cwmbUwzrut/zwmMrAFQ6LrMI71cy7QR+rUcKuKVZ+x5VA3GQfn8AFSTBLsMU L+AOdkPE/uC7Q+8CCa5p/bhI04R1jC0LFAw3CbEq+lKkcbqLW38xn4vNpxaBeem/z9V/ E8sAPMlHrH/P59CNHOazr5iAEYLsRYAxdn2GrOJs6w5jl9swRDlJh97AbdeU9/Hs2ACV hNAQna5xtj9vV8E17G/r2RvZjudS5rL+27fIeqy0iJmIpqq4D/1uRKrefefBTuoRKNzi eUOA== X-Gm-Message-State: ANoB5pnTqjUBvsUZ0VsFnIhHW2x13ZKGyGwRq38xam/I4JThP4qeNXvL US319bjOy4DHLb5jc+7SxLlKGY0lP3izAZOsV+7QrQoG X-Google-Smtp-Source: AA0mqf7DcM9g4bmq4StqwLg72HjwbQzsNljXj78/PgIZDmdK47iiwkm0j+r1NBwLrOXB/fG2UEqHhGGXdVBH3bITGQ4= X-Received: by 2002:a17:906:1495:b0:7ad:d250:b904 with SMTP id x21-20020a170906149500b007add250b904mr3464534ejc.633.1668716239384; Thu, 17 Nov 2022 12:17:19 -0800 (PST) MIME-Version: 1.0 References: <20221115030210.3159213-1-sdf@google.com> <20221115030210.3159213-6-sdf@google.com> <87h6z0i449.fsf@toke.dk> <8735ajet05.fsf@toke.dk> <6374854883b22_5d64b208e3@john.notmuch> <34f89a95-a79e-751c-fdd2-93889420bf96@linux.dev> <878rkbjjnp.fsf@toke.dk> <6375340a6c284_66f16208aa@john.notmuch> <637576962dada_8cd03208b0@john.notmuch> <6375dad15f11f_9c882208b5@john.notmuch> <63768feaf1324_4101208cf@john.notmuch> In-Reply-To: <63768feaf1324_4101208cf@john.notmuch> From: Alexei Starovoitov Date: Thu, 17 Nov 2022 12:17:07 -0800 Message-ID: Subject: Re: [xdp-hints] Re: [PATCH bpf-next 05/11] veth: Support rx timestamp metadata for xdp To: John Fastabend Cc: Stanislav Fomichev , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Martin KaFai Lau , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, Network Development Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Nov 17, 2022 at 11:47 AM John Fastabend wrote: > > Yeah for timestamps I think a kfunc to either get the timestamp or could > also be done with a kfunc to read hw clock. But either way seems hard > to do that in BPF code directly so kfunc feels right to me here. > > By the way I think if you have the completion queue (rx descriptor) in > the xdp_buff and we use Yonghong's patch to cast the ctx as a BTF type > then we should be able to also directly read all the fields. I see > you noted this in the response to Alexei so lets see what he thinks. Fine with me. Let's land something that is not uapi and then iterate on top.