Anthony Liguori wrote: > Aurelien Jarno wrote: >> On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote: >> >>> The current logic of the can_receive handler is to allow packets >>> whenever the >>> receiver is disabled or when there are descriptors available in the >>> ring. >>> >>> I think the logic ought to be to allow packets whenever the receiver >>> is enabled >>> and there are descriptors available in the ring. >>> >> >> The current behaviour is actually correct, this is the way QEMU works: >> when the card is stopped, it should always accept packets, and then >> discard them. >> > > The previous patches in my virtio series change that behavior. Before > delivering a packet to a VLAN, it checks to see if any of the VLAN > clients are able to receive a packet. > > This is very important for achieving good performance with tap. With > virtio-net, we were dropping a ton of packets with tap because there > weren't descriptors available on the RX ring. > > I plan to submit that behavioral change to QEMU upstream along with > the virtio drivers. I'm still optimizing phys_page_find() though. > The performance impact of switching the ring manipulation to using the > stl_phys accessors is unacceptable for KVM.
I think this indicates a virtio tuning problem. The rx queue should never be empty on normal operation, ever. Signalling on rx queue empty invites the overrun since it takes time for the interrupt to be delivered and for the guest to refill the queue. Long term we need to do this dynamically but we can start with signalling on rx queue half empty (or half full if you're an optimist). We further need to tune the queue size so that this results in an acceptable number of interrupts: 1 Gbps = 83K pps = 83 entries per half queue @ 1 KHz interrupt rate So we need 166 entries on the queue to keep a moderate interrupt rate, if we change it to signal at the halfway mark. Note that flow control still makes sense since it allows us to buffer some packets if the guest is scheduled out. But we can't use it as the primary mechanism since it won't exist with multiqueue NICs (where the virtio descriptors are fed to driver). Similar reasoning probably applied to tx. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
