On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:58:01], Anthony Liguori wrote:
Amit Shah wrote:
On (Thu) Aug 06 2009 [08:29:40], Anthony Liguori wrote:
Amit Shah wrote:
Sure; but there's been no resistance from anyone from
On Friday 07 August 2009, Stephen Hemminger wrote:
So instead of adding more stuff to existing bridge code, why not
have a new driver for just VEPA. You could
do it with a simple version of macvlan type driver.
The current macvlan driver already does the downstream side of
VEPA and only needs
On Thu, 6 Aug 2009, Alasdair G Kergon wrote:
On Thu, Aug 06, 2009 at 12:14:17PM +0100, Mark McLoughlin wrote:
We should error all barriers, even empty barriers, on devices like
virtio_blk which don't support them.
Have you considered whether or not virtio_blk actually needs to
support
Hi Yaron,
Yes, I also believe that VEPA + SRIOV can potentially, in some deployments,
achieve better performance than a bridge/tap configuration, especially when you
run multiple VMs and if you want to enable more sophisticated network
processing in the data path.
If you do have a SRIOV NIC
On Fri, 7 Aug 2009 14:06:58 -0700
Paul Congdon \(UC Davis\) ptcong...@ucdavis.edu wrote:
Yaron,
The interface multiplexing can be achieved using macvlan driver or using an
SR-IOV capable NIC (the preferred option), macvlan may need to be extended to
support VEPA multicast handling, this
