search for: poll_queu

...but it doesn''t work as expected. Here is what I have with error checking, etc. removed: class RequestQueuePollerWorker < BackgrounDRb::MetaWorker set_worker_name :request_queue_poller_worker QUEUE_SLEEP_TIME = 30 # seconds def create(args = nil) @running = true self.poll_queue end def build_all_matches(args = nil) thread_pool.defer(args) do |args| requests = Request.find_active(:all) requests.each { |request| request.queue! } # using acts_as_state_machine end end protected # Was hoping to get multiple threads processing def build_ma...

...h set is we would be able to enable more queues when there is limited number of vectors. Another use case we may classify queues as hight priority or low priority as mentioned by Cornelia. For virtio-blk, we may extend virtio-blk based on this patch set to enable something similar to write_queues/poll_queues in nvme, when (set->nr_maps != 1). Yet, the question I am asking in this email thread is for a difference scenario. The issue is not we are not having enough vectors (although this is why only 1 vector is allocated for all virtio-blk queues). As so far virtio-blk has (set->nr_maps == 1),...

...h set is we would be able to enable more queues when there is limited number of vectors. Another use case we may classify queues as hight priority or low priority as mentioned by Cornelia. For virtio-blk, we may extend virtio-blk based on this patch set to enable something similar to write_queues/poll_queues in nvme, when (set->nr_maps != 1). Yet, the question I am asking in this email thread is for a difference scenario. The issue is not we are not having enough vectors (although this is why only 1 vector is allocated for all virtio-blk queues). As so far virtio-blk has (set->nr_maps == 1),...

...Please note that this is pci-specific... >>> >>>> >>>> >>>> This is because the max number of queues is not limited by the number of >>>> possible cpus. >>>> >>>> By default, nvme (regardless about write_queues and poll_queues) and >>>> xen-blkfront limit the number of queues with num_possible_cpus(). >>> >>> ...and these are probably pci-specific as well. >> >> Not pci-specific, but per-cpu as well. > > Ah, I meant that those are pci devices. > >> >>...

...Please note that this is pci-specific... >>> >>>> >>>> >>>> This is because the max number of queues is not limited by the number of >>>> possible cpus. >>>> >>>> By default, nvme (regardless about write_queues and poll_queues) and >>>> xen-blkfront limit the number of queues with num_possible_cpus(). >>> >>> ...and these are probably pci-specific as well. >> >> Not pci-specific, but per-cpu as well. > > Ah, I meant that those are pci devices. > >> >>...

...0-req.2 28: 0 0 0 0 PCI-MSI 65540-edge virtio0-req.3 ... ... In above case, there is one msix vector per queue. This is because the max number of queues is not limited by the number of possible cpus. By default, nvme (regardless about write_queues and poll_queues) and xen-blkfront limit the number of queues with num_possible_cpus(). Is this by design on purpose, or can we fix with below? diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 4bc083b..df95ce3 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @...

...0-req.2 28: 0 0 0 0 PCI-MSI 65540-edge virtio0-req.3 ... ... In above case, there is one msix vector per queue. This is because the max number of queues is not limited by the number of possible cpus. By default, nvme (regardless about write_queues and poll_queues) and xen-blkfront limit the number of queues with num_possible_cpus(). Is this by design on purpose, or can we fix with below? diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 4bc083b..df95ce3 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @...

...above case, there is one msix vector per queue. > > Please note that this is pci-specific... > >> >> >> This is because the max number of queues is not limited by the number of >> possible cpus. >> >> By default, nvme (regardless about write_queues and poll_queues) and >> xen-blkfront limit the number of queues with num_possible_cpus(). > > ...and these are probably pci-specific as well. Not pci-specific, but per-cpu as well. > >> >> >> Is this by design on purpose, or can we fix with below? >> >> >> d...

...above case, there is one msix vector per queue. > > Please note that this is pci-specific... > >> >> >> This is because the max number of queues is not limited by the number of >> possible cpus. >> >> By default, nvme (regardless about write_queues and poll_queues) and >> xen-blkfront limit the number of queues with num_possible_cpus(). > > ...and these are probably pci-specific as well. Not pci-specific, but per-cpu as well. > >> >> >> Is this by design on purpose, or can we fix with below? >> >> >> d...

