netdev - Re: [PATCHv4] virtio-spec: virtio network device multiqueue support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 12 Sep 2012 20:11:23 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Tom Herbert <therbert@...gle.com>
CC:	"Michael S. Tsirkin" <mst@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jason Wang <jasowang@...hat.com>, <kvm@...r.kernel.org>,
	<virtualization@...ts.linux-foundation.org>,
	<netdev@...r.kernel.org>, <pbonzini@...hat.com>,
	<levinsasha928@...il.com>, <rick.jones2@...com>
Subject: Re: [PATCHv4] virtio-spec: virtio network device multiqueue support

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@...hat.com> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html