RE: [Xen-devel] RE: Rather slow time of Ping in Windows with GPL PVdriver

[MaoXiaoyun <tinnycloud@xxxxxxxxxxx>]

Thanks James.
 
I will do some iperf test either.
 
One more quesiton:
Does "Xen will only ever deliver the evtchn interrupt to VCPU0" mentioned by Paul right?
If so, how to explain the log I printed before?
It looks like all VCPUS have got the packets.
 
===============Result================================
      1) KeSetTargetProcessorDpc(&xi->rx_dpc, 0) is commentted.
       XnetNet       pcpu = 1
       XnetNet       pcpu = 3
       XnetNet       pcpu = 2
       XnetNet       pcpu = 3
       XnetNet       pcpu = 7
       XnetNet       pcpu = 0
       XnetNet &nb sp;     pcpu = 5
       XnetNet       pcpu = 3
       XnetNet       pcpu = 0
       XnetNet       pcpu = 3
       XnetNet       pcpu = 7
       XnetNet       pcpu = 4
       XnetNet       pcpu = 5
       XnetNet       pcpu = 2
       XnetNet       pcpu = 4
       XnetNet       pcpu = 5
       XnetNet   & nbsp;   pcpu = 6
       XnetNet       pcpu = 0
       XnetNet       pcpu = 6


 
> Subject: RE: [Xen-devel] RE: Rather slow time of Ping in Windows with GPL PVdriver
> Date: Mon, 14 Mar 2011 14:10:46 +1100
> From: james.harper@xxxxxxxxxxxxxxxx
> To: tinnycloud@xxxxxxxxxxx; paul.durrant@xxxxxxxxxx
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx
>
> >
> > Do you mean if we discard KeSetTargetProcessorDpc(&xi->rx_dpc, 0) ,
> the
> > interrupts
> > will be processed across on different VCPUS, but will cause serious
> > performance issue?
> > Where could I find the releated docs?
> >
> > So actually we need do KeSetImportanceDpc(&xi->rx_dpc, HighImportance)
> to
> > solve
> > ping problem. Though performance is not the best, but it should not
> decrease,
> > right?
> >
>
> In my testing, without the KeSetTargetProcessorDpc, iperf would give
> inconsistent results, which I assume is because packets were being
> delivered to NDIS out of order.
>
> KeSetImportanceDpc(HighImportance) should resolve the 15ms response time
> you were seeing as the DPC will be immediately scheduled on the other
> processor, rather than scheduled some time later.
>
> James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel