* Re: virtio scsi host draft specification, v3
From: Michael S. Tsirkin @ 2011-06-29 10:31 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
Linux Kernel Mailing List, qemu-devel, Christoph Hellwig,
Linux Virtualization
In-Reply-To: <4E0AF925.2050707@redhat.com>
On Wed, Jun 29, 2011 at 12:06:29PM +0200, Paolo Bonzini wrote:
> On 06/29/2011 12:03 PM, Christoph Hellwig wrote:
> >> I agree here, in fact I misread Hannes's comment as "if a driver
> >> uses more than one queue it is responsibility of the driver to
> >> ensure strict request ordering". If you send requests to different
> >> queues, you know that those requests are independent. I don't think
> >> anything else is feasible in the virtio framework.
> >
> >That doesn't really fit very well with the SAM model. If we want
> >to use multiple queues for a single LUN it has to be transparent to
> >the SCSI command stream. Then again I don't quite see the use for
> >that anyway.
>
> Agreed, I see a use for multiple queues (MSI-X), but not for
> multiple queues shared by a single LUN.
>
> Paolo
Then let's make it explicit in the spec?
--
MST
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Christoph Hellwig @ 2011-06-29 10:27 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm, Michael S. Tsirkin,
qemu-devel, Linux Kernel Mailing List, Christoph Hellwig,
Paolo Bonzini, Linux Virtualization
In-Reply-To: <4E0AFD2A.80102@suse.de>
On Wed, Jun 29, 2011 at 12:23:38PM +0200, Hannes Reinecke wrote:
> The general idea here is that we can support NPIV.
> With NPIV we'll have several scsi_hosts, each of which is assigned a
> different set of LUNs by the array.
> With virtio we need to able to react on LUN remapping on the array
> side, ie we need to be able to issue a 'REPORT LUNS' command and
> add/remove LUNs on the fly. This means we have to expose the
> scsi_host in some way via virtio.
>
> This is impossible with a one-to-one mapping between targets and
> LUNs. The actual bus-level pass-through will be just on the SCSI
> layer, ie 'REPORT LUNS' should be possible. If and how we do a LUN
> remapping internally on the host is a totally different matter.
> Same goes for the transport details; I doubt we will expose all the
> dingy details of the various transports, but rather restrict
> ourselves to an abstract transport.
If we want to support traditional NPIV that's what we have to do.
I still hope we'll see broad SR-IOV support for FC adapters soon,
which would ease all this greatly.
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Hannes Reinecke @ 2011-06-29 10:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm, Michael S. Tsirkin,
qemu-devel, Linux Kernel Mailing List, Paolo Bonzini,
Linux Virtualization
In-Reply-To: <20110629100752.GA27744@infradead.org>
On 06/29/2011 12:07 PM, Christoph Hellwig wrote:
> On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
>> I think we're missing a level of addressing. We need the ability to
>> talk to multiple target ports in order for "list target ports" to make
>> sense. Right now there is one implicit target that handles all
>> commands. That means there is one fixed I_T Nexus.
>>
>> If we introduce "list target ports" we also need a way to say "This
>> CDB is destined for target port #0". Then it is possible to enumerate
>> target ports and address targets independently of the LUN field in the
>> CDB.
>>
>> I'm pretty sure this is also how SAS and other transports work. In
>> their framing they include the target port.
>
> Yes, exactly. Hierachial LUNs are a nasty fringe feature that we should
> avoid as much as possible, that is for everything but IBM vSCSI which is
> braindead enough to force them.
>
Yep.
>> The question is whether we really need to support multiple targets on
>> a virtio-scsi adapter or not. If you are selectively mapping LUNs
>> that the guest may access, then multiple targets are not necessary.
>> If we want to do pass-through of the entire SCSI bus then we need
>> multiple targets but I'm not sure if there are other challenges like
>> dependencies on the transport (Fibre Channel, SAS, etc) which make it
>> impossible to pass through bus-level access?
>
> I don't think bus-level pass through is either easily possible nor
> desirable. What multiple targets are useful for is allowing more
> virtual disks than we have virtual PCI slots. We could do this by
> supporting multiple LUNs, but given that many SCSI ressources are
> target-based doing multiple targets most likely is the more scabale
> and more logical variant. E.g. we could much more easily have one
> virtqueue per target than per LUN.
>
The general idea here is that we can support NPIV.
With NPIV we'll have several scsi_hosts, each of which is assigned a
different set of LUNs by the array.
With virtio we need to able to react on LUN remapping on the array
side, ie we need to be able to issue a 'REPORT LUNS' command and
add/remove LUNs on the fly. This means we have to expose the
scsi_host in some way via virtio.
This is impossible with a one-to-one mapping between targets and
LUNs. The actual bus-level pass-through will be just on the SCSI
layer, ie 'REPORT LUNS' should be possible. If and how we do a LUN
remapping internally on the host is a totally different matter.
Same goes for the transport details; I doubt we will expose all the
dingy details of the various transports, but rather restrict
ourselves to an abstract transport.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Christoph Hellwig @ 2011-06-29 10:07 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm, Michael S. Tsirkin,
qemu-devel, Linux Kernel Mailing List, Paolo Bonzini,
Linux Virtualization
In-Reply-To: <BANLkTik2AXXkWvV23OP1eDdLirP2N0PC3A@mail.gmail.com>
On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
> I think we're missing a level of addressing. We need the ability to
> talk to multiple target ports in order for "list target ports" to make
> sense. Right now there is one implicit target that handles all
> commands. That means there is one fixed I_T Nexus.
>
> If we introduce "list target ports" we also need a way to say "This
> CDB is destined for target port #0". Then it is possible to enumerate
> target ports and address targets independently of the LUN field in the
> CDB.
>
> I'm pretty sure this is also how SAS and other transports work. In
> their framing they include the target port.
Yes, exactly. Hierachial LUNs are a nasty fringe feature that we should
avoid as much as possible, that is for everything but IBM vSCSI which is
braindead enough to force them.
> The question is whether we really need to support multiple targets on
> a virtio-scsi adapter or not. If you are selectively mapping LUNs
> that the guest may access, then multiple targets are not necessary.
> If we want to do pass-through of the entire SCSI bus then we need
> multiple targets but I'm not sure if there are other challenges like
> dependencies on the transport (Fibre Channel, SAS, etc) which make it
> impossible to pass through bus-level access?
I don't think bus-level pass through is either easily possible nor
desirable. What multiple targets are useful for is allowing more
virtual disks than we have virtual PCI slots. We could do this by
supporting multiple LUNs, but given that many SCSI ressources are
target-based doing multiple targets most likely is the more scabale
and more logical variant. E.g. we could much more easily have one
virtqueue per target than per LUN.
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Paolo Bonzini @ 2011-06-29 10:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
Michael S. Tsirkin, qemu-devel, Linux Kernel Mailing List,
Linux Virtualization
In-Reply-To: <20110629100341.GC22900@infradead.org>
On 06/29/2011 12:03 PM, Christoph Hellwig wrote:
> > I agree here, in fact I misread Hannes's comment as "if a driver
> > uses more than one queue it is responsibility of the driver to
> > ensure strict request ordering". If you send requests to different
> > queues, you know that those requests are independent. I don't think
> > anything else is feasible in the virtio framework.
>
> That doesn't really fit very well with the SAM model. If we want
> to use multiple queues for a single LUN it has to be transparent to
> the SCSI command stream. Then again I don't quite see the use for
> that anyway.
Agreed, I see a use for multiple queues (MSI-X), but not for multiple
queues shared by a single LUN.
Paolo
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Christoph Hellwig @ 2011-06-29 10:03 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
Michael S. Tsirkin, qemu-devel, Linux Kernel Mailing List,
Linux Virtualization
In-Reply-To: <4E0AE0FE.2090905@redhat.com>
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote:
> I agree here, in fact I misread Hannes's comment as "if a driver
> uses more than one queue it is responsibility of the driver to
> ensure strict request ordering". If you send requests to different
> queues, you know that those requests are independent. I don't think
> anything else is feasible in the virtio framework.
That doesn't really fit very well with the SAM model. If we want
to use multiple queues for a single LUN it has to be transparent to
the SCSI command stream. Then again I don't quite see the use for
that anyway.
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Christoph Hellwig @ 2011-06-29 10:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
qemu-devel, Linux Kernel Mailing List, Paolo Bonzini,
Linux Virtualization
In-Reply-To: <20110612075140.GB11941@redhat.com>
On Sun, Jun 12, 2011 at 10:51:41AM +0300, Michael S. Tsirkin wrote:
> For example, if the driver is crazy enough to put
> all write requests on one queue and all barriers
> on another one, how is the device supposed to ensure
> ordering?
There is no such things as barriers in SCSI. The thing that comes
closest is ordered tags, which neither Linux nor any mainstream OS
uses, and which we don't have to (and generally don't want to)
implement.
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Christoph Hellwig @ 2011-06-29 10:00 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
Michael S. Tsirkin, Linux Kernel Mailing List, qemu-devel,
Linux Virtualization, Paolo Bonzini
In-Reply-To: <4DF77E90.4080409@suse.de>
On Tue, Jun 14, 2011 at 05:30:24PM +0200, Hannes Reinecke wrote:
> Which is exactly the problem I was referring to.
> When using more than one channel the request ordering
> _as seen by the initiator_ has to be preserved.
>
> This is quite hard to do from a device's perspective;
> it might be able to process the requests _in the order_ they've
> arrived, but it won't be able to figure out the latency of each
> request, ie how it'll take the request to be delivered to the
> initiator.
>
> What we need to do here is to ensure that virtio will deliver
> the requests in-order across all virtqueues. Not sure whether it
> does this already.
This only matters for ordered tags, or implicit or explicit HEAD OF
QUEUE tags. For everything else there's no ordering requirement.
Given that ordered tags don't matter in practice and we don't have
to support them this just leaves HEAD OF QUEUE. I suspect the
HEAD OF QUEUE semantics need to be implemented using underlying
draining of all queues, which should be okay given that it's
usually used in slow path commands.
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Stefan Hajnoczi @ 2011-06-29 9:39 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm, Michael S. Tsirkin,
qemu-devel, Linux Kernel Mailing List, Linux Virtualization
In-Reply-To: <4E0AE36B.9010500@redhat.com>
On Wed, Jun 29, 2011 at 9:33 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
>> If, however, we decide to expose some details about the backend, we
>> could be using the values from the backend directly.
>> EG we could be forwarding the SCSI target port identifier here
>> (if backed by real hardware) or creating our own SAS-type
>> identifier when backed by qemu block. Then we could just query
>> the backend via a new command on the controlq
>> (eg 'list target ports') and wouldn't have to worry about any protocol
>> specific details here.
>
> Besides the controlq command, which I can certainly add, this is
> actually quite similar to what I had in mind (though my plan likely
> would not have worked because I was expecting hierarchical LUNs used
> uniformly). So, "list target ports" would return a set of LUN values to
> which you can send REPORT LUNS, or something like that?
I think we're missing a level of addressing. We need the ability to
talk to multiple target ports in order for "list target ports" to make
sense. Right now there is one implicit target that handles all
commands. That means there is one fixed I_T Nexus.
If we introduce "list target ports" we also need a way to say "This
CDB is destined for target port #0". Then it is possible to enumerate
target ports and address targets independently of the LUN field in the
CDB.
I'm pretty sure this is also how SAS and other transports work. In
their framing they include the target port.
The question is whether we really need to support multiple targets on
a virtio-scsi adapter or not. If you are selectively mapping LUNs
that the guest may access, then multiple targets are not necessary.
If we want to do pass-through of the entire SCSI bus then we need
multiple targets but I'm not sure if there are other challenges like
dependencies on the transport (Fibre Channel, SAS, etc) which make it
impossible to pass through bus-level access?
> If I understand it correctly, it should remain possible to use a single
> host for both pass-through and emulated targets.
Yes.
>> Of course, when doing so we would be lose the ability to freely remap
>> LUNs. But then remapping LUNs doesn't gain you much imho.
>> Plus you could always use qemu block backend here if you want
>> to hide the details.
>
> And you could always use the QEMU block backend with scsi-generic if you
> want to remap LUNs, instead of true passthrough via the kernel target.
IIUC the in-kernel target always does remapping. It passes through
individual LUNs rather than entire targets and you pick LU Numbers to
map to the backing storage (which may or may not be a SCSI
pass-through device). Nicholas Bellinger can confirm whether this is
correct.
Stefan
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Michael S. Tsirkin @ 2011-06-29 8:46 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
qemu-devel, Linux Kernel Mailing List, Linux Virtualization
In-Reply-To: <4E0AE0FE.2090905@redhat.com>
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote:
> On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
> >>>
> >>> If a device uses more than one queue it is the responsibility of the
> >>> device to ensure strict request ordering.
> >Maybe I misunderstand - how can this be the responsibility of
> >the device if the device does not get the information about
> >the original ordering of the requests?
> >
> >For example, if the driver is crazy enough to put
> >all write requests on one queue and all barriers
> >on another one, how is the device supposed to ensure
> >ordering?
>
> I agree here, in fact I misread Hannes's comment as "if a driver
> uses more than one queue it is responsibility of the driver to
> ensure strict request ordering". If you send requests to different
> queues, you know that those requests are independent. I don't think
> anything else is feasible in the virtio framework.
>
> Paolo
Like this then?
If a driver uses more than one queue it is the responsibility of the
driver to ensure strict request ordering: the device does not
supply any guarantees about the ordering of requests between different
virtqueues.
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Michael S. Tsirkin @ 2011-06-29 8:42 UTC (permalink / raw)
To: Tom Lendacky
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <201106281108.09285.tahm@linux.vnet.ibm.com>
On Tue, Jun 28, 2011 at 11:08:07AM -0500, Tom Lendacky wrote:
> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
> > OK, different people seem to test different trees. In the hope to get
> > everyone on the same page, I created several variants of this patch so
> > they can be compared. Whoever's interested, please check out the
> > following, and tell me how these compare:
> >
> > kernel:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> >
> > virtio-net-limit-xmit-polling/base - this is net-next baseline to test
> > against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
> > virtio-net-limit-xmit-polling/v1 - previous revision of the patch
> > this does xmit,free,xmit,2*free,free
> > virtio-net-limit-xmit-polling/v2 - new revision of the patch
> > this does free,xmit,2*free,free
> >
>
> Here's a summary of the results. I've also attached an ODS format spreadsheet
> (30 KB in size) that might be easier to analyze and also has some pinned VM
> results data. I broke the tests down into a local guest-to-guest scenario
> and a remote host-to-guest scenario.
>
> Within the local guest-to-guest scenario I ran:
> - TCP_RR tests using two different messsage sizes and four different
> instance counts among 1 pair of VMs and 2 pairs of VMs.
> - TCP_STREAM tests using four different message sizes and two different
> instance counts among 1 pair of VMs and 2 pairs of VMs.
>
> Within the remote host-to-guest scenario I ran:
> - TCP_RR tests using two different messsage sizes and four different
> instance counts to 1 VM and 4 VMs.
> - TCP_STREAM and TCP_MAERTS tests using four different message sizes and
> two different instance counts to 1 VM and 4 VMs.
> over a 10GbE link.
roprabhu, Tom,
Thanks very much for the testing. So on the first glance
one seems to see a significant performance gain in V0 here,
and a slightly less significant in V2, with V1
being worse than base. But I'm afraid that's not the
whole story, and we'll need to work some more to
know what really goes on, please see below.
Some comments on the results: I found out that V0 because of mistake
on my part was actually almost identical to base.
I pushed out virtio-net-limit-xmit-polling/v1a instead that
actually does what I intended to check. However,
the fact we get such a huge distribution in the results by Tom
most likely means that the noise factor is very large.
From my experience one way to get stable results is to
divide the throughput by the host CPU utilization
(measured by something like mpstat).
Sometimes throughput doesn't increase (e.g. guest-host)
by CPU utilization does decrease. So it's interesting.
Another issue is that we are trying to improve the latency
of a busy queue here. However STREAM/MAERTS tests ignore the latency
(more or less) while TCP_RR by default runs a single packet per queue.
Without arguing about whether these are practically interesting
workloads, these results are thus unlikely to be significantly affected
by the optimization in question.
What we are interested in, thus, is either TCP_RR with a -b flag
(configure with --enable-burst) or multiple concurrent
TCP_RRs.
> *** Local Guest-to-Guest ***
>
> Here's the local guest-to-guest summary for 1 VM pair doing TCP_RR with
> 256/256 request/response message size in transactions per second:
>
> Instances Base V0 V1 V2
> 1 8,151.56 8,460.72 8,439.16 9,990.37
> 25 48,761.74 51,032.62 51,103.25 49,533.52
> 50 55,687.38 55,974.18 56,854.10 54,888.65
> 100 58,255.06 58,255.86 60,380.90 59,308.36
>
> Here's the local guest-to-guest summary for 2 VM pairs doing TCP_RR with
> 256/256 request/response message size in transactions per second:
>
> Instances Base V0 V1 V2
> 1 18,758.48 19,112.50 18,597.07 19,252.04
> 25 80,500.50 78,801.78 80,590.68 78,782.07
> 50 80,594.20 77,985.44 80,431.72 77,246.90
> 100 82,023.23 81,325.96 81,303.32 81,727.54
>
> Here's the local guest-to-guest summary for 1 VM pair doing TCP_STREAM with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 961.78 1,115.92 794.02 740.37
> 4 2,498.33 2,541.82 2,441.60 2,308.26
>
> 1K:
> 1 3,476.61 3,522.02 2,170.86 1,395.57
> 4 6,344.30 7,056.57 7,275.16 7,174.09
>
> 4K:
> 1 9,213.57 10,647.44 9,883.42 9,007.29
> 4 11,070.66 11,300.37 11,001.02 12,103.72
>
> 16K:
> 1 12,065.94 9,437.78 11,710.60 6,989.93
> 4 12,755.28 13,050.78 12,518.06 13,227.33
>
> Here's the local guest-to-guest summary for 2 VM pairs doing TCP_STREAM with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 2,434.98 2,403.23 2,308.69 2,261.35
> 4 5,973.82 5,729.48 5,956.76 5,831.86
>
> 1K:
> 1 5,305.99 5,148.72 4,960.67 5,067.76
> 4 10,628.38 10,649.49 10,098.90 10,380.09
>
> 4K:
> 1 11,577.03 10,710.33 11,700.53 10,304.09
> 4 14,580.66 14,881.38 14,551.17 15,053.02
>
> 16K:
> 1 16,801.46 16,072.50 15,773.78 15,835.66
> 4 17,194.00 17,294.02 17,319.78 17,121.09
>
>
> *** Remote Host-to-Guest ***
>
> Here's the remote host-to-guest summary for 1 VM doing TCP_RR with
> 256/256 request/response message size in transactions per second:
>
> Instances Base V0 V1 V2
> 1 9,732.99 10,307.98 10,529.82 8,889.28
> 25 43,976.18 49,480.50 46,536.66 45,682.38
> 50 63,031.33 67,127.15 60,073.34 65,748.62
> 100 64,778.43 65,338.07 66,774.12 69,391.22
>
> Here's the remote host-to-guest summary for 4 VMs doing TCP_RR with
> 256/256 request/response message size in transactions per second:
>
> Instances Base V0 V1 V2
> 1 39,270.42 38,253.60 39,353.10 39,566.33
> 25 207,120.91 207,964.50 211,539.70 213,882.21
> 50 218,801.54 221,490.56 220,529.48 223,594.25
> 100 218,432.62 215,061.44 222,011.61 223,480.47
>
> Here's the remote host-to-guest summary for 1 VM doing TCP_STREAM with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 2,274.74 2,220.38 2,245.26 2,212.30
> 4 5,689.66 5,953.86 5,984.80 5,827.94
>
> 1K:
> 1 7,804.38 7,236.29 6,716.58 7,485.09
> 4 7,722.42 8,070.38 7,700.45 7,856.76
>
> 4K:
> 1 8,976.14 9,026.77 9,147.32 9,095.58
> 4 7,532.25 7,410.80 7,683.81 7,524.94
>
> 16K:
> 1 8,991.61 9,045.10 9,124.58 9,238.34
> 4 7,406.10 7,626.81 7,711.62 7,345.37
>
> Here's the remote host-to-guest summary for 1 VM doing TCP_MAERTS with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 1,165.69 1,181.92 1,152.20 1,104.68
> 4 2,580.46 2,545.22 2,436.30 2,601.74
>
> 1K:
> 1 2,393.34 2,457.22 2,128.86 2,258.92
> 4 7,152.57 7,606.60 8,004.64 7,576.85
>
> 4K:
> 1 9,258.93 8,505.06 9,309.78 9,215.05
> 4 9,374.20 9,363.48 9,372.53 9,352.00
>
> 16K:
> 1 9,244.70 9,287.72 9,298.60 9,322.28
> 4 9,380.02 9,347.50 9,377.46 9,372.98
>
> Here's the remote host-to-guest summary for 4 VMs doing TCP_STREAM with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 9,392.37 9,390.74 9,395.58 9,392.46
> 4 9,394.24 9,394.46 9,395.42 9,394.05
>
> 1K:
> 1 9,396.34 9,397.46 9,396.64 9,443.26
> 4 9,397.14 9,402.25 9,398.67 9,391.09
>
> 4K:
> 1 9,397.16 9,398.07 9,397.30 9,396.33
> 4 9,395.64 9,400.25 9,397.54 9,397.75
>
> 16K:
> 1 9,396.58 9,397.01 9,397.58 9,397.70
> 4 9,399.15 9,400.02 9,399.66 9,400.16
>
>
> Here's the remote host-to-guest summary for 4 VMs doing TCP_MAERTS with
> 256, 1K, 4K and 16K message size in Mbps:
>
> 256:
> Instances Base V0 V1 V2
> 1 5,048.66 5,007.26 5,074.98 4,974.86
> 4 9,217.23 9,245.14 9,263.97 9,294.23
>
> 1K:
> 1 9,378.32 9,387.12 9,386.21 9,361.55
> 4 9,384.42 9,384.02 9,385.50 9,385.55
>
> 4K:
> 1 9,391.10 9,390.28 9,389.70 9,391.02
> 4 9,384.38 9,383.39 9,384.74 9,384.19
>
> 16K:
> 1 9,390.77 9,389.62 9,388.07 9,388.19
> 4 9,381.86 9,382.37 9,385.54 9,383.88
>
>
> Tom
>
> > There's also this on top:
> > virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
> > I don't think it's important to test this one, yet
> >
> > Userspace to use: event index work is not yet merged upstream
> > so the revision to use is still this:
> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
> > virtio-net-event-idx-v3
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Paolo Bonzini @ 2011-06-29 8:33 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm, Michael S. Tsirkin,
qemu-devel, Linux Kernel Mailing List, Linux Virtualization
In-Reply-To: <4DF71E28.6070009@suse.de>
On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
> If, however, we decide to expose some details about the backend, we
> could be using the values from the backend directly.
> EG we could be forwarding the SCSI target port identifier here
> (if backed by real hardware) or creating our own SAS-type
> identifier when backed by qemu block. Then we could just query
> the backend via a new command on the controlq
> (eg 'list target ports') and wouldn't have to worry about any protocol
> specific details here.
Besides the controlq command, which I can certainly add, this is
actually quite similar to what I had in mind (though my plan likely
would not have worked because I was expecting hierarchical LUNs used
uniformly). So, "list target ports" would return a set of LUN values to
which you can send REPORT LUNS, or something like that? I suppose that
if you're using real hardware as the backing storage the in-kernel
target can provide that.
For the QEMU backend I'd keep hierarchical LUNs, though of course one
could add a FC or SAS bus to QEMU, each implementing its own identifier
scheme.
If I understand it correctly, it should remain possible to use a single
host for both pass-through and emulated targets.
Would you draft the command structure, so I can incorporate it into the
spec?
> Of course, when doing so we would be lose the ability to freely remap
> LUNs. But then remapping LUNs doesn't gain you much imho.
> Plus you could always use qemu block backend here if you want
> to hide the details.
And you could always use the QEMU block backend with scsi-generic if you
want to remap LUNs, instead of true passthrough via the kernel target.
Paolo
^ permalink raw reply
* Re: virtio scsi host draft specification, v3
From: Paolo Bonzini @ 2011-06-29 8:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Christoph Hellwig, Stefan Hajnoczi, kvm@vger.kernel.org,
qemu-devel, Linux Kernel Mailing List, Linux Virtualization
In-Reply-To: <20110612075140.GB11941@redhat.com>
On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
>> >
>> > If a device uses more than one queue it is the responsibility of the
>> > device to ensure strict request ordering.
> Maybe I misunderstand - how can this be the responsibility of
> the device if the device does not get the information about
> the original ordering of the requests?
>
> For example, if the driver is crazy enough to put
> all write requests on one queue and all barriers
> on another one, how is the device supposed to ensure
> ordering?
I agree here, in fact I misread Hannes's comment as "if a driver uses
more than one queue it is responsibility of the driver to ensure strict
request ordering". If you send requests to different queues, you know
that those requests are independent. I don't think anything else is
feasible in the virtio framework.
Paolo
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Tom Lendacky @ 2011-06-28 16:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <20110619102700.GA11198@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 6384 bytes --]
On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
> OK, different people seem to test different trees. In the hope to get
> everyone on the same page, I created several variants of this patch so
> they can be compared. Whoever's interested, please check out the
> following, and tell me how these compare:
>
> kernel:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>
> virtio-net-limit-xmit-polling/base - this is net-next baseline to test
> against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
> virtio-net-limit-xmit-polling/v1 - previous revision of the patch
> this does xmit,free,xmit,2*free,free
> virtio-net-limit-xmit-polling/v2 - new revision of the patch
> this does free,xmit,2*free,free
>
Here's a summary of the results. I've also attached an ODS format spreadsheet
(30 KB in size) that might be easier to analyze and also has some pinned VM
results data. I broke the tests down into a local guest-to-guest scenario
and a remote host-to-guest scenario.
Within the local guest-to-guest scenario I ran:
- TCP_RR tests using two different messsage sizes and four different
instance counts among 1 pair of VMs and 2 pairs of VMs.
- TCP_STREAM tests using four different message sizes and two different
instance counts among 1 pair of VMs and 2 pairs of VMs.
Within the remote host-to-guest scenario I ran:
- TCP_RR tests using two different messsage sizes and four different
instance counts to 1 VM and 4 VMs.
- TCP_STREAM and TCP_MAERTS tests using four different message sizes and
two different instance counts to 1 VM and 4 VMs.
over a 10GbE link.
*** Local Guest-to-Guest ***
Here's the local guest-to-guest summary for 1 VM pair doing TCP_RR with
256/256 request/response message size in transactions per second:
Instances Base V0 V1 V2
1 8,151.56 8,460.72 8,439.16 9,990.37
25 48,761.74 51,032.62 51,103.25 49,533.52
50 55,687.38 55,974.18 56,854.10 54,888.65
100 58,255.06 58,255.86 60,380.90 59,308.36
Here's the local guest-to-guest summary for 2 VM pairs doing TCP_RR with
256/256 request/response message size in transactions per second:
Instances Base V0 V1 V2
1 18,758.48 19,112.50 18,597.07 19,252.04
25 80,500.50 78,801.78 80,590.68 78,782.07
50 80,594.20 77,985.44 80,431.72 77,246.90
100 82,023.23 81,325.96 81,303.32 81,727.54
Here's the local guest-to-guest summary for 1 VM pair doing TCP_STREAM with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 961.78 1,115.92 794.02 740.37
4 2,498.33 2,541.82 2,441.60 2,308.26
1K:
1 3,476.61 3,522.02 2,170.86 1,395.57
4 6,344.30 7,056.57 7,275.16 7,174.09
4K:
1 9,213.57 10,647.44 9,883.42 9,007.29
4 11,070.66 11,300.37 11,001.02 12,103.72
16K:
1 12,065.94 9,437.78 11,710.60 6,989.93
4 12,755.28 13,050.78 12,518.06 13,227.33
Here's the local guest-to-guest summary for 2 VM pairs doing TCP_STREAM with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 2,434.98 2,403.23 2,308.69 2,261.35
4 5,973.82 5,729.48 5,956.76 5,831.86
1K:
1 5,305.99 5,148.72 4,960.67 5,067.76
4 10,628.38 10,649.49 10,098.90 10,380.09
4K:
1 11,577.03 10,710.33 11,700.53 10,304.09
4 14,580.66 14,881.38 14,551.17 15,053.02
16K:
1 16,801.46 16,072.50 15,773.78 15,835.66
4 17,194.00 17,294.02 17,319.78 17,121.09
*** Remote Host-to-Guest ***
Here's the remote host-to-guest summary for 1 VM doing TCP_RR with
256/256 request/response message size in transactions per second:
Instances Base V0 V1 V2
1 9,732.99 10,307.98 10,529.82 8,889.28
25 43,976.18 49,480.50 46,536.66 45,682.38
50 63,031.33 67,127.15 60,073.34 65,748.62
100 64,778.43 65,338.07 66,774.12 69,391.22
Here's the remote host-to-guest summary for 4 VMs doing TCP_RR with
256/256 request/response message size in transactions per second:
Instances Base V0 V1 V2
1 39,270.42 38,253.60 39,353.10 39,566.33
25 207,120.91 207,964.50 211,539.70 213,882.21
50 218,801.54 221,490.56 220,529.48 223,594.25
100 218,432.62 215,061.44 222,011.61 223,480.47
Here's the remote host-to-guest summary for 1 VM doing TCP_STREAM with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 2,274.74 2,220.38 2,245.26 2,212.30
4 5,689.66 5,953.86 5,984.80 5,827.94
1K:
1 7,804.38 7,236.29 6,716.58 7,485.09
4 7,722.42 8,070.38 7,700.45 7,856.76
4K:
1 8,976.14 9,026.77 9,147.32 9,095.58
4 7,532.25 7,410.80 7,683.81 7,524.94
16K:
1 8,991.61 9,045.10 9,124.58 9,238.34
4 7,406.10 7,626.81 7,711.62 7,345.37
Here's the remote host-to-guest summary for 1 VM doing TCP_MAERTS with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 1,165.69 1,181.92 1,152.20 1,104.68
4 2,580.46 2,545.22 2,436.30 2,601.74
1K:
1 2,393.34 2,457.22 2,128.86 2,258.92
4 7,152.57 7,606.60 8,004.64 7,576.85
4K:
1 9,258.93 8,505.06 9,309.78 9,215.05
4 9,374.20 9,363.48 9,372.53 9,352.00
16K:
1 9,244.70 9,287.72 9,298.60 9,322.28
4 9,380.02 9,347.50 9,377.46 9,372.98
Here's the remote host-to-guest summary for 4 VMs doing TCP_STREAM with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 9,392.37 9,390.74 9,395.58 9,392.46
4 9,394.24 9,394.46 9,395.42 9,394.05
1K:
1 9,396.34 9,397.46 9,396.64 9,443.26
4 9,397.14 9,402.25 9,398.67 9,391.09
4K:
1 9,397.16 9,398.07 9,397.30 9,396.33
4 9,395.64 9,400.25 9,397.54 9,397.75
16K:
1 9,396.58 9,397.01 9,397.58 9,397.70
4 9,399.15 9,400.02 9,399.66 9,400.16
Here's the remote host-to-guest summary for 4 VMs doing TCP_MAERTS with
256, 1K, 4K and 16K message size in Mbps:
256:
Instances Base V0 V1 V2
1 5,048.66 5,007.26 5,074.98 4,974.86
4 9,217.23 9,245.14 9,263.97 9,294.23
1K:
1 9,378.32 9,387.12 9,386.21 9,361.55
4 9,384.42 9,384.02 9,385.50 9,385.55
4K:
1 9,391.10 9,390.28 9,389.70 9,391.02
4 9,384.38 9,383.39 9,384.74 9,384.19
16K:
1 9,390.77 9,389.62 9,388.07 9,388.19
4 9,381.86 9,382.37 9,385.54 9,383.88
Tom
> There's also this on top:
> virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
> I don't think it's important to test this one, yet
>
> Userspace to use: event index work is not yet merged upstream
> so the revision to use is still this:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
> virtio-net-event-idx-v3
[-- Attachment #2: MST-Request.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 31012 bytes --]
[-- Attachment #3: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Konrad Rzeszutek Wilk @ 2011-06-28 13:47 UTC (permalink / raw)
To: Bastian Blank, xen-devel, virtualization, linux-kernel
In-Reply-To: <20110627173447.GD2430@dumpdata.com>
On Mon, Jun 27, 2011 at 01:34:47PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 27, 2011 at 07:23:05PM +0200, Bastian Blank wrote:
> > On Mon, Jun 27, 2011 at 12:57:11PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Ugh actually no I can't.
> >
> > Why? It does not actually change things.
There are two ways of doing this:
1). Split the patch in three b/c:
The backends are owned by different maintainers. The xen-netback
is owned by David Miller and he is the one that will take the patch and send
it to Linus during the next merge window. The xen-blkback is the same thing -
Jens will take it (or I can stick it in my #stable/for-jens branch and ask
him to pull everything there). Either way, for both backends, those two
folks are the ones that Linus will take the patch from - not me.
I am going to take the xenbus patches and ask Linus to pull them.
In other words, this last patch crosses three different maintainers - hence
you can either split the patch in three parts.
2). Ask each of the maintainers (David, Jens) to give you an Ack so that
this patch has both of them and then I can send it directly to Linus.
^ permalink raw reply
* Re: [PATCH 00/02][RESEND] virtio: Virtio platform driver
From: Magnus Damm @ 2011-06-28 5:14 UTC (permalink / raw)
To: Rusty Russell
Cc: vapier, mst, linux-sh, linux-kernel, virtualization,
Christian Borntraeger
In-Reply-To: <87oc1q8vnj.fsf@rustcorp.com.au>
On Wed, Jun 22, 2011 at 11:09 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Tue, 21 Jun 2011 19:26:05 +0900, Magnus Damm <magnus.damm@gmail.com> wrote:
>> virtio: Virtio platform driver
>>
>> [PATCH 01/02] virtio: Break out lguest virtio code to virtio_lguest.c
>> [PATCH 02/02] virtio: Add virtio platform driver
>>
>> These patches add a virtio platform driver to the Linux kernel. This
>> platform driver has the same role as the virtio_pci driver, but instead
>> of building on top of emulated PCI this driver is making use of the
>> platform bus together with driver specific callbacks.
>>
>> The virtio platform driver can be seen as a reusable implementation of
>> the lguest virtio driver - in fact, most code is just taken directly
>> from lguest_device.c and reworked to fit the platform device driver
>> abstraction. The first patch breaks out code that can be shared between
>> lguest and the virtio platform driver.
>>
>> This code has been used to implement a mailbox interface between the
>> two processor cores included in the sh7372 SoC. The sh7372 contains
>> one ARM Cortex-A8 and one SH4AL-DSP core, and in the prototype two
>> Linux kernels are running in parallel on the same chip. Virtio serves
>> as a communication link between the two cores.
Hi Rusty,
Thanks for your comments!
> OK, this seems pretty neat, but I have three questions before we nail this
> down (note that lguest doesn't have an ABI, so we can change it as much
> as we want).
>
> 1) The lguest bus is dumb, and I never thought about device hotplug, for
> example. It would be nice to handle that somehow. Is it possible?
> Is this something you care about?
I would most likely use device hotplug if it already existed, but my
goal with this patch and the rest of the sh7372 AMP code is to show
that virtio exists and that there is no need for people to invent
their own IPC software mechanism. So I don't care that much about
device hotplug.
I do however care about ABI and a non-GPL licensed virtio library to
allow people to tie in commercial RTOS with virtio. To prevent them
from rolling their own. It's pretty low priority though, I am quite
happy as-is staying in proof-of-concept-land running two instances of
Linux.
> 2) Have you seen the '[RFC 0/8] Introducing a generic AMP/IPC framework'
> patches? Seems to overlap with what you're doing after these patches.
Yes, there is clearly overlap, but surprisingly little. I believe
we're trying to solve different sides of the same problem.
Lguest system (Linux + Linux):
Host: lguest.c (user space) talks to /dev/lguest
Guest: lguest_device.c ties in virtio devices
SH Core Linux system (Linux + Linux):
Host: SoC-specific rtcpu-loader.c (user space) talks to /dev/uioX
Slave: SoC-specific code chats to virtio_platform.c that ties in virtio devices
"generic AMP/IPC framework" (Linux + DSP/RTOS):
Host: "remoteproc" and "rpmsg" run in the kernel
Slave: ?? (not covered by the patches I believe)
So while the "generic AMP/IPC framework" looks great for the host,
this patch tries to make something reusable on the slave/guest side.
> 3) The S/390 layout is identical, except their struct kvm_vqconfig is a
> bit different. Perhaps we should just use theirs (they use a 64-bit
> token instead of an interrupt number).
I don't mind so much, but alignment wise I find it odd that the s390
version chose to use u64 + u64 + u16.
Thanks,
/ magnus
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Konrad Rzeszutek Wilk @ 2011-06-27 17:34 UTC (permalink / raw)
To: Bastian Blank, xen-devel, virtualization, linux-kernel
In-Reply-To: <20110627172305.GC23028@wavehammer.waldi.eu.org>
On Mon, Jun 27, 2011 at 07:23:05PM +0200, Bastian Blank wrote:
> On Mon, Jun 27, 2011 at 12:57:11PM -0400, Konrad Rzeszutek Wilk wrote:
> > Ugh actually no I can't.
>
> Why? It does not actually change things.
>
> > Can you re-submit these two patches (and stick on Acked-by Ian on them) and
> > split the "xen: Add alias to autoload backend driver" in three patches:
> > 1) the xen-netback (and copy David Miller)
> > 2) the xen-blkback (and copy Jens Axboe)
> > 3) the xenbus one
>
> That is silly.
Please do it.
>
> > That should be five patches total.
>
> No, 2+2 is 4, not five.
Right. Got my math wrong.
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Bastian Blank @ 2011-06-27 17:23 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel, linux-kernel, virtualization
In-Reply-To: <20110627165711.GA2201@dumpdata.com>
On Mon, Jun 27, 2011 at 12:57:11PM -0400, Konrad Rzeszutek Wilk wrote:
> Ugh actually no I can't.
Why? It does not actually change things.
> Can you re-submit these two patches (and stick on Acked-by Ian on them) and
> split the "xen: Add alias to autoload backend driver" in three patches:
> 1) the xen-netback (and copy David Miller)
> 2) the xen-blkback (and copy Jens Axboe)
> 3) the xenbus one
That is silly.
> That should be five patches total.
No, 2+2 is 4, not five.
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Konrad Rzeszutek Wilk @ 2011-06-27 16:57 UTC (permalink / raw)
To: Bastian Blank, xen-devel, virtualization, linux-kernel
In-Reply-To: <20110627165109.GB13335@dumpdata.com>
On Mon, Jun 27, 2011 at 12:51:09PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 27, 2011 at 06:37:29PM +0200, Bastian Blank wrote:
> > On Mon, Jun 27, 2011 at 12:13:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Jun 24, 2011 at 11:51:55PM +0200, Bastian Blank wrote:
> > > > All the Xen backend drivers are assigned to a special bus type
> > > > xen-backend. This allows userspace to load the modules on request.
> > > Is there a specific version of udev that would take advantage of this?
> >
> > Was there a version within the last three years that can't? The patch is
> > tested and udev does its work.
>
> Ok, that answers that question. Queue up for 3.1
Ugh actually no I can't.
Bastian,
Can you re-submit these two patches (and stick on Acked-by Ian on them) and
split the "xen: Add alias to autoload backend driver" in three patches:
1) the xen-netback (and copy David Miller)
2) the xen-blkback (and copy Jens Axboe)
3) the xenbus one
and add Acked-by on the two backends from me and from Ian?
That should be five patches total.
I will take the xenbus patches and have them in a 3.1 branch and the
backends patches will go to the appropiate maintainer.
Thanks!
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Konrad Rzeszutek Wilk @ 2011-06-27 16:51 UTC (permalink / raw)
To: Bastian Blank, xen-devel, virtualization, linux-kernel
In-Reply-To: <20110627163728.GA23028@wavehammer.waldi.eu.org>
On Mon, Jun 27, 2011 at 06:37:29PM +0200, Bastian Blank wrote:
> On Mon, Jun 27, 2011 at 12:13:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jun 24, 2011 at 11:51:55PM +0200, Bastian Blank wrote:
> > > All the Xen backend drivers are assigned to a special bus type
> > > xen-backend. This allows userspace to load the modules on request.
> > Is there a specific version of udev that would take advantage of this?
>
> Was there a version within the last three years that can't? The patch is
> tested and udev does its work.
Ok, that answers that question. Queue up for 3.1
^ permalink raw reply
* Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Bastian Blank @ 2011-06-27 16:37 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel, linux-kernel, virtualization
In-Reply-To: <20110627161327.GO6978@dumpdata.com>
On Mon, Jun 27, 2011 at 12:13:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 24, 2011 at 11:51:55PM +0200, Bastian Blank wrote:
> > All the Xen backend drivers are assigned to a special bus type
> > xen-backend. This allows userspace to load the modules on request.
> Is there a specific version of udev that would take advantage of this?
Was there a version within the last three years that can't? The patch is
tested and udev does its work.
Bastian
--
Pain is a thing of the mind. The mind can be controlled.
-- Spock, "Operation -- Annihilate!" stardate 3287.2
^ permalink raw reply
* Re: [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Konrad Rzeszutek Wilk @ 2011-06-27 16:13 UTC (permalink / raw)
To: Bastian Blank, xen-devel, virtualization, linux-kernel
In-Reply-To: <20110624215155.GB4735@wavehammer.waldi.eu.org>
On Fri, Jun 24, 2011 at 11:51:55PM +0200, Bastian Blank wrote:
> All the Xen backend drivers are assigned to a special bus type
> xen-backend. This allows userspace to load the modules on request.
Is there a specific version of udev that would take advantage of this?
>
> This patch defines xen-backend:* aliases on the modules and exports this
> names through modalias and uevent.
>
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
> drivers/block/xen-blkback/blkback.c | 1 +
> drivers/net/xen-netback/netback.c | 1 +
> drivers/xen/xenbus/xenbus_probe.c | 3 ++-
> drivers/xen/xenbus/xenbus_probe_backend.c | 3 +++
> 4 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 5cf2993..ed62008 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -824,3 +824,4 @@ static int __init xen_blkif_init(void)
> module_init(xen_blkif_init);
>
> MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_ALIAS("xen-backend:vbd");
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0e4851b..fd00f25 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1743,3 +1743,4 @@ failed_init:
> module_init(netback_init);
>
> MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_ALIAS("xen-backend:vif");
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 2ed0b04..bd2f90c 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -393,7 +393,8 @@ static ssize_t devtype_show(struct device *dev,
> static ssize_t modalias_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> - return sprintf(buf, "xen:%s\n", to_xenbus_device(dev)->devicetype);
> + return sprintf(buf, "%s:%s\n", dev->bus->name,
> + to_xenbus_device(dev)->devicetype);
> }
>
> struct device_attribute xenbus_dev_attrs[] = {
> diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c
> index ec510e5..60adf91 100644
> --- a/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -107,6 +107,9 @@ static int xenbus_uevent_backend(struct device *dev,
> if (xdev == NULL)
> return -ENODEV;
>
> + if (add_uevent_var(env, "MODALIAS=xen-backend:%s", xdev->devicetype))
> + return -ENOMEM;
> +
> /* stuff we want to pass to /sbin/hotplug */
> if (add_uevent_var(env, "XENBUS_TYPE=%s", xdev->devicetype))
> return -ENOMEM;
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [Xen-devel] [PATCH 2/2] xen: Add alias to autoload backend drivers
From: Ian Campbell @ 2011-06-27 8:45 UTC (permalink / raw)
To: Bastian Blank, Konrad Rzeszutek Wilk, Jeremy Fitzhardinge
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20110624215155.GB4735@wavehammer.waldi.eu.org>
On Fri, 2011-06-24 at 22:51 +0100, Bastian Blank wrote:
> All the Xen backend drivers are assigned to a special bus type
> xen-backend. This allows userspace to load the modules on request.
>
> This patch defines xen-backend:* aliases on the modules and exports this
> names through modalias and uevent.
Excellent, this was a big missing piece of functionality for distros.
Thanks!
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> drivers/block/xen-blkback/blkback.c | 1 +
> drivers/net/xen-netback/netback.c | 1 +
> drivers/xen/xenbus/xenbus_probe.c | 3 ++-
> drivers/xen/xenbus/xenbus_probe_backend.c | 3 +++
> 4 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 5cf2993..ed62008 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -824,3 +824,4 @@ static int __init xen_blkif_init(void)
> module_init(xen_blkif_init);
>
> MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_ALIAS("xen-backend:vbd");
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0e4851b..fd00f25 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1743,3 +1743,4 @@ failed_init:
> module_init(netback_init);
>
> MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_ALIAS("xen-backend:vif");
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 2ed0b04..bd2f90c 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -393,7 +393,8 @@ static ssize_t devtype_show(struct device *dev,
> static ssize_t modalias_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> - return sprintf(buf, "xen:%s\n", to_xenbus_device(dev)->devicetype);
> + return sprintf(buf, "%s:%s\n", dev->bus->name,
> + to_xenbus_device(dev)->devicetype);
> }
>
> struct device_attribute xenbus_dev_attrs[] = {
> diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c
> index ec510e5..60adf91 100644
> --- a/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -107,6 +107,9 @@ static int xenbus_uevent_backend(struct device *dev,
> if (xdev == NULL)
> return -ENODEV;
>
> + if (add_uevent_var(env, "MODALIAS=xen-backend:%s", xdev->devicetype))
> + return -ENOMEM;
> +
> /* stuff we want to pass to /sbin/hotplug */
> if (add_uevent_var(env, "XENBUS_TYPE=%s", xdev->devicetype))
> return -ENOMEM;
^ permalink raw reply
* Re: [Xen-devel] [PATCH 1/2] xen: Populate xenbus device attributes
From: Ian Campbell @ 2011-06-27 8:44 UTC (permalink / raw)
To: Bastian Blank, Jeremy Fitzhardinge, Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20110624215146.GA4735@wavehammer.waldi.eu.org>
On Fri, 2011-06-24 at 22:51 +0100, Bastian Blank wrote:
> The xenbus bus type uses device_create_file to assign all used device
> attributes. However it does not remove them when the device goes away.
Doesn't the cleanup happen automatically in the device core when the
device goes away? Either way this is a good cleanup in its own right.
> This patch uses the dev_attrs field of the bus type to specify default
> attributes for all devices.
>
> Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Thanks Bastian.
Ian.
> ---
> drivers/xen/xenbus/xenbus_probe.c | 41 +++++++++------------------
> drivers/xen/xenbus/xenbus_probe.h | 2 +
> drivers/xen/xenbus/xenbus_probe_backend.c | 6 +---
> drivers/xen/xenbus/xenbus_probe_frontend.c | 6 +---
> 4 files changed, 18 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index 7397695..2ed0b04 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -378,26 +378,31 @@ static void xenbus_dev_release(struct device *dev)
> kfree(to_xenbus_device(dev));
> }
>
> -static ssize_t xendev_show_nodename(struct device *dev,
> - struct device_attribute *attr, char *buf)
> +static ssize_t nodename_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> {
> return sprintf(buf, "%s\n", to_xenbus_device(dev)->nodename);
> }
> -static DEVICE_ATTR(nodename, S_IRUSR | S_IRGRP | S_IROTH, xendev_show_nodename, NULL);
>
> -static ssize_t xendev_show_devtype(struct device *dev,
> - struct device_attribute *attr, char *buf)
> +static ssize_t devtype_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> {
> return sprintf(buf, "%s\n", to_xenbus_device(dev)->devicetype);
> }
> -static DEVICE_ATTR(devtype, S_IRUSR | S_IRGRP | S_IROTH, xendev_show_devtype, NULL);
>
> -static ssize_t xendev_show_modalias(struct device *dev,
> - struct device_attribute *attr, char *buf)
> +static ssize_t modalias_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> {
> return sprintf(buf, "xen:%s\n", to_xenbus_device(dev)->devicetype);
> }
> -static DEVICE_ATTR(modalias, S_IRUSR | S_IRGRP | S_IROTH, xendev_show_modalias, NULL);
> +
> +struct device_attribute xenbus_dev_attrs[] = {
> + __ATTR_RO(nodename),
> + __ATTR_RO(devtype),
> + __ATTR_RO(modalias),
> + __ATTR_NULL
> +};
> +EXPORT_SYMBOL_GPL(xenbus_dev_attrs);
>
> int xenbus_probe_node(struct xen_bus_type *bus,
> const char *type,
> @@ -449,25 +454,7 @@ int xenbus_probe_node(struct xen_bus_type *bus,
> if (err)
> goto fail;
>
> - err = device_create_file(&xendev->dev, &dev_attr_nodename);
> - if (err)
> - goto fail_unregister;
> -
> - err = device_create_file(&xendev->dev, &dev_attr_devtype);
> - if (err)
> - goto fail_remove_nodename;
> -
> - err = device_create_file(&xendev->dev, &dev_attr_modalias);
> - if (err)
> - goto fail_remove_devtype;
> -
> return 0;
> -fail_remove_devtype:
> - device_remove_file(&xendev->dev, &dev_attr_devtype);
> -fail_remove_nodename:
> - device_remove_file(&xendev->dev, &dev_attr_nodename);
> -fail_unregister:
> - device_unregister(&xendev->dev);
> fail:
> kfree(xendev);
> return err;
> diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus_probe.h
> index 888b990..b814935 100644
> --- a/drivers/xen/xenbus/xenbus_probe.h
> +++ b/drivers/xen/xenbus/xenbus_probe.h
> @@ -48,6 +48,8 @@ struct xen_bus_type
> struct bus_type bus;
> };
>
> +extern struct device_attribute xenbus_dev_attrs[];
> +
> extern int xenbus_match(struct device *_dev, struct device_driver *_drv);
> extern int xenbus_dev_probe(struct device *_dev);
> extern int xenbus_dev_remove(struct device *_dev);
> diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c b/drivers/xen/xenbus/xenbus_probe_backend.c
> index 6cf467b..ec510e5 100644
> --- a/drivers/xen/xenbus/xenbus_probe_backend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_backend.c
> @@ -183,10 +183,6 @@ static void frontend_changed(struct xenbus_watch *watch,
> xenbus_otherend_changed(watch, vec, len, 0);
> }
>
> -static struct device_attribute xenbus_backend_dev_attrs[] = {
> - __ATTR_NULL
> -};
> -
> static struct xen_bus_type xenbus_backend = {
> .root = "backend",
> .levels = 3, /* backend/type/<frontend>/<id> */
> @@ -200,7 +196,7 @@ static struct xen_bus_type xenbus_backend = {
> .probe = xenbus_dev_probe,
> .remove = xenbus_dev_remove,
> .shutdown = xenbus_dev_shutdown,
> - .dev_attrs = xenbus_backend_dev_attrs,
> + .dev_attrs = xenbus_dev_attrs,
> },
> };
>
> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
> index b6a2690..ed2ba47 100644
> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -81,10 +81,6 @@ static void backend_changed(struct xenbus_watch *watch,
> xenbus_otherend_changed(watch, vec, len, 1);
> }
>
> -static struct device_attribute xenbus_frontend_dev_attrs[] = {
> - __ATTR_NULL
> -};
> -
> static const struct dev_pm_ops xenbus_pm_ops = {
> .suspend = xenbus_dev_suspend,
> .resume = xenbus_dev_resume,
> @@ -106,7 +102,7 @@ static struct xen_bus_type xenbus_frontend = {
> .probe = xenbus_dev_probe,
> .remove = xenbus_dev_remove,
> .shutdown = xenbus_dev_shutdown,
> - .dev_attrs = xenbus_frontend_dev_attrs,
> + .dev_attrs = xenbus_dev_attrs,
>
> .pm = &xenbus_pm_ops,
> },
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-06-25 19:44 UTC (permalink / raw)
To: Roopa Prabhu, Tom Lendacky, Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <CA29D629.2C9B1%roprabhu@cisco.com>
[-- Attachment #1.1: Type: text/plain, Size: 3019 bytes --]
Here are the results I am getting with a Cisco 10G VIC adapter.
All tests are from the guest to an external host.
virtio-net-limit-xmit-polling/base:
TCP_STREAM: 8089Mbps
TCP_MAERTS: 9334Mbps
virtio-net-limit-xmit-polling/v0
TCP_STREAM: 8004Mbps
TCP_MAERTS: 9338Mbps
virtio-net-limit-xmit-polling/v1
TCP_STREAM: 8028Mbps
TCP_MAERTS: 9339Mbps
virtio-net-limit-xmit-polling/v2
TCP_STREAM: 8045Mbps
TCP_MAERTS: 9337Mbps
For the TCP_STREAM tests I don¹t get consistent results.
Every run gives me slightly different results. But its always between
7900Mbps to 8100Mbps.
But I also see this with the base kernel so its not related to these
patches.
Thanks,
Roopa
On 6/24/11 5:50 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:
> Michael,
>
> I am testing this too.
> I have finished one round of testing. But am running it again just to
> confirm.
> This time I will see if I can collect some exit stats too. Will post results
> sometime this weekend.
> I am just doing TCP_STREAM and TCP_MAERTS from guest to remote host.
>
> Thanks,
> Roopa
>
>
> On 6/21/11 8:23 AM, "Tom Lendacky" <tahm@linux.vnet.ibm.com> wrote:
>
>> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
>>> > OK, different people seem to test different trees. In the hope to get
>>> > everyone on the same page, I created several variants of this patch so
>>> > they can be compared. Whoever's interested, please check out the
>>> > following, and tell me how these compare:
>>
>> I'm in the process of testing these patches. Base and v0 are complete
>> and v1 is near complete with v2 to follow. I'm testing with a variety
>> of TCP_RR and TCP_STREAM/TCP_MAERTS tests involving local guest-to-guest
>> tests and remote host-to-guest tests. I'll post the results in the next
>> day or two when the tests finish.
>>
>> Thanks,
>> Tom
>>
>>> >
>>> > kernel:
>>> >
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>>> >
>>> > virtio-net-limit-xmit-polling/base - this is net-next baseline to test
>>> > against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
>>> > virtio-net-limit-xmit-polling/v1 - previous revision of the patch
>>> > this does xmit,free,xmit,2*free,free
>>> > virtio-net-limit-xmit-polling/v2 - new revision of the patch
>>> > this does free,xmit,2*free,free
>>> >
>>> > There's also this on top:
>>> > virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
>>> > I don't think it's important to test this one, yet
>>> >
>>> > Userspace to use: event index work is not yet merged upstream
>>> > so the revision to use is still this:
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
>>> > virtio-net-event-idx-v3
>>
>
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
[-- Attachment #1.2: Type: text/html, Size: 4335 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox