From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1428279AbdDXPIy (ORCPT ); Mon, 24 Apr 2017 11:08:54 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:49808 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1171891AbdDXPIr (ORCPT ); Mon, 24 Apr 2017 11:08:47 -0400 Date: Mon, 24 Apr 2017 11:08:44 -0400 (EDT) Message-Id: <20170424.110844.1321374394090353753.davem@davemloft.net> To: jslaby@suse.cz Cc: alexei.starovoitov@gmail.com, mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, jpoimboe@redhat.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, daniel@iogearbox.net, edumazet@google.com Subject: Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC From: David Miller In-Reply-To: References: <697947f4-0a2c-1480-0995-9919556dc020@suse.cz> <20170424.104132.950580313142367896.davem@davemloft.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 24 Apr 2017 07:27:23 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jiri Slaby Date: Mon, 24 Apr 2017 16:52:43 +0200 > On 04/24/2017, 04:41 PM, David Miller wrote: >>> It cannot stay as-is simply because we want to know where the functions >>> end to inject debuginfo properly. The code above does not warrant for >>> any exception. >> >> I totally and completely disagree. > > You can disagree as you wish but there is really nothing special on the > bpf code with respect to annotations. > >>> Executing a nop takes a little and having externally-callable functions >>> aligned can actually help performance (no, I haven't measured nor tested >>> the code). But sure, the tool is generic, so I can introduce a local >>> macros to avoid alignments in the functions: >> >> Not for this case, it's a bunch of entry points all packed together >> intentionally so that SKB accesses of different access sizes (which is >> almost always the case) from BPF programs use the smallest amount of >> I-cache as possible. > > And for that reason I suggested the special macros for the code (see the > macros in the e-mail you replied to again). So what problem do you > actually have with the suggested solution? If you align the entry points, then the code sequence as a whole is are no longer densely packed. Or do I misunderstand how your macros work?