linux-kernel - Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4916DF99.6020107@redhat.com>
Date:	Sun, 09 Nov 2008 15:03:21 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Muli Ben-Yehuda <muli@...ibm.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>, Greg KH <greg@...ah.com>,
	Matthew Wilcox <matthew@....cx>, H L <swdevyid@...oo.com>,
	Yu Zhao <yu.zhao@...el.com>, randy.dunlap@...cle.com,
	grundler@...isc-linux.org, achiang@...com,
	linux-pci@...r.kernel.org, rdreier@...co.com,
	linux-kernel@...r.kernel.org, jbarnes@...tuousgeek.org,
	virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
	mingo@...e.hu, Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

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.
>>     
>
> I don't believe that it will, and every benchmark I've seen or have
> done so far shows a significant performance gap between virtio and
> direct assignment, even on 1G ethernet. I am willing however to
> reserve judgement until someone implements your suggestion and
> actually measures it, preferably on 10G ethernet.
>   

Right now virtio copies data, and has other inefficiencies.  With a 
dedicated VF, we can eliminate the copies.

CPU utilization and latency will be worse.  If we can limit the 
slowdowns to an acceptable amount, the simplicity and other advantages 
of VF-in-host may outweigh the performance degradation.

> No doubt device assignment---and SR-IOV in particular---are complex,
> but I hardly think ignoring it as you seem to propose is the right
> approach.

I agree.  We should hedge our bets and support both models.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/