align() invocation in
> add_recvbuf_small(), suggested by Venkatesh Srinivas
> ---
> drivers/net/virtio_net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index fb0eae4..100e039 100644
> --- a/drivers/net/
-
+1% bandwidth).
What tests did you see a 2-3% win on?
Do you think its worth modifying add_recvbuf_small() to use
napi_alloc_skb() when called from
Rx NAPI (virtnet_receive)?
Tested-by: Venkatesh Srinivas
Thanks,
-- vs;
___
Virtualization mailing list
noise (+0.6%
- +1% bandwidth).
What tests did you see a 2-3% win on?
Do you think its worth modifying add_recvbuf_small() to use
napi_alloc_skb() when called from
Rx NAPI (virtnet_receive)?
Tested-by: Venkatesh Srinivas
Thanks,
-- vs;
___
Virtualiz
On Mon, Nov 30, 2015 at 11:15:23AM +0200, Michael S. Tsirkin wrote:
> We know vring num is a power of 2, so use &
> to mask the high bits.
>
> Signed-off-by: Michael S. Tsirkin
> ---
The generated code switches from DIV -> masking, source is clearer as well.
Tested-
>
> static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
> {
> - return __cpu_to_virtio64(virtio_has_feature(vdev, VIRTIO_F_VERSION_1),
> val);
> + return __cpu_to_virtio64(virtio_is_little_endian(vdev), val);
> }
Tested patch with vring-bench. (I did somet
On Thu, Nov 19, 2015 at 04:15:48PM +, Xie, Huawei wrote:
> On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote:
> > On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote:
> >> On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote:
> >>
> >>> On
On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote:
> On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote:
>
> > On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote:
> > > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote:
> > >> O
On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei wrote:
> On 11/14/2015 7:41 AM, Venkatesh Srinivas wrote:
> > On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote:
> >>> Impro
On Wed, Nov 11, 2015 at 02:34:33PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 10, 2015 at 04:21:07PM -0800, Venkatesh Srinivas wrote:
> > Improves cacheline transfer flow of available ring header.
> >
> > Virtqueues are implemented as a pair of rings, one producer->con
1-dcache-loads
...
2.168405376 seconds time elapsed
The further away (in a NUMA sense) virtio producers and consumers are
from each other, the more we expect to benefit. Physical implementations
of virtio devices and implementations of virtio where the consumer polls
vring a
has resolved.
Signed-off-by: Venkatesh Srinivas
---
drivers/scsi/virtio_scsi.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index db3b494..6cd39cd 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
wrote:
>> And I rewrote it substantially, mainly to take
>> VIRTIO_RING_F_INDIRECT_DESC into account.
>>
>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
>> have made a change. T
ivide-by-2 produced the same queue depth as the prior
computation in QEMU was deliberate -- but raising it to 128 seems
pretty reasonable.
Signed-off-by: Venkatesh Srinivas
-- vs;
___
Virtualization mailing list
Virtualization@list
virtio-blk set the default queue depth to 64 requests, which was
insufficient for high-IOPS devices. Instead set the blk-queue depth to
the device's virtqueue depth divided by two (each I/O requires at least
two VQ entries).
Signed-off-by: Venkatesh Srinivas
---
drivers/block/virtio_blk.
On Fri, Mar 14, 2014 at 10:57:58AM -0600, David Ahern wrote:
On 3/14/14, 10:17 AM, Andi Kleen wrote:
The Intel ISR section for RDMSR seems to say: "Specifying a reserved
or unimplemented
MSR address in ECX will also cause a general protection exception".
From a guest's perspective, MSR_RAPL_POW
Hi,
When KVM's check_cr_write() is invoked to write to %cr3, it tests that
the lower three bits of %cr3 are set to zero. On real h/w (tested on
Core2, K10), these bits are ignored; the AMD64 documentation describes
the bits as 'should', but not 'must' be zero. The Intel documentation
seems to indi
the hint
fast enough.
Looks good! Tested as V5.
Tested-by: Venkatesh Srinivas
-- vs;
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Engine's virtio-scsi device.
Reviewed-and-tested-by: Venkatesh Srinivas
Thanks,
-- vs;
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
18 matches
Mail list logo