On Fri, 7 Aug 2009 14:06:58 -0700
"Paul Congdon \(UC Davis\)" 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 looks like a
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 th
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
> su
Amit Shah wrote:
> On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
>
>> Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
>> asking for trouble. It is bound to break when widely deployed and
>>
>
> It's no different from the way major-minor numbering works on the Linux
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 need
