| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel][PATCH][RFC] Using data polling mechanism in netfront tor
|
To: |
"Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel][PATCH][RFC] Using data polling mechanism in netfront toreplace event notification between netback and netfront |
|
From: |
"James Harper" <james.harper@xxxxxxxxxxxxxxxx> |
|
Date: |
Thu, 10 Sep 2009 19:47:55 +1000 |
|
Cc: |
"Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx> |
|
Delivery-date: |
Thu, 10 Sep 2009 02:48:25 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<EADF0A36011179459010BDF5142A457501CD8BF3B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<EADF0A36011179459010BDF5142A457501CD8BF336@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0177D1E4@trantor> <EADF0A36011179459010BDF5142A457501CD8BF3B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Acox6jFOUMf61+LiTw60WvyWTJXRuAAAiMpAAAIiU+AAAPACsA== |
|
Thread-topic: |
[Xen-devel][PATCH][RFC] Using data polling mechanism in netfront toreplace event notification between netback and netfront |
>
> Here the w/ FE patch means that applying the first solution patch
attached in
> my last mail. w/ BE patch means applying the second solution patch
attached in
> this mail.
>
I think you also need to measure dropped packets (which presumably
happened due to buffer overflow), latency, and maybe jitter. The latter
two might be hard to measure with enough resolution to be significant
though.
What I saw when I was testing this sort of thing under Windows was that
instead of receiving a constant stream of a few packets at a time, I
received less frequent but much larger chunks of packets, which caused
more work to be done per DPC.
Does Xen give Windows any high resolution timers to play with? The best
I could find (I didn't look that hard) was the standard windows timer
which has >10ms resolution.
I think it might be good, as you have suggested, to push all the smarts
back to the back end. Have some tunable figures (either via xenbus or
via ring comms) to give the parameters of when a notify is needed eg:
. maximum time since last notification
. maximum time since last packet
. number of packets to notify at, regardless of timeout (this is the
event setting in the ring, although maybe not using that and having a
separate backend driven auto-scaling algorithm might be worthwhile)
Sounds like a bit of work though...
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home