RE: [Xen-devel][PATCH][RFC] Using data polling mechanism in netfront toreplace event notification between netback and netfront

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> Hi,
>       This is a VNIF optimization patch, need for your comments.
Thanks!
> 
> [Background]:
>       One of the VNIF driver's scalability issues is the high event
channel
> frequency. It's highly related to physical NIC's interrupt frequency
in dom0,
> which could be 20K HZ in some situation. The high frequency event
channel
> notification makes the guest and dom0 CPU utilization at a high value.
> Especially for HVM PV driver, it brings high rate of interrupts, which
could
> cost a lot of CPU cycle.
>       The attached patches have two parts: one part is for netback,
and the
> other is for netfront. The netback part is based on the latest PV-Ops
Dom0,
> and the netfront part is based on the 2.6.18 HVM unmodified driver.
>       This patch uses a timer in netfront to poll the ring instead of
event
> channel notification. If guest is transferring data, the timer will
start
> working and periodicaly send/receive data from ring. If guest is idle
and no
> data is transferring, the timer will stop working automatically. It
will
> restart again once there is new data transferring.
>       We set a feature flag in xenstore to indicate whether the
> netfront/netback support this feature. If there is only one side
supporting
> it, the communication mechanism will fall back to default, and the new
feature
> will not be used. The feature is enabled only when both sides have the
flag
> set in xenstore.
>       One problem is the timer polling frequency. This netfront part
patch is
> based on 2.6.18 HVM unmodified driver, and in that kernel version,
guest
> hrtimer is not accuracy, so I use the classical timer. The polling
frequency
> is 1KHz. If rebase the netfront part patch to latest pv-ops, we could
use
> hrtimer instead.
> 

I experimented with this in Windows too, but the timer resolution is too
poor. I think you should also look at setting the 'event' parameter too.
The current driver tells the backend to tell it as soon as there is a
single packet ready to be notified (np->rx.sring->rsp_event =
np->rx.rsp_cons + 1), but you could set it to a higher number and also
use the timer, eg "tell me when there are 32 ring slots filled, or when
the timer elapses". That way you should have less problems with
overflows.

Also, I don't think you need to tell the backend to stop notifying you,
just don't set the 'event' field in the frontend and then
RING_PUSH_RESPONSES_AND_CHECK_NOTIFY in the backend will not return that
a notification is required.

James


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