| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [PATCH] Netchannel2 optimizations [2/4]
>
> I've also added a (very stupid) adaptation scheme which tries
> to adjust the max_count_frags_no_event parameter to avoid
> hitting the deadlock too often in the first place. It seems
> to do broadly the right thing for both UDP floods and TCP
> stream tests, but it probably wouldn't be very hard to come
> up with some workload for which it falls over.
>
OK, I will test how this work on 10 gig NICs when I have some time.
I am currently doing some tests on Intel 10gig ixgbe NICs and I am seeing
some behaviour that I cannot explain (without this adaptation patch).
Netperf is not able to saturate the link and at the same time both the guest
and dom0 cannot not saturate the CPU either ( I made sure the client is not the
bottleneck either). So some other factor is limiting throughput. (I disabled
the netchannel2 rate limiter but this did not seem to have any effect either).
I will spend some time looking into that.
Regards
Renato
> > We could also make the number of fragments that generate
> an event a
> > configurable paramenter that it could be adjusted (right
> now it is an
> > constant). So a sys admin would have an option to configure
> it with a
> > value compatible with the default socket buffer. What about
> combining
> > the timer with a configurable parameter?
> I guess it wouldn't hurt to make this stuff configurable,
> although I think you may be overestimating the average
> sysadmin if you think they're going to know the default
> socket buffer size (hell, *I* don't know the default socket
> buffer size).
>
> Steven.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home