netdev - Re: [RFC PATCH 1/4] Add a new API to virtio-pci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C8E58C3.7060108@redhat.com>
Date:	Mon, 13 Sep 2010 19:00:51 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Krishna Kumar2 <krkumar2@...ibm.com>, davem@...emloft.net,
	kvm@...r.kernel.org, netdev@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [RFC PATCH 1/4] Add a new API to virtio-pci

  On 09/13/2010 06:30 PM, Michael S. Tsirkin wrote:
> Trouble is, each vhost-net device is associated with 1 tun/tap
> device which means that each vhost-net device is associated with a
> transmit and receive queue.
>
> I don't know if you'll always have an equal number of transmit and
> receive queues but there's certainly  challenge in terms of
> flexibility with this model.
>
> Regards,
>
> Anthony Liguori
> Not really, TX and RX can be mapped to different devices,
> or you can only map one of these. What is the trouble?

Suppose you have one multiqueue-capable ethernet card.  How can you 
connect it to multiple rx/tx queues?

tx is in principle doable, but what about rx?

What does "only map one of these" mean?  Connect the device with one 
queue (presumably rx), and terminate the others?


Will packet classification work (does the current multiqueue proposal 
support it)?


-- 
error compiling committee.c: too many arguments to function

--
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