From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=5x4E=SU=vger.kernel.org=netdev-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 38ADDC10F0E
	for <netdev@archiver.kernel.org>; Thu, 18 Apr 2019 22:40:17 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 09ABC2087F
	for <netdev@archiver.kernel.org>; Thu, 18 Apr 2019 22:40:17 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1725917AbfDRWkP (ORCPT <rfc822;netdev@archiver.kernel.org>);
        Thu, 18 Apr 2019 18:40:15 -0400
Received: from mga17.intel.com ([192.55.52.151]:39946 "EHLO mga17.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725824AbfDRWkP (ORCPT <rfc822;netdev@vger.kernel.org>);
        Thu, 18 Apr 2019 18:40:15 -0400
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
  by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2019 15:40:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,367,1549958400"; 
   d="scan'208";a="338795480"
Received: from ellie.jf.intel.com (HELO ellie) ([10.54.70.67])
  by fmsmga006.fm.intel.com with ESMTP; 18 Apr 2019 15:40:15 -0700
From:   Vinicius Costa Gomes <vinicius.gomes@intel.com>
To:     Alexander Duyck <alexander.duyck@gmail.com>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
        intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
        Netdev <netdev@vger.kernel.org>,
        Bhagath Singh Karunakaran <bhagath@kalycito.com>
Subject: Re: [Intel-wired-lan] [next-queue PATCH v1] igb: Fix limiting the number of queues to number of cpus
In-Reply-To: <CAKgT0Ud1WkN9OT4ftwzry8Wf2Qwr3h=SwVrsRc9zu_BEg3w0_w@mail.gmail.com>
References: <20190404215632.9881-1-vinicius.gomes@intel.com> <461c66428b411644e78ad5a9a44c47442c9b6edf.camel@intel.com> <87d0ljhw09.fsf@intel.com> <CAKgT0Ud1WkN9OT4ftwzry8Wf2Qwr3h=SwVrsRc9zu_BEg3w0_w@mail.gmail.com>
Date:   Thu, 18 Apr 2019 15:40:15 -0700
Message-ID: <878sw7hr8w.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: netdev-owner@vger.kernel.org
Precedence: bulk
List-ID: <netdev.vger.kernel.org>
X-Mailing-List: netdev@vger.kernel.org

Hi Alex,

Alexander Duyck <alexander.duyck@gmail.com> writes:

> On Thu, Apr 18, 2019 at 1:57 PM Vinicius Costa Gomes
> <vinicius.gomes@intel.com> wrote:
>>
>> Hi Jeff,
>>
>> Jeff Kirsher <jeffrey.t.kirsher@intel.com> writes:
>>
>> > I will discuss the issue with my fellow developers and hopefully we can
>> > come up with a kernel interface that all drivers can use to handle this
>> > issue.
>>
>> Did you have the chance to discuss this issue?
>>
>>
>> Cheers,
>> --
>> Vinicius
>
> Is there any reason why you couldn't just use the "ethtool -L" command
> to change the number of queues after creating the interface instead of
> having to use a module parameter? Just wondering since that would be a
> way to change the number of queues, and it should support values
> greater than the number of CPUs if I am not mistaken.

No reason at all. Just not being able to remember about that ethtool
parameter. It indeed works even when the number of CPUs are less than
the number of HW queues. Thanks a lot.


Cheers,
--
Vinicius