From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F44D14885C for ; Tue, 4 Jun 2024 16:32:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717518727; cv=none; b=uWEGIBNNHhL/8WEE7J1PBCl0D+BGQY329FYWiXHD6mCOn0zJoTo+iwstjoPfemQZG/YbO4e6y2ZObP0sJfwcOLwXHcc80LPRvXj7FEmtJaxV+9kQW19sz2BBhZcMhTF79XdD+Hpi17FDbMDEICCst4c8pv8WtO4jRbl+7FpJkeI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717518727; c=relaxed/simple; bh=i4Ogx5/mcBgPe8sS8F8X3tQ7eWEg2sGB2TGn7q/9bMU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DbuOYPvOKqQFTdsQPpR9OC1JZSA5jGvUv/aFG5vUBFkg/16K0D6AGrxSWaeXNxlUwfYwxIqzmoIKQLT9H7tl3Lh0D1URPXgVNGE0sJXDkAH5ooeUVm4mOBt0fpT3BGyJ5lpdnCe8b3P71v7xh3RELdsmTmNlegsDWaFNpMXWZt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=HgXnE0hF; arc=none smtp.client-ip=209.85.222.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="HgXnE0hF" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-794c3ae6db2so351477585a.0 for ; Tue, 04 Jun 2024 09:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1717518723; x=1718123523; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=EYr0Y7RICrMaykessJ15jPU9wen2fALKwAvygZWhRiU=; b=HgXnE0hFGN5LPcj1volHEzaktqS39wRLFKsfdPOjrGSzbcgM8iKqyoaryZ52o2p4vz Nqvfru5A3eCMEsddtspDtceHVmvigeqFj0/Ij/SWd9KTnXD3bn3UyKCelhqIg83GURRF fFg+ZD+ksUXGFmVvcZM3sQHu0HhfE3BnJEeapN441cKgo1NE6skc9DQJuhi8ACyH2mpO g7g7WrO8weGOIJ+4PgW52LK2eVAJR4zyWFW45r8R/V5Y79eksxGmoaNkh+uA5pmk4kNf qJ1+8x1GntZWXPuug9UqtquGS0oy8GcsbydN/4pkBCLAOHYhUNroafSvXiAUP8FEdYJq 2oBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717518723; x=1718123523; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EYr0Y7RICrMaykessJ15jPU9wen2fALKwAvygZWhRiU=; b=kAIQqtWqgAkkDKOjGVr6OmA+Ijzf8u9c1rWKqVUc3eTvdnoa6Q8z5Ni4MxVIaP9E4z Xzx7NvBX+5gO6PUwedN4j+ei8oNOMOMHwuTwNo6ckJ5+cHZuzMMRfwKnIkpbBKbxvefi rleXnXoZZSjuygg9YH2wn2m91tDyKeQy+D0io6LETsy6Bj32tSesiFJkvq7tuUHm8dUM h5MqCnYs1c9ztH5sgRM9tzP0TanlfC0SiSfRCzsY9yhJBHihBtzKsM9SG3DrGCJKXKSh h5023PVUESk7sjQa7LqC+o4F1wT8AYt66+7x93Ve956cKY/kZuPwB6euRUE56AmNlVNv pnDw== X-Forwarded-Encrypted: i=1; AJvYcCXXjcrjc94O2Z+goAXXoAOyU3u6RLDP7RNE+EzqOHOdKSpqwgfmbm+wIhVkN6gWah/TcW5PuTTnK4K2uAFS31XHTW49 X-Gm-Message-State: AOJu0YylLHhdMt9eZ2OsRfQCf2KDMioyopV713nLogV8xu0M7sQTdVNi uGYBkExbLyHrqCBZ4VsXPF56na1qOWgUeoxEMJc94XESAZTZNXter8CdP2lpeuA= X-Google-Smtp-Source: AGHT+IHcNJm5ltpG2mf7+3csAwiL5eKctuS7MAmZ+C2lRHB7rHiUktaBSt3TzVqwSkXLa2Nb4dRvUA== X-Received: by 2002:a05:620a:271a:b0:792:c5c7:e90d with SMTP id af79cd13be357-794f5cc687emr1510000185a.49.1717518722779; Tue, 04 Jun 2024 09:32:02 -0700 (PDT) Received: from ziepe.ca ([128.77.69.89]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7951a7b3314sm48813285a.40.2024.06.04.09.32.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jun 2024 09:32:01 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1sEX4o-002rQm-Kw; Tue, 04 Jun 2024 13:31:58 -0300 Date: Tue, 4 Jun 2024 13:31:58 -0300 From: Jason Gunthorpe To: Steven Rostedt Cc: Paolo Abeni , Mina Almasry , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-arch@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Donald Hunter , Jonathan Corbet , Richard Henderson , Ivan Kokshaysky , Matt Turner , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Andreas Larsson , Jesper Dangaard Brouer , Ilias Apalodimas , Masami Hiramatsu , Mathieu Desnoyers , Arnd Bergmann , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Steffen Klassert , Herbert Xu , David Ahern , Willem de Bruijn , Shuah Khan , Sumit Semwal , Christian =?utf-8?B?S8O2bmln?= , Pavel Begunkov , David Wei , Yunsheng Lin , Shailend Chand , Harshitha Ramamurthy , Shakeel Butt , Jeroen de Borst , Praveen Kaligineedi , Willem de Bruijn , Kaiyuan Zhang Subject: Re: [PATCH net-next v10 05/14] netdev: netdevice devmem allocator Message-ID: <20240604163158.GB21513@ziepe.ca> References: <20240530201616.1316526-1-almasrymina@google.com> <20240530201616.1316526-6-almasrymina@google.com> <20240604121551.07192993@gandalf.local.home> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240604121551.07192993@gandalf.local.home> On Tue, Jun 04, 2024 at 12:15:51PM -0400, Steven Rostedt wrote: > On Tue, 04 Jun 2024 12:13:15 +0200 > Paolo Abeni wrote: > > > On Thu, 2024-05-30 at 20:16 +0000, Mina Almasry wrote: > > > diff --git a/net/core/devmem.c b/net/core/devmem.c > > > index d82f92d7cf9ce..d5fac8edf621d 100644 > > > --- a/net/core/devmem.c > > > +++ b/net/core/devmem.c > > > @@ -32,6 +32,14 @@ static void net_devmem_dmabuf_free_chunk_owner(struct gen_pool *genpool, > > > kfree(owner); > > > } > > > > > > +static inline dma_addr_t net_devmem_get_dma_addr(const struct net_iov *niov) > > > > Minor nit: please no 'inline' keyword in c files. > > I'm curious. Is this a networking rule? I use 'inline' in my C code all the > time. It mostly comes from Documentation/process/coding-style.rst: 15) The inline disease ---------------------- There appears to be a common misperception that gcc has a magic "make me faster" speedup option called ``inline``. While the use of inlines can be appropriate (for example as a means of replacing macros, see Chapter 12), it very often is not. Abundant use of the inline keyword leads to a much bigger kernel, which in turn slows the system as a whole down, due to a bigger icache footprint for the CPU and simply because there is less memory available for the pagecache. Just think about it; a pagecache miss causes a disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles that can go into these 5 milliseconds. A reasonable rule of thumb is to not put inline at functions that have more than 3 lines of code in them. An exception to this rule are the cases where a parameter is known to be a compiletime constant, and as a result of this constantness you *know* the compiler will be able to optimize most of your function away at compile time. For a good example of this later case, see the kmalloc() inline function. Often people argue that adding inline to functions that are static and used only once is always a win since there is no space tradeoff. While this is technically correct, gcc is capable of inlining these automatically without help, and the maintenance issue of removing the inline when a second user appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway. Jason