Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755799AbdCTWGH (ORCPT ); Mon, 20 Mar 2017 18:06:07 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:34114 "EHLO mail-wr0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753522AbdCTWGF (ORCPT ); Mon, 20 Mar 2017 18:06:05 -0400 MIME-Version: 1.0 In-Reply-To: <20170320214854.13922.5086.stgit@localhost.localdomain> References: <20170320214643.13922.51284.stgit@localhost.localdomain> <20170320214854.13922.5086.stgit@localhost.localdomain> From: Eric Dumazet Date: Mon, 20 Mar 2017 15:06:03 -0700 Message-ID: Subject: Re: [net-next PATCH 2/2] tcp: Record Rx hash and NAPI ID in tcp_child_process To: Alexander Duyck Cc: netdev , LKML , sridhar.samudrala@intel.com, David Miller 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: 775 Lines: 17 On Mon, Mar 20, 2017 at 2:48 PM, Alexander Duyck wrote: > From: Alexander Duyck > > While working on some recent busy poll changes we found that child sockets > were being instantiated without NAPI ID being set. In our first attempt to > fix it, it was suggested that we should just pull programming the NAPI ID > into the function itself since all callers will need to have it set. > > In addition to NAPI ID I have decided to also pull in populating the Rx > hash since it likely has the same problem as NAPI ID but just doesn't have > the visibility. It looks like Rx hash was initialized elsewhere ( tcp_get_cookie_sock() & tcp_check_req()) So this probably could be cleaned up, if done at the proper place ;)