From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH net-next] virtio_net: force_napi_tx module param. Date: Wed, 25 Jul 2018 01:46:38 +0300 Message-ID: <20180725014410-mutt-send-email-mst@kernel.org> References: <20180723231119.142904-1-caleb.raitto@gmail.com> <20180724134138-mutt-send-email-mst@kernel.org> <20180724212238-mutt-send-email-mst@kernel.org> <20180725012205-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: caleb.raitto@gmail.com, Jason Wang , David Miller , Network Development , Caleb Raitto To: Willem de Bruijn Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58130 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388479AbeGXXzV (ORCPT ); Tue, 24 Jul 2018 19:55:21 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jul 24, 2018 at 06:31:54PM -0400, Willem de Bruijn wrote: > On Tue, Jul 24, 2018 at 6:23 PM Michael S. Tsirkin wrote: > > > > On Tue, Jul 24, 2018 at 04:52:53PM -0400, Willem de Bruijn wrote: > > > >From the above linked patch, I understand that there are yet > > > other special cases in production, such as a hard cap on #tx queues to > > > 32 regardless of number of vcpus. > > > > I don't think upstream kernels have this limit - we can > > now use vmalloc for higher number of queues. > > Yes. that patch* mentioned it as a google compute engine imposed > limit. It is exactly such cloud provider imposed rules that I'm > concerned about working around in upstream drivers. > > * for reference, I mean https://patchwork.ozlabs.org/patch/725249/ Yea. Why does GCE do it btw? -- MST