On Wed, Sep 19, 2012 at 11:10:10AM +0930, Rusty Russell wrote: > Tom Herbert <therbert@xxxxxxxxxx> writes: > > On Tue, Sep 11, 2012 at 10:49 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx>wrote: > >> Perhaps Tom can explain how we avoid out-of-order receive for the > >> accelerated RFS case? It's not clear to me, but we need to be able to > >> do that for virtio-net if it implements accelerated RFS. > > > > AFAIK ooo RX is possible with accelerated RFS. We have an algorithm that > > prevents this for RFS case by deferring a migration to a new queue as long > > as it's possible that a flow might have outstanding packets on the old > > queue. I suppose this could be implemented in the device for the HW > > queues, but I don't think it would be easy to cover all cases where packets > > were already in transit to the host or other cases where host and device > > queues are out of sync. > > Having gone to such great lengths to avoid ooo for RFS, I don't think > DaveM would be happy if we allow it for virtio_net. > > So, how *would* we implement such a thing for a "hardware" device? What > if the device will only change the receive queue if the old receive > queue is empty? > > Cheers, > Rusty. > I think that would do it in most cases. Or if we want to be more exact we could delay switching a specific flow until no outstanding rx packets for this flow. Not sure it's worth the hassle. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
