From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by mail.toke.dk (Postfix) with ESMTPS id 805389C33E1 for ; Fri, 18 Nov 2022 01:03:08 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=QmL2QNUk Received: by mail-ed1-x535.google.com with SMTP id s5so4876864edc.12 for ; Thu, 17 Nov 2022 16:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CC+7vBXHGdFVqaUi/5ScLBYfTiVfdcPIJ8NhD12IG5g=; b=QmL2QNUk8kIxg7DMWGsCbWdosmwbUPz6SinIwC3OQm3U82iJfzqBJIU1cKXdakmjth jJAHdiIH3Zhmq/DIbOSJlRuVGxjMjWgKFc6rM64SexwSCf0GEQafRNF1Jz47oStxfxg2 X44dxI2Rtqmy672JQY5XJdszrmXI1VXqRGwGDewVYRerLfhMKujlBi/pbkzyBAUhm2r0 VV7n5D0efO4MTudqg79kjA5pVbizZ3yIbCUBrcApHSJJTS8wyoRgiPI+cm27Gg/AZGiC dNgjaedB0/qVC3Dq1tkhke4REbdKS+/9HrNQPLe0DnVecpn+wR/6lYxcVB/b+ApmxzuU DCdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=CC+7vBXHGdFVqaUi/5ScLBYfTiVfdcPIJ8NhD12IG5g=; b=iNOP72We1oMha2AOTXBh/xxbbJeUCuTGSOw159nrkefQHBRabTSfCMEwTiXSV5H26/ YMf6ueadXXImtftXFhpSfjGu53IfG0/pkLF2hHK3n7KJGz9aRoi/oW+SCfICjlcJmS7j 4x8HYE8AVX1PPqe3kH/ZfNibdZ147jPt1Np7xlnpyN9KexDZHBxb6IGah9fnQoEecudB fkleWMQtU1bvfoXB7Z77wVc+8vyGLsWPL0xYnEy8eCMaOsZJzQ2SYDqjOpX4NiFk0ZgB /n90JUXlafXlP2PGhiJEHluIK/yXS7ISPAJFMBpT0ybsNXAzdQUj8gh3bat/Oo3FBPpg 16Ng== X-Gm-Message-State: ANoB5pnHsdYQxcTmWj48BamA7CTHuumv0Zk6AhTNsLEFsmjaguF4DHsb VS8a4pzmP4cNAhNgq3Zc3pcvE3Lnkezg0qMXvYU= X-Google-Smtp-Source: AA0mqf5+LxZoZnW3rPh8xbGePYov+M/+njRFrT0KT6r6c2LbpWRvPv4hlOScP8HWjeef8y10CAQKKKE4UoNrZrGtQ3A= X-Received: by 2002:a05:6402:389:b0:459:2515:b27b with SMTP id o9-20020a056402038900b004592515b27bmr4156991edv.338.1668729786295; Thu, 17 Nov 2022 16:03:06 -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> <87wn7t4y0g.fsf@toke.dk> <874juxywih.fsf@toke.dk> In-Reply-To: <874juxywih.fsf@toke.dk> From: Alexei Starovoitov Date: Thu, 17 Nov 2022 16:02:54 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: L2XZKXUF2DJ6PMD4MC5U4LNQT27CVCW6 X-Message-ID-Hash: L2XZKXUF2DJ6PMD4MC5U4LNQT27CVCW6 X-MailFrom: alexei.starovoitov@gmail.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: Stanislav Fomichev , John Fastabend , 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 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: On Thu, Nov 17, 2022 at 3:46 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > > Ack. I can replace the unrolling with something that just resolves > > "generic" kfuncs to the per-driver implementation maybe? That would at > > least avoid netdev->ndo_kfunc_xxx indirect calls at runtime.. > > As stated above, I think we should keep the unrolling. If we end up with > an actual CALL instruction for every piece of metadata that's going to > suck performance-wise; unrolling is how we keep this fast enough! :) Let's start with pure kfuncs without requiring drivers to provide corresponding bpf asm. If pure kfuncs will indeed turn out to be perf limiting then we'll decide on how to optimize them.