On 04/20/2011 03:33 AM, Jason Wang wrote:
This patch adds the multiqueues support for emulated nics. Each VLANClientState
pairs are now abstract as a queue instead of a nic, and multiple VLANClientState
pointers were stored in the NICState and treated as the multiple queues of a
single nic. The netdev options of qdev were now expanded to accept more than one
netdev ids. A queue_index were also introduced to let the emulated nics know
which queue the packet were came from or sent out. Virtio-net would be the first
user.
The legacy single queue nics can still run happily without modification as the
the compatibility were kept.
Signed-off-by: Jason Wang<jasowang@xxxxxxxxxx>
---
hw/qdev-properties.c | 37 ++++++++++++++++++++++++++++++-------
hw/qdev.h | 3 ++-
net.c | 34 ++++++++++++++++++++++++++--------
net.h | 15 +++++++++++----
4 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 1088a26..dd371e1 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -384,14 +384,37 @@ PropertyInfo qdev_prop_chr = {
static int parse_netdev(DeviceState *dev, Property *prop, const char *str)
{
- VLANClientState **ptr = qdev_get_prop_ptr(dev, prop);
+ VLANClientState ***nc = qdev_get_prop_ptr(dev, prop);
+ const char *ptr = str;
+ int i = 0;
+ size_t len = strlen(str);
+ *nc = qemu_malloc(MAX_QUEUE_NUM * sizeof(VLANClientState *));
+
+ while (i< MAX_QUEUE_NUM&& ptr< str + len) {
+ char *name = NULL;
+ char *this = strchr(ptr, '#');
However this is being used is not going to be right. Is this taking
netdev=a#b#c#d?
I sort of agree with Michael about using multiple netdevs for this but I
don't yet understand how this gets sets up from userspace.
Can you give an example of usage that involves the full tap device setup?
Ideally, a user/management tool would never need to know about any of this.
In a perfect world, we could just dup() the tap fd a few times to create
multiple queues.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
