Rusty Russell wrote:
On Friday 07 November 2008 18:17:54 Zhao, Yu wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 04:40:21PM -0600, Anthony Liguori wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
I don't think we really know what the One True Usage
Anthony Liguori wrote:
I don't think it's established that PV/VF will have less latency than
using virtio-net. virtio-net requires a world switch to send a group
of packets. The cost of this (if it stays in kernel) is only a few
thousand cycles on the most modern processors.
Using VT-d
Avi Kivity wrote:
Anthony Liguori wrote:
I don't think it's established that PV/VF will have less latency than
using virtio-net. virtio-net requires a world switch to send a group
of packets. The cost of this (if it stays in kernel) is only a few
thousand cycles on the most modern
On Fri, Nov 14, 2008 at 03:56:19PM +0800, Zhao, Yu wrote:
Hi Greg KH,
I updated PF driver to use latest SR-IOV API in the patch set v6, and
attached it. Please take a look and please let us know if you have any
comments.
Is this driver already upstream? If so, can you just send the diff
, Eddie; kvm@vger.kernel.org; Barnes, Jesse; Ronciak,
John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
On Fri, Nov 14, 2008 at 03:56:19PM +0800, Zhao, Yu wrote:
Hi Greg KH,
I updated PF driver to use latest SR-IOV API in the patch
On Fri, Nov 14, 2008 at 09:48:15AM -0800, Rose, Gregory V wrote:
It's not upstream yet. However, if you grep through for
CONFIG_PCI_IOV you'll see all the relevant code in those sections.
Wouldn't it make more sense for the IOV code to be reworked to not
require #ifdefs in a driver? There
[mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2008 10:39 AM
To: Rose, Gregory V
Cc: Zhao, Yu; Dong, Eddie; kvm@vger.kernel.org; Barnes, Jesse;
Ronciak, John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
On Fri, Nov 14, 2008
A: No.
Q: Should I include quotations after my reply?
On Fri, Nov 14, 2008 at 11:49:52AM -0700, Ronciak, John wrote:
We have been waiting for the kernel IOV work to be in place upstream
completely before we submitted the drivers. Jeff Garzik won't take
driver changes that have no user. So as
On Sat, Nov 08, 2008 at 02:48:25AM +0800, Greg KH wrote:
On Fri, Nov 07, 2008 at 11:17:40PM +0800, Yu Zhao wrote:
While we are arguing what the software model the SR-IOV should be, let me
ask two simple questions first:
1, What does the SR-IOV looks like?
2, Why do we need to support
Andi Kleen wrote:
Anthony Liguori [EMAIL PROTECTED] writes:
What we would rather do in KVM, is have the VFs appear in the host as
standard network devices. We would then like to back our existing PV
driver to this VF directly bypassing the host networking stack. A key
feature here is being
On Sun, Nov 09, 2008 at 09:37:20PM +0200, Avi Kivity wrote:
Greg KH wrote:
On Sun, Nov 09, 2008 at 02:44:06PM +0200, Avi Kivity wrote:
Greg KH wrote:
It's that second part that I'm worried about. How is that going to
happen? Do you have any patches that show this kind of
Greg KH wrote:
It's that second part that I'm worried about. How is that going to
happen? Do you have any patches that show this kind of assignment?
For kvm, this is in 2.6.28-rc.
Note there are two ways to assign a device to a guest:
- run the VF driver in the guest: this has the
Muli Ben-Yehuda wrote:
We've been talking about avoiding hardware passthrough entirely and
just backing a virtio-net backend driver by a dedicated VF in the
host. That avoids a huge amount of guest-facing complexity, let's
migration Just Work, and should give the same level of performance.
Andi Kleen wrote:
Anthony Liguori [EMAIL PROTECTED] writes:
What we would rather do in KVM, is have the VFs appear in the host as
standard network devices. We would then like to back our existing PV
driver to this VF directly bypassing the host networking stack. A key
feature here is being
Greg KH wrote:
We've been talking about avoiding hardware passthrough entirely and
just backing a virtio-net backend driver by a dedicated VF in the
host. That avoids a huge amount of guest-facing complexity, let's
migration Just Work, and should give the same level of performance.
Does
Matthew Wilcox wrote:
What we would rather do in KVM, is have the VFs appear in the host as
standard network devices. We would then like to back our existing PV
driver to this VF directly bypassing the host networking stack. A key
feature here is being able to fill the VF's receive queue
On Sun, Nov 09, 2008 at 02:44:06PM +0200, Avi Kivity wrote:
Greg KH wrote:
It's that second part that I'm worried about. How is that going to
happen? Do you have any patches that show this kind of assignment?
For kvm, this is in 2.6.28-rc.
Where? I just looked and couldn't find
Greg KH wrote:
On Sun, Nov 09, 2008 at 02:44:06PM +0200, Avi Kivity wrote:
Greg KH wrote:
It's that second part that I'm worried about. How is that going to
happen? Do you have any patches that show this kind of assignment?
For kvm, this is in 2.6.28-rc.
Where? I
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
Importance: High
On Fri, Nov 07, 2008 at 11:17:40PM +0800, Yu Zhao wrote:
While we are arguing what the software model the SR-IOV should be,
let me
ask two simple questions first:
1, What does the SR-IOV looks like?
2
];
[EMAIL PROTECTED];
[EMAIL PROTECTED]; kvm@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Leonid Grossman;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
But would such an api really take advantage of the new
On Thu, Nov 06, 2008 at 04:40:21PM -0600, Anthony Liguori wrote:
We've been talking about avoiding hardware passthrough entirely and
just backing a virtio-net backend driver by a dedicated VF in the
host. That avoids a huge amount of guest-facing complexity, let's
migration Just Work, and
Anthony Liguori [EMAIL PROTECTED] writes:
What we would rather do in KVM, is have the VFs appear in the host as
standard network devices. We would then like to back our existing PV
driver to this VF directly bypassing the host networking stack. A key
feature here is being able to fill the
While we are arguing what the software model the SR-IOV should be, let
me ask two simple questions first:
1, What does the SR-IOV looks like?
2, Why do we need to support it?
I'm sure people have different understandings from their own view
points. No one is wrong, but, please don't make
Anthony Liguori wrote:
Matthew Wilcox wrote:
[Anna, can you fix your word-wrapping please? Your lines appear to be
infinitely long which is most unpleasant to reply to]
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
Where would the VF drivers have to be associated? On the
On Fri, Nov 07, 2008 at 11:17:40PM +0800, Yu Zhao wrote:
While we are arguing what the software model the SR-IOV should be, let me
ask two simple questions first:
1, What does the SR-IOV looks like?
2, Why do we need to support it?
I don't think we need to worry about those questions, as we
Greetings (from a new lurker to the list),
To your question Greg, yes and sort of ;-). I have started taking a look
at these patches with a strong interest in understanding how they work. I've
built a kernel with them and tried out a few things with real SR-IOV hardware.
--
Lance Hartmann
On Thu, Nov 06, 2008 at 07:40:12AM -0800, H L wrote:
Greetings (from a new lurker to the list),
Welcome!
To your question Greg, yes and sort of ;-). I have started taking
a look at these patches with a strong interest in understanding how
they work. I've built a kernel with them and
I have not modified any existing drivers, but instead I threw together a
bare-bones module enabling me to make a call to pci_iov_register() and then
poke at an SR-IOV adapter's /sys entries for which no driver was loaded.
It appears from my perusal thus far that drivers using these new SR-IOV
A: No.
Q: Should I include quotations after my reply?
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw together
a bare-bones module enabling me to make a call to pci_iov_register()
and then poke at an SR-IOV adapter's /sys
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw
together
a bare-bones module enabling me to make a call to pci_iov_register()
and then poke at an SR-IOV adapter's /sys entries for which no driver
was loaded.
It
On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw together
a bare-bones module enabling me to make a call to pci_iov_register()
and then poke at an SR-IOV adapter's /sys
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw together
a bare-bones module enabling me to make a
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw
together
a bare-bones module enabling me to make a call to pci_iov_register()
and then poke at an SR-IOV
--- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead
I threw together
a bare-bones module enabling me to make a call to
pci_iov_register()
and then poke at an SR-IOV adapter's
[Anna, can you fix your word-wrapping please? Your lines appear to be
infinitely long which is most unpleasant to reply to]
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
Where would the VF drivers have to be associated? On the pci_dev
level or on a higher one?
A VF
On Thu, Nov 06, 2008 at 10:05:39AM -0800, H L wrote:
--- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead
I threw together
a bare-bones module enabling me to make a call to
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw
together
a bare-bones module enabling me
On Thu, Nov 06, 2008 at 09:53:08AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I
Matthew Wilcox wrote:
[Anna, can you fix your word-wrapping please? Your lines appear to be
infinitely long which is most unpleasant to reply to]
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
Where would the VF drivers have to be associated? On the pci_dev
level or on a
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
I don't think we really know what the One True Usage model is for VF
devices. Chris Wright has some ideas, I have some ideas and Yu Zhao has
some ideas. I bet there's other people who have other ideas too.
On Thu, Nov 06, 2008 at 04:38:40PM -0600, Anthony Liguori wrote:
It's not clear thats the right solution. If the VF devices are _only_
going to be used by the guest, then arguably, we don't want to create
pci_devs for them in the host. (I think it _is_ the right answer, but I
want to make it
* Greg KH ([EMAIL PROTECTED]) wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead I threw together
a
What we would rather do in KVM, is have the VFs appear in
the host as standard network devices. We would then like
to back our existing PV driver to this VF directly
bypassing the host networking stack. A key feature here
is being able to fill the VF's receive queue with guest
memory
On 11/6/2008 2:38:40 PM, Anthony Liguori wrote:
Matthew Wilcox wrote:
[Anna, can you fix your word-wrapping please? Your lines appear to
be infinitely long which is most unpleasant to reply to]
On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
Where would the VF
Greg KH wrote:
On Wed, Oct 22, 2008 at 04:38:09PM +0800, Yu Zhao wrote:
Greetings,
Following patches are intended to support SR-IOV capability in the
Linux kernel. With these patches, people can turn a PCI device with
the capability into multiple ones from software perspective, which
will
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:05:39AM -0800, H L wrote:
--- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not modified any existing drivers, but instead
I threw together
a bare-bones module enabling me to make a
On Fri, Nov 07, 2008 at 01:18:52PM +0800, Zhao, Yu wrote:
Greg KH wrote:
On Wed, Oct 22, 2008 at 04:38:09PM +0800, Yu Zhao wrote:
Greetings,
Following patches are intended to support SR-IOV capability in the
Linux kernel. With these patches, people can turn a PCI device with
the capability
On Thu, Nov 06, 2008 at 03:54:06PM -0800, Chris Wright wrote:
* Greg KH ([EMAIL PROTECTED]) wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
I have not
On Thu, Nov 06, 2008 at 04:40:21PM -0600, Anthony Liguori wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
I don't think we really know what the One True Usage model is for VF
devices. Chris Wright has some ideas, I have some ideas and Yu Zhao has
On Thu, Nov 06, 2008 at 03:58:54PM -0700, Matthew Wilcox wrote:
What we would rather do in KVM, is have the VFs appear in the host as
standard network devices. We would then like to back our existing PV
driver to this VF directly bypassing the host networking stack. A key
feature here
];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
kvm@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
Chris Wright wrote:
* Greg KH ([EMAIL PROTECTED]) wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
On Thu, Nov 06
Greg KH wrote:
On Thu, Nov 06, 2008 at 04:40:21PM -0600, Anthony Liguori wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
I don't think we really know what the One True Usage model is for VF
devices. Chris Wright has some ideas, I have some ideas and
On Wed, Oct 22, 2008 at 04:38:09PM +0800, Yu Zhao wrote:
Greetings,
Following patches are intended to support SR-IOV capability in the
Linux kernel. With these patches, people can turn a PCI device with
the capability into multiple ones from software perspective, which
will benefit KVM and
53 matches
Mail list logo
