Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756405AbdCWWnh (ORCPT ); Thu, 23 Mar 2017 18:43:37 -0400 Received: from mail.kernel.org ([198.145.29.136]:48476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756317AbdCWWnf (ORCPT ); Thu, 23 Mar 2017 18:43:35 -0400 MIME-Version: 1.0 In-Reply-To: <20170323213802.12615.58216.stgit@localhost.localdomain> References: <20170323211820.12615.88907.stgit@localhost.localdomain> <20170323213802.12615.58216.stgit@localhost.localdomain> From: Andy Lutomirski Date: Thu, 23 Mar 2017 15:43:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID To: Alexander Duyck Cc: Network Development , "linux-kernel@vger.kernel.org" , sridhar.samudrala@intel.com, Eric Dumazet , "David S. Miller" , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1573 Lines: 35 On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck wrote: > From: Sridhar Samudrala > > This socket option returns the NAPI ID associated with the queue on which > the last frame is received. This information can be used by the apps to > split the incoming flows among the threads based on the Rx queue on which > they are received. > > If the NAPI ID actually represents a sender_cpu then the value is ignored > and 0 is returned. This may be more of a naming / documentation issue than a functionality issue, but to me this reads as: "This socket option returns an internal implementation detail that, if you are sufficiently clueful about the current performance heuristics used by the Linux networking stack, just might give you a hint as to which epoll set to put the socket in." I've done some digging into Linux networking stuff, but not nearly enough to have the slighest clue what you're supposed to do with the NAPI ID. It would be nice to make this a bit more concrete and a bit less tied in Linux innards. Perhaps a socket option could instead return a hint saying "for best results, put this socket in an epoll set that's on cpu N"? After all, you're unlikely to do anything productive with busy polling at all, even on a totally different kernel implementation, if you have more than one epoll set per CPU. I can see cases where you could plausibly poll with fewer than one set per CPU, I suppose. Again, though, from the description, it's totally unclear what a user is supposed to do. --Andy