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 38F549C30A0 for ; Thu, 17 Nov 2022 11:27:12 +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=JozlNmOw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668680831; 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=xlbf4XMXjAAtZtTfrsNX3coW79/AxwrRMideQvPGziY=; b=JozlNmOwuwJFuRaX7eKWEKmePZ5YheCWUd0+vQoUo979DEvNeYrHObEz0tNQOfT1YWtSp0 L0f7j9M9KF7Iz21cGNW4xrJOmBsGf+dyxngsG/S6KSifWaNs8jwBSlGxWOrg/0/xHrr1Kr R0tcF3RaCcIfUGUr23Al+xAr7S+6Pv4= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-422-Dbwvi2aIOQ-bG-FD68kGVA-1; Thu, 17 Nov 2022 05:27:05 -0500 X-MC-Unique: Dbwvi2aIOQ-bG-FD68kGVA-1 Received: by mail-ej1-f71.google.com with SMTP id dn14-20020a17090794ce00b007ae5d040ca8so863736ejc.17 for ; Thu, 17 Nov 2022 02:27:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=xlbf4XMXjAAtZtTfrsNX3coW79/AxwrRMideQvPGziY=; b=129whK5ZY/+HuAiufQq/dnfWp5UfH/PgH8PhUI+7tNMVibzb8Ojvya3KH3Svgg5vGs /5NQy+tYR0UFZhRqP9Jl/yh4V029uXv4iX0rGTB0T2SJ2GkSnnoxbQtDAQtADoTMFN6x hom4r1vr6Pz/AVpuNeChzczkTAVftMtJ1yKkukz4+5c3PB6tgRboGG3waH+pCIAai32U OZ/O3Q371Le1joSklJsKLWYASC4LoRxN6suxZbhgqrqgnSFR5WdZum374Swpbxw1hlBa GpxEGOwb9HECIn3zEKKbIQgZLtzj2kMw5HF5B0c4tuDBt2XLbI0FXbQJpTfr1X65LJa1 6OtA== X-Gm-Message-State: ANoB5pkBICyykp+Ulc091TRS71W2RNpMn/g/N/IGVwkgDQ9IYuIjyot0 F5c+enTSG/CP2P4qXxyqg0SOPR9esOXJ7pTG1YGC7suwUCeWb+czLbh77dOU+kgTtDmoSb2ygBm tXcSTujd5jq2lJP60dPAG X-Received: by 2002:a17:906:254f:b0:7ac:d0ae:feba with SMTP id j15-20020a170906254f00b007acd0aefebamr1573826ejb.646.1668680824268; Thu, 17 Nov 2022 02:27:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf7LIpp0Gv2shAYk1X+0qGt/Bbdy+J07gPYzUVDRuy1tpjEPTaB+4v//C8khZ3yBq2rJTWDoAw== X-Received: by 2002:a17:906:254f:b0:7ac:d0ae:feba with SMTP id j15-20020a170906254f00b007acd0aefebamr1573792ejb.646.1668680823936; Thu, 17 Nov 2022 02:27:03 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id d23-20020a056402001700b00461aca1c7b6sm351336edu.6.2022.11.17.02.27.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 02:27:03 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id D11907A6F2C; Thu, 17 Nov 2022 11:27:01 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: John Fastabend , Stanislav Fomichev , John Fastabend In-Reply-To: <637576962dada_8cd03208b0@john.notmuch> 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 17 Nov 2022 11:27:01 +0100 Message-ID: <87zgcp511m.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: XNMV4XZJS7A372TM64WRQ3XCRWRX5ERM X-Message-ID-Hash: XNMV4XZJS7A372TM64WRQ3XCRWRX5ERM 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: Martin KaFai Lau , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, song@kernel.org, yhs@fb.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next 05/11] veth: Support rx timestamp metadata for xdp List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Just a separate comment on this bit: John Fastabend writes: > If you go with in-kernel BPF kfunc approach (vs user space side) I think > you also need to add CO-RE to be friendly for driver developers? Otherwise > they have to keep that read in sync with the descriptors? CO-RE is for doing relocations of field offsets without having to recompile. That's not really relevant for the kernel, that gets recompiled whenever the layout changes. So the field offsets are just kept in sync with offsetof(), like in Stanislav's RFCv2 where he had this snippet: + /* return ((struct sk_buff *)r5)->tstamp; */ + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_5, + offsetof(struct sk_buff, tstamp)), So I definitely don't think this is an argument against the kfunc approach? > Also need to handle versioning of descriptors where depending on > specific options and firmware and chip being enabled the descriptor > might be moving around. This is exactly the kind of thing the driver is supposed to take care of; it knows the hardware configuration and can pick the right descriptor format. Either by just picking an entirely different kfunc unroll depending on the config (if it's static), or by adding the right checks to the unroll. You'd have to replicate all this logic in BPF anyway, and while I'm not doubting *you* are capable of doing this, I don't think we should be forcing every XDP developer to deal with all this. Or to put it another way, a proper hardware abstraction and high-quality drivers is one of the main selling points of XDP over DPDK and other kernel bypass solutions; we should not jettison this when enabling metadata support! -Toke