On Wed, 2012-09-12 at 07:40 -0700, Tom Herbert wrote: > On Wed, Sep 12, 2012 at 12:57 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell 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 still possible with accelerated RFS. We have an > algorithm that prevents this for RFS 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. [...] Yes, I couldn't see any way to eliminate the possibility of OOO. The software queue check in RFS should redirect the flow only when it is new or has had an idle period, when I hope only a few packets will be received before we send some kind of response (transport or application layer ACK). So I think that OOO is not that likely in practice, but I don't have the evidence to back that up. If the filter update latency is high enough that a response can overtake the filter update, there may be more of a problem. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
