Thread (33 messages) 33 messages, 7 authors, 2018-09-10

Re: [PATCH net-next] virtio_net: force_napi_tx module param.

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2018-07-24 23:55:21

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 [off-list ref] wrote:
quoted
On Tue, Jul 24, 2018 at 04:52:53PM -0400, Willem de Bruijn wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help