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.133.124]) by mail.toke.dk (Postfix) with ESMTPS id BE9509A7E9A for ; Wed, 5 Oct 2022 15:43:48 +0200 (CEST) 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=jUcbz4Gm DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664977427; 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=GsSbujtCTt+IW+d/rBXbBcKeW+BBGKycYoOIn8QFlQI=; b=jUcbz4Gm1vnl8N5JnrH4g1lqpGijg+124lZpGav6nirRWYD1SxlQzHlLMKwoh57J3TyFg+ ibfTWWzmRMhnPCaVql2NuSMTjIIdCBW53joHV/RtVSBFgMLVf+gNqoAbPnTW/z7e5uASad DhykHhk2Ng8admXciQC1MbzJevnA7AM= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-644-s_kdlRFVOKeplMODb17J8w-1; Wed, 05 Oct 2022 09:43:46 -0400 X-MC-Unique: s_kdlRFVOKeplMODb17J8w-1 Received: by mail-ej1-f72.google.com with SMTP id gb42-20020a170907962a00b0078d194624a9so2573573ejc.11 for ; Wed, 05 Oct 2022 06:43:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=GsSbujtCTt+IW+d/rBXbBcKeW+BBGKycYoOIn8QFlQI=; b=afs1hCQ3ogdoWu5ymr/P0ik/t1LWM1/v6iqW6bcE0l7ZIH0pG/YcC2wXQ/zgD1HEFz Ofv3Op8sytuWIxQEfm4aQ1HLcETFgTKM3evGvZuzEYWG2p7bgwAmBfhPzbQx7Ce/fGv+ iCMY75C2VZCWB0pk53kx0oHo9ORCFRlbk9jfXSK5QpCs85gPouQoHwF39wZyJbFzyDC/ NCgjXAjpevh1m7M3UOB3I0S+ql1m+CNvsj6QCxCf1WUFUJXuqtzRghWDq7ZcqU27gSSw ALKHZbJJMmcDxfXSANicEQy2d1ZQvj02bXOjaO1d/Ds7/KI6rvyqO/tf/lQnIYP2YQTf D+2g== X-Gm-Message-State: ACrzQf2cqmRMk1CENiMSq793weFT482d0+JoS0jueJUbSj/6S0Cj1uIL a6T7CpwnUujsQvpj6Pg7y6VvOrEhSQK73j6Ea794F/DiXxbaxChWm3Xm4EnIlB/+CpB8CjYnA4d wFDKMIoGs6NzO9rC7QoxP X-Received: by 2002:a05:6402:3806:b0:450:bad8:8cd5 with SMTP id es6-20020a056402380600b00450bad88cd5mr29071225edb.305.1664977425131; Wed, 05 Oct 2022 06:43:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4tKV4IdZ6t5ipdEbNxxbfP4IIcnxZBulYixB9jOklWI6+RrrOCPSFkdrSDcafwl7LtCwE9+g== X-Received: by 2002:a05:6402:3806:b0:450:bad8:8cd5 with SMTP id es6-20020a056402380600b00450bad88cd5mr29071198edb.305.1664977424819; Wed, 05 Oct 2022 06:43:44 -0700 (PDT) Received: from [192.168.41.81] (83-90-141-187-cable.dk.customer.tdc.net. [83.90.141.187]) by smtp.gmail.com with ESMTPSA id la3-20020a170907780300b00781dbdb292asm8634645ejc.155.2022.10.05.06.43.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 06:43:44 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <404395ad-ad96-d300-a7fe-1116c9fd7b57@redhat.com> Date: Wed, 5 Oct 2022 15:43:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Martin KaFai Lau , Stanislav Fomichev , Jesper Dangaard Brouer References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <35fcfb25-583a-e923-6eee-e8bbcc19db17@redhat.com> <5ccff6fa-0d50-c436-b891-ab797fe7e3c4@linux.dev> In-Reply-To: <5ccff6fa-0d50-c436-b891-ab797fe7e3c4@linux.dev> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 5C44RWUC2OJY4GCQDJQ6JLJTT25BNQC4 X-Message-ID-Hash: 5C44RWUC2OJY4GCQDJQ6JLJTT25BNQC4 X-MailFrom: jbrouer@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, xdp-hints@xdp-project.net, larysa.zaremba@intel.com, memxor@gmail.com, Lorenzo Bianconi , mtahhan@redhat.com, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , dave@dtucker.co.uk, Magnus Karlsson , bjorn@kernel.org X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFCv2 bpf-next 00/18] XDP-hints: XDP gaining access to HW offload hints via BTF List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 05/10/2022 02.25, Martin KaFai Lau wrote: > For rx hwtimestamp, the value could be just 0 if a specific hw/driver > cannot provide it for all packets while some other hw can. Keep in mind that we want to avoid having to write a (64-bit) zero into the metadata for rx_hwtimestamp, for every packet that doesn't carry a timestamp. It essentially reverts back to clearing memory like with SKBs, due to performance overhead we don't want to go that path again! There are multiple ways to avoid having to zero init the memory. In this patchset I have choosen have the traditional approach of flags (u32) approach located in xdp_hints_common, e.g. setting a flag if the field is valid (p.s. John Fastabend convinced me of this approach ;-)). But COMBINED with: some BTF ID layouts doesn't contain some fields e.g. the rx_timestamp, thus the code have no reason to query those flag fields. I am intrigued to find a way to leverage bpf_core_field_exists() some more (as proposed by Stanislav). (As this can allow for dead-code elimination). --Jesper