similar to: [PATCH v2 1/2] virtio-ring: Use threshold for switching to indirect descriptors

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux/virtio.h | 5 +++++ 2 files changed, 13

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux/virtio.h | 5 +++++ 2 files changed, 13

Hello, In my system, dmesg outputs : [ 13.039788] wcb4xxp 0000:01:0a.0: probe called for b4xx... [ 13.039788] ACPI: PCI Interrupt 0000:01:0a.0[A] -> GSI 21 (level, low) -> IRQ 21 [ 13.039788] wcb4xxp 0000:01:0a.0: Identified HFC-8S Junghanns.NET octoBRI PCI (controller rev 1) at 0001dfe0, IRQ 21 [ 13.041202] wcb4xxp 0000:01:0a.0: NOTE: hardware echo cancellation has been disabled [

Il 19/06/2013 10:24, Michael S. Tsirkin ha scritto: >> > 2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT >> > specifically for net and block (note the new names). So why not a transport feature? Is it just because the SCSI commands for virtio-blk also require a config space field? Sorry if I missed this upthread. Paolo >> > 3) I note the

Il 19/06/2013 10:24, Michael S. Tsirkin ha scritto: >> > 2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT >> > specifically for net and block (note the new names). So why not a transport feature? Is it just because the SCSI commands for virtio-blk also require a config space field? Sorry if I missed this upthread. Paolo >> > 3) I note the

Joe Perches <joe at perches.com> writes: > On Sun, 2014-03-16 at 22:00 -0700, Joe Perches wrote: >> On Mon, 2014-03-17 at 14:25 +1030, Rusty Russell wrote: >> >> > Erk, our tests are insufficient. Testbuilding an allmodconfig with this >> > now: >> >> Good idea. >> >> > diff --git a/include/linux/moduleparam.h

Joe Perches <joe at perches.com> writes: > On Sun, 2014-03-16 at 22:00 -0700, Joe Perches wrote: >> On Mon, 2014-03-17 at 14:25 +1030, Rusty Russell wrote: >> >> > Erk, our tests are insufficient. Testbuilding an allmodconfig with this >> > now: >> >> Good idea. >> >> > diff --git a/include/linux/moduleparam.h

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 11 +++--- drivers/char/hw_random/virtio-rng.c | 11 +++--- drivers/char/virtio_console.c | 27

This replaces find_vq/del_vq with find_vqs/del_vqs virtio operations, and updates all drivers. This is needed for MSI support, because MSI needs to know the total number of vectors upfront. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/block/virtio_blk.c | 11 +++--- drivers/char/hw_random/virtio-rng.c | 11 +++--- drivers/char/virtio_console.c | 27

On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > > > However, some rng

On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > > > However, some rng

virtqueue ops were introduced in the hope that we'll have multiple implementations besides virtio_ring, but none have surfaced so far, and given that existing virtio ring is deployed in production we are likely stuck with it now, so this layer just adds complexity and overhead. Further, the need to pass vq twice to each call (as in dev->vq->vq_ops->kick(dev->vq) ) adds potential

virtqueue ops were introduced in the hope that we'll have multiple implementations besides virtio_ring, but none have surfaced so far, and given that existing virtio ring is deployed in production we are likely stuck with it now, so this layer just adds complexity and overhead. Further, the need to pass vq twice to each call (as in dev->vq->vq_ops->kick(dev->vq) ) adds potential

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

There is currently a mixture of octal and symbolic permissions uses in files in drivers/gpu/drm and one file in drivers/gpu. There are ~270 existing octal uses and ~115 S_<FOO> uses. Convert all the S_<FOO> symbolic permissions to their octal equivalents as using octal and not symbolic permissions is preferred by many as more readable. see: https://lkml.org/lkml/2016/8/2/1945 Done