From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 062D82E424A; Mon, 16 Jun 2025 12:06:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750075564; cv=none; b=tzIe96KNyNUSzP7KYI1z4meYQ4OGwEtTZrhZFIHe1zoPDdJGOR2laQDzcEmChb5bGNX/CPrDNC7tnl2ydiJUXG4rrDF0Ve4OXwpiyZ8cve70aBArlO9ig33AWItLr/eLDNSjL+jZBd5akQLYlnLqm7LAQDRUpcFRfe0fGydqbp8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750075564; c=relaxed/simple; bh=b9WYpdYFnxnMvXA1h3uf/5jste9EtGT+SWQw77HmkHQ=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=Aupcn7drlTaujYfs4UdI/BGDOk49TB6mkAeYUYumxOu19FMEsts3G0V8A9NIvHjNFtgBbi2k1QOEsGV/wBa504Ht6cy5mgNXQMweA8ZaX8JDV9D7jcDctUuh+ZwGSbZb/jrTwf+cFXO6DbebO5Ypx0DzvWi6FIf8DvUfbee5OMA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pq67Wpiy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pq67Wpiy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E4F8C4CEEA; Mon, 16 Jun 2025 12:06:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750075563; bh=b9WYpdYFnxnMvXA1h3uf/5jste9EtGT+SWQw77HmkHQ=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=pq67WpiybJlomxNo1Q0ynrhGsdBlLEZa3DapIvrN62fslXaJvFSseYU1F6UF6iK7m eRjNYnjG4H+HpTv+rDskCAVmxpco7/DZ+LSFuf6wTg0KlYhtOAWE/nAjK43uRVc+mZ jLR2DW/n7KG1ffCW0PtADsj9vMXl1cgYgm39oBRnpvW912H0vgijYY1cE6n2UfvoJo g3MFBCtiYS2xpwe4DQIkU5knmOVB1NsyYKYtmYFn55S1xvicbtUkR+RuAaSfi8PXXz U6Xd+aDPSj5ualUsK7k5hQqGA3nehA79pSkx32khEdCQ/bUQdJ+l6ni7LEO1Sq5oJo rkLvwouWXCydQ== Message-ID: <20415ab5-5003-4725-bf1b-560f197465c4@kernel.org> Date: Mon, 16 Jun 2025 14:05:58 +0200 Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xdp: Remove unused events xdp_redirect_map and xdp_redirect_map_err From: Jesper Dangaard Brouer To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Steven Rostedt , LKML , Linux trace kernel , bpf@vger.kernel.org Cc: Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , "David S. Miller" , Jakub Kicinski , John Fastabend , Andrii Nakryiko References: <20250611155615.0c2cf61c@batman.local.home> <87bjqtb6c1.fsf@toke.dk> <4af27621-6d81-4316-b57a-b546c8a7ad08@kernel.org> Content-Language: en-US In-Reply-To: <4af27621-6d81-4316-b57a-b546c8a7ad08@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/06/2025 12.54, Jesper Dangaard Brouer wrote: > > > On 12/06/2025 12.30, Toke Høiland-Jørgensen wrote: >> Steven Rostedt writes: >> >>> From: Steven Rostedt >>> >>> Each TRACE_EVENT() defined can take up around 5K of text and meta data >>> regardless if they are used or not. New code is being developed that >>> will >>> warn when a tracepoint is defined but not used. >>> >>> The trace events xdp_redirect_map and xdp_redirect_map_err are >>> defined but >>> not used, but there's also a comment that states these are kept >>> around for >>> backward compatibility. Which is interesting because since they are not >>> used, any old BPF program that expects them to exist will get incorrect >>> data (no data) when they use them. It's worse than not working, it's >>> silently failing. >>> >>> Remove them as they will soon cause warnings, or if they really need to >>> stick around, then code needs to be added to use them. >>> >>> Signed-off-by: Steven Rostedt (Google) >> >> I guess that makes sense; I have no objections to getting rid of them. >> >> Reviewed-by: Toke Høiland-Jørgensen > > Make sense. > > > Toke we have to check how XDP-tools handle when these tracepoints > disappears. To Toke, notice that userspace tools expect this tracepoint to be available will fail as below (for kernel release v6.16): $ sudo ./xdp-bench redirect mlx5p1 veth41 libbpf: prog 'tp_xdp_redirect_map_err': failed to find kernel BTF type ID of 'xdp_redirect_map_err': -3 libbpf: prog 'tp_xdp_redirect_map_err': failed to prepare load attributes: -3 libbpf: prog 'tp_xdp_redirect_map_err': failed to load: -3 libbpf: failed to load object 'xdp_redirect_basic' Failed to attach XDP program: No such process IMHO this is a userspace problem, that needs to be more flexible and adapt to this change. This was changed in kernel v5.6 (Jan 2020) commit 1d233886dd90 ("xdp: Use bulking for non-map XDP_REDIRECT and consolidate code paths"). So, I'm thinking that xdp-tools could just remove monitoring for these tracepoints? --Jesper