On Sun, 27 Mar 2011 09:52:54 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
Though IIRC, qemu's virtio barfs if the first descriptor isn't just the
hdr (barf...).
Maybe we can try fixing this before adding more flags,
then e.g. publish used flag can be resued to also
tell us layout is
On Fri, Mar 25, 2011 at 03:20:46PM +1030, Rusty Russell wrote:
3. For TX sometimes we free a single buffer, sometimes
a ton of them, which might make the transmit latency
vary. It's probably a good idea to limit this,
maybe free the minimal number possible to keep the device
On Thu, 24 Mar 2011 10:46:49 -0700, Shirley Ma mashi...@us.ibm.com wrote:
On Thu, 2011-03-24 at 16:28 +0200, Michael S. Tsirkin wrote:
Several other things I am looking at, wellcome cooperation:
1. It's probably a good idea to update avail index
immediately instead of upon kick: for RX
On Thu, 24 Mar 2011 16:28:22 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Thu, Mar 24, 2011 at 11:00:53AM +1030, Rusty Russell wrote:
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example for 1K message size, the single
TCP_STREAM
On Thu, Mar 24, 2011 at 10:46:49AM +1030, Rusty Russell wrote:
On Tue, 22 Mar 2011 13:36:50 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Mar 21, 2011 at 11:03:07AM -0700, Shirley Ma wrote:
On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
+ /* Drop packet instead
On Thu, Mar 24, 2011 at 11:00:53AM +1030, Rusty Russell wrote:
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example for 1K message size, the single
TCP_STREAM performance improved from 2.xGb/s to 4.xGb/s.
OK, we'll be getting rid of the
On Thu, 2011-03-24 at 16:28 +0200, Michael S. Tsirkin wrote:
On Thu, Mar 24, 2011 at 11:00:53AM +1030, Rusty Russell wrote:
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example for 1K message size, the single
TCP_STREAM performance
On Thu, Mar 24, 2011 at 10:46:49AM -0700, Shirley Ma wrote:
On Thu, 2011-03-24 at 16:28 +0200, Michael S. Tsirkin wrote:
On Thu, Mar 24, 2011 at 11:00:53AM +1030, Rusty Russell wrote:
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example
On Tue, 22 Mar 2011 13:36:50 +0200, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Mar 21, 2011 at 11:03:07AM -0700, Shirley Ma wrote:
On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
+ /* Drop packet instead of stop queue for better
performance
*/
I would
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example for 1K message size, the single
TCP_STREAM performance improved from 2.xGb/s to 4.xGb/s.
OK, we'll be getting rid of the kick on full, so please delete that on
all benchmarks.
Now, does the
On Thu, 2011-03-24 at 11:00 +1030, Rusty Russell wrote:
With simply removing the notify here, it does help the case when TX
overrun hits too often, for example for 1K message size, the single
TCP_STREAM performance improved from 2.xGb/s to 4.xGb/s.
OK, we'll be getting rid of the kick on
On Mon, Mar 21, 2011 at 11:03:07AM -0700, Shirley Ma wrote:
On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
+ /* Drop packet instead of stop queue for better
performance
*/
I would like to see some justification as to why this is the right
way to go and not just
On Tue, 2011-03-22 at 13:36 +0200, Michael S. Tsirkin wrote:
diff --git a/drivers/virtio/virtio_ring.c
b/drivers/virtio/virtio_ring.c
index cc2f73e..6106017 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -185,11 +185,6 @@ int virtqueue_add_buf_gfp(struct
On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote:
+ /* Drop packet instead of stop queue for better
performance
*/
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
Fair. KVM guest virtio_net TX queue
On Thu, Mar 17, 2011 at 08:28:47PM -0700, Shirley Ma wrote:
On Thu, 2011-03-17 at 08:18 -0700, Shirley Ma wrote:
On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
So, this just tries to make sure there's enough space for
max packet in the ring, if not - drop and return OK.
Shirley Ma mashi...@us.ibm.com wrote:
+ /* Drop packet instead of stop queue for better performance */
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home
On Fri, 2011-03-18 at 15:15 +0200, Michael S. Tsirkin wrote:
Is this the local or remote throughput?
With UDP_STREAM you are mostly interested in
remote throughput, local one can be pretty high
while most packets get dropped.
This is local throughput. Remote is called recv(netserver) data.
On Fri, 2011-03-18 at 08:33 -0500, Herbert Xu wrote:
Shirley Ma mashi...@us.ibm.com wrote:
+ /* Drop packet instead of stop queue for better performance
*/
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
On Wed, 16 Mar 2011 17:12:55 -0700, Shirley Ma mashi...@us.ibm.com wrote:
Signed-off-by: Shirley Ma x...@us.ibm.com
This is fascinating... and deeply weird.
OK, what's the difference between calling xmit_skb and ignoring failure,
and this patch which figures out it's going to fail before
On Thu, 2011-03-17 at 15:40 +1030, Rusty Russell wrote:
This is fascinating... and deeply weird.
OK, what's the difference between calling xmit_skb and ignoring
failure,
and this patch which figures out it's going to fail before calling
xmit_skb?
ie. what if you *just* delete this:
On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
So, this just tries to make sure there's enough space for
max packet in the ring, if not - drop and return OK.
Why bother checking beforehand though?
If that's what we want to do, we can just call add_buf and see
if it fails?
In
On Thu, 2011-03-17 at 08:18 -0700, Shirley Ma wrote:
On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
So, this just tries to make sure there's enough space for
max packet in the ring, if not - drop and return OK.
Why bother checking beforehand though?
If that's what we want to
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/virtio_net.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 82dba5a..c603daa 100644
--- a/drivers/net/virtio_net.c
On Wed, Mar 16, 2011 at 05:12:55PM -0700, Shirley Ma wrote:
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/virtio_net.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/net/virtio_net.c
24 matches
Mail list logo