...note that this is pci-specific... >>>> >>>>> >>>>> This is because the max number of queues is not limited by the number of >>>>> possible cpus. >>>>> >>>>> By default, nvme (regardless about write_queues and poll_queues) and >>>>> xen-blkfront limit the number of queues with num_possible_cpus(). >>>> ...and these are probably pci-specific as well. >>> Not pci-specific, but per-cpu as well. >> Ah, I meant that those are pci devices. >> >>>> >>&...

...o0-req.3 > ... ... > > In above case, there is one msix vector per queue. Please note that this is pci-specific... > > > This is because the max number of queues is not limited by the number of > possible cpus. > > By default, nvme (regardless about write_queues and poll_queues) and > xen-blkfront limit the number of queues with num_possible_cpus(). ...and these are probably pci-specific as well. > > > Is this by design on purpose, or can we fix with below? > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index 4...

...0 PCI-MSI 65540-edge virtio0-req.3 > ... ... > > In above case, there is one msix vector per queue. > > > This is because the max number of queues is not limited by the number of > possible cpus. > > By default, nvme (regardless about write_queues and poll_queues) and > xen-blkfront limit the number of queues with num_possible_cpus(). > > > Is this by design on purpose, or can we fix with below? > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index 4bc083b..df95ce3 100644 > --- a/drivers/block/vi...

...le more queues when > there is limited number of vectors. > > Another use case we may classify queues as hight priority or low priority as > mentioned by Cornelia. > > For virtio-blk, we may extend virtio-blk based on this patch set to enable > something similar to write_queues/poll_queues in nvme, when (set->nr_maps != 1). > > > Yet, the question I am asking in this email thread is for a difference scenario. > > The issue is not we are not having enough vectors (although this is why only 1 > vector is allocated for all virtio-blk queues). As so far virtio-blk...

...> > > > Please note that this is pci-specific... > > > >> > >> > >> This is because the max number of queues is not limited by the number of > >> possible cpus. > >> > >> By default, nvme (regardless about write_queues and poll_queues) and > >> xen-blkfront limit the number of queues with num_possible_cpus(). > > > > ...and these are probably pci-specific as well. > > Not pci-specific, but per-cpu as well. Ah, I meant that those are pci devices. > > > > >> > >>...

...ck layer limits the number of hw queues to the number of vcpus. This applies only to virtio devices that interact with the block layer, but regardless of the virtio transport. > That's why I think virtio-blk should use the similar solution as nvme > (regardless about write_queues and poll_queues) and xen-blkfront. Ok, the hw queues limit from above would be an argument to limit to #vcpus in the virtio-blk driver, regardless of the transport used. (No idea if there are better ways to deal with this, I'm not familiar with the interface.) For virtio devices that don't interact wit...

On Fri, 15 Mar 2019 12:50:11 +0800 Jason Wang <jasowang at redhat.com> wrote: > Or something like I proposed several years ago? > https://do-db2.lkml.org/lkml/2014/12/25/169 > > Btw, for virtio-net, I think we actually want to go for having a maximum > number of supported queues like what hardware did. This would be useful > for e.g cpu hotplug or XDP (requires per cpu

On Fri, 15 Mar 2019 12:50:11 +0800 Jason Wang <jasowang at redhat.com> wrote: > Or something like I proposed several years ago? > https://do-db2.lkml.org/lkml/2014/12/25/169 > > Btw, for virtio-net, I think we actually want to go for having a maximum > number of supported queues like what hardware did. This would be useful > for e.g cpu hotplug or XDP (requires per cpu

...t the >>>>> handle_rx is scheduled ? >>>>> If we use the vhost_has_work(), the work in the dev work_list may be >>>>> rx work, or tx work, right ? >>>> Yes. We can add a boolean to record whether or not we've called >>>> vhost_poll_queue() for rvq. And avoid calling vhost_net_enable_vq() if >>>> it was true. >>> so, the commit be294a51a "vhost_net: Avoid rx queue wake-ups during busypoll" >>> may not consider the case: work is tx work in the dev work list. >> So two kinds of work, tx k...