[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Add upper bound to receiver ring poll to reduce DPC latency
On 21/02/2023 08:40, Owen Smith wrote:
Ahh...
https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvif.git;a=blob;f=src/xenvif/receiver.c;h=21451331d330168b4792428f56057e16577c3ca7;hb=HEAD#l2469
<https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvif.git;a=blob;f=src/xenvif/receiver.c;h=21451331d330168b4792428f56057e16577c3ca7;hb=HEAD#l2469>
is a non-threaded DPC for the Poll,
https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvif.git;a=blob;f=src/xenvif/receiver.c;h=21451331d330168b4792428f56057e16577c3ca7;hb=HEAD#l2529
<https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvif.git;a=blob;f=src/xenvif/receiver.c;h=21451331d330168b4792428f56057e16577c3ca7;hb=HEAD#l2529>
is a threaded DPC for the queue.
Should both be threaded? or does the poll need to be a non-threaded DPC,
and therefore this patch should help.
I see. Mining a bit I found 264bde12317f ("Introduce a threaded DPC into
the receiver code") which very deliberately split the ring processing
between a non-threaded and a threaded DPC.
I think, rather than coming up with heuristics for how much we poll,
experimenting with a threaded DPC in both cases would be better. ISTR
there was a suspicion that a threaded DPC might have sufficient latency
to harm performance, but I can't remember how well founded that
suspicion was.
Paul
|
