Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbdCQCz0 (ORCPT ); Thu, 16 Mar 2017 22:55:26 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:35659 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751801AbdCQCzY (ORCPT ); Thu, 16 Mar 2017 22:55:24 -0400 Message-ID: <1489719322.28631.278.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths From: Eric Dumazet To: Alexander Duyck Cc: Netdev , "linux-kernel@vger.kernel.org" , "Samudrala, Sridhar" , Eric Dumazet , David Miller Date: Thu, 16 Mar 2017 19:55:22 -0700 In-Reply-To: References: <20170316183142.15806.38824.stgit@localhost.localdomain> <20170316183238.15806.14293.stgit@localhost.localdomain> <1489701936.28631.249.camel@edumazet-glaptop3.roam.corp.google.com> <1489704618.28631.267.camel@edumazet-glaptop3.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 652 Lines: 18 On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote: > I don't know. My concern here is about the cost of going through all > that code just for something that we know shouldn't be valid. If > nothing else I might update sk_can_busy_loop so that it doesn't try > busy looping on a sk_napi_id that is NR_CPU or less. But why would that be a win ? if napi_by_id() returns NULL, we immediately give up, (goto out;) So why should we add a code that will add something that will not be useful for the vast majority of the cases where the ID is valid and we need to do the hash look up ? Is libc trying to avoid doing syscalls like close(-1) ?