[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1183861813.6005.227.camel@localhost.localdomain>
Date: Sun, 08 Jul 2007 12:30:13 +1000
From: Rusty Russell <rusty@...tcorp.com.au>
To: hadi@...erus.ca
Cc: David Miller <davem@...emloft.net>, kaber@...sh.net,
peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: Multiqueue and virtualization WAS(Re: [PATCH 3/3] NET: [SCHED]
Qdisc changes and sch_rr added for multiqueue
On Fri, 2007-07-06 at 10:39 -0400, jamal wrote:
> The first thing that crossed my mind was "if you want to select a
> destination port based on a destination MAC you are talking about a
> switch/bridge". You bring up the issue of "a huge number of virtual NICs
> if you wanted arbitrary guests" which is a real one[2].
Hi Jamal,
I'm deeply tempted to agree with you that the answer is multiple
virtual NICs (and I've been tempted to abandon lguest's N-way transport
scheme), except that it looks like we're going to have multi-queue NICs
for other reasons.
Otherwise I'd be tempted to say "create/destroy virtual NICs as other
guests appear/vanish from the network". Noone does this today, but that
doesn't make it wrong.
> If i got this right, still not answering the netif_stop question posed:
> the problem you are also trying to resolve now is get rid of N
> netdevices on each guest for a usability reason; i.e have one netdevice,
> move the bridging/switching functionality/tables into the driver;
> replace the ports with queues instead of netdevices. Did i get that
> right?
Yep, well summarized. I guess the question is: should the Intel guys
be representing their multi-queue NICs as multiple NICs rather than
adding the subqueue concept?
> BTW, one curve that threw me off a little is it seems most of the
> hardware that provides virtualization also provides point-to-point
> connections between different domains; i always thought that they all
> provided a point-to-point to the dom0 equivalent and let the dom0 worry
> about how things get from domainX to domainY.
Yeah, but that has obvious limitations as people care more about
inter-guest I/O: we want direct inter-guest networking...
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists