On (Thu) Dec 03 2009 [09:24:23], Rusty Russell wrote: > On Wed, 2 Dec 2009 07:54:06 pm Amit Shah wrote: > > On (Wed) Dec 02 2009 [14:14:20], Rusty Russell wrote: > > > On Sat, 28 Nov 2009 05:20:35 pm Amit Shah wrote: > > > > The console could be flooded with data from the host; handle > > > > this situation by buffering the data. > > > > > > All this complexity makes me really wonder if we should just > > > have the host say the max # ports it will ever use, and just do this > > > really dumbly. Yes, it's a limitation, but it'd be much simpler. > > > > As in make sure the max nr ports is less than 255 and have per-port vqs? > > And then the buffering will be done inside the vqs themselves? > > Well < 128 (two vqs per port). The config would say (with a feature bit) > how many vq pairs there are. Sure. This was how the previous versions behaved as well. > If we want expect sparse port numbers, it can > also provide an array mapping the vq pairs to the port number (65535 or > something meaning unused). In practice I suspect 4 or 8 will be plenty > for now. > > That makes hotplugging ports pretty simple: change the array, ping > config_changed. The very early versions of this patch used this approach: a nr_ports u32 and a bitmap... > Or we could abandon numbers and just use the names; I don't mind (we still > need a way to figure out what ports are active I guess, maybe a bitmap in > the config?) ... but we dropped that approach and are now just using the 'names' as a means of identifying ports. Currently, there's only a 'nr_ports' entry in the config. For hotplug, the entry is bumped by the host and the guest adds the new ports. That's definitely simpler than maintaining the bitmap, and also we don't associate any special meaning to the port numbers themselves, which is a big plus. (Hot plug after hot unplug can be made to work with a control message as well, but that support can come in later.) Looks like we're just going back to what this patch looked like when it was sent out first. > But we get the vq buffering and flow control for free with this approach. I'll see if I can send out this spin today. Amit _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
