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 846709D01B0 for ; Thu, 15 Dec 2022 15:29:33 +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=Ael4A02T DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671114572; 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=F9zk1ydpzyPtO+/nncYucgHPeAfHU3SdhVuHl+hsa5c=; b=Ael4A02T4K9KvZsVsH4VLl4dM7a1+X1OWssIt5hxmOmSrkzqWfnMg3jtBiAcOLciR3BY+f MG7FHu8UGiHWFS3GOwLts+VUlzh3I7FKweF6qIZmO23NDXJTr1OzfqBQhwzJH8iohfGK5M Hq1/rcEAtYpcaylAhdU8vOoCYcDtcUE= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-624-EPx-VSDJNuWKkm8HW8Gwjg-1; Thu, 15 Dec 2022 09:29:28 -0500 X-MC-Unique: EPx-VSDJNuWKkm8HW8Gwjg-1 Received: by mail-ed1-f71.google.com with SMTP id dz11-20020a0564021d4b00b0046cc3f565e5so11813192edb.8 for ; Thu, 15 Dec 2022 06:29:28 -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=F9zk1ydpzyPtO+/nncYucgHPeAfHU3SdhVuHl+hsa5c=; b=pSI9aXotv5cfcDXPM/IaqmHaDvq4Rcad/QzYEAEPdmSvaIkxOnPUNxGUJ8FvHkF7rB rFgGVU4cYG5LVDtSNzclA1EUNbHAhjxh4FxkEJOopG2TLB0v7esTfO0r6z+uoLOZey1d NeRTnq/d35R3fp6+JDTnK0mE5aCG0JkydvDmBiMh+U9ezgPtbrjwq8UQeH+uWI+y4b20 V7tY1NJDBqPgirHEhzZ82hu8ZHUWn48xFSMOKWU8ylNlpJ2cG3ELPY+l8flM/FkZBzxu /sX7zpLazcUBhp7s7aqprEXIWbKUcZYv9hr5WwQiquJHoe6hsA5Xii89GcGB1JiZaAit Ev3Q== X-Gm-Message-State: ANoB5pkwp50Zp1+t4I3wgu2fU9SUj3hhdwL0Z9kJjFqayeGhX5DZeFVA yt+iRiR1JlYhSRsM5aeYgQFwi8QQ8RihJHucw6oPa42EVwYn4/DjRUpZLHPtunAPFOgTgwvkoo9 rA+vEP99qnJvDsK9pygII X-Received: by 2002:a05:6402:1152:b0:467:9046:e2ef with SMTP id g18-20020a056402115200b004679046e2efmr24476815edw.17.1671114567075; Thu, 15 Dec 2022 06:29:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf59tSBcDngjM41CYfl+TarYqzZRUi/+mvPyr9Wha9rbixivAZTpjgcQ5WUIx76Xe4MQLXPDCQ== X-Received: by 2002:a05:6402:1152:b0:467:9046:e2ef with SMTP id g18-20020a056402115200b004679046e2efmr24476765edw.17.1671114566271; Thu, 15 Dec 2022 06:29:26 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id ee48-20020a056402293000b004615f7495e0sm7423125edb.8.2022.12.15.06.29.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 06:29:25 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 2F3C982F7EB; Thu, 15 Dec 2022 15:29:25 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Larysa Zaremba , Stanislav Fomichev In-Reply-To: References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-11-sdf@google.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 15 Dec 2022 15:29:25 +0100 Message-ID: <874jtweo56.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: 255HCWDGH4ILLLRKDEFQRZZWAPBAO2FT X-Message-ID-Hash: 255HCWDGH4ILLLRKDEFQRZZWAPBAO2FT 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: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.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.7 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 10/14] ice: 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: Larysa Zaremba writes: > On Thu, Nov 03, 2022 at 08:25:28PM -0700, Stanislav Fomichev wrote: >> + /* if (r5 == NULL) return; */ >> + BPF_JMP_IMM(BPF_JNE, BPF_REG_5, 0, S16_MAX), > > S16_MAX jump crashes my system and I do not see such jumps used very often > in bpf code found in-tree, setting a fixed jump length worked for me. > Also, I think BPF_JEQ is a correct condition in this case, not BPF_JNE. > > But the main reason for my reply is that I have implemented RX hash hint > for ice both as unrolled bpf code and with BPF_EMIT_CALL [0]. > Both bpf_xdp_metadata_rx_hash() and bpf_xdp_metadata_rx_hash_supported() > are implemented in those 2 ways. > > RX hash is the easiest hint to read, so performance difference > should be more visible than when reading timestapm. > > Counting packets in an rxdrop XDP program on a single queue > gave me the following numbers: > > - unrolled: 41264360 pps > - BPF_EMIT_CALL: 40370651 pps > > So, reading a single hint in an unrolled way instead of calling 2 driver > functions in a row, gives us a 2.2% performance boost. > Surely, the difference will increase, if we read more than a single hint. > Therefore, it would be great to implement at least some simple hints > functions as unrolled. > > [0] https://github.com/walking-machine/linux/tree/ice-kfunc-hints-clean Right, so this corresponds to ~0.5ns function call overhead, which is a bit less than what I was seeing[0], but you're also getting 41 Mpps where I was getting 25, so I assume your hardware is newer :) And yeah, I agree that ideally we really should inline these functions. However, seeing as that may be a ways off[1], I suppose we'll have to live with the function call overhead for now. As long as we're reasonably confident that inlining can be added later without disruptive API breaks I am OK with proceeding without inlining for now, though. That way, inlining will just be a nice performance optimisation once it does land, and who knows, maybe this will provide the impetus for someone to land it sooner rather than later... -Toke [0] https://lore.kernel.org/r/875yellcx6.fsf@toke.dk [1] https://lore.kernel.org/r/CAADnVQ+MyE280Q-7iw2Y-P6qGs4xcDML-tUrXEv_EQTmeESVaQ@mail.gmail.com