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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120912075737.GA30455@redhat.com>
Date:	Wed, 12 Sep 2012 10:57:37 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	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,
	Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCHv4] virtio-spec: virtio network device multiqueue support

On Wed, Sep 12, 2012 at 03:19:11PM +0930, Rusty Russell wrote:
> Jason Wang <jasowang@...hat.com> writes:
> > On 09/10/2012 02:33 PM, Michael S. Tsirkin wrote:
> >> A final addition: what you suggest above would be
> >> "TX follows RX", right?
> 
> BTW, yes.  But it's a weird way to express what the nic is doing.

It explains what the system is doing.
TX is done by driver, RX by nic.
We document both driver and device in the spec
so I thought it's fine. any suggestions wellcome.

> >> It is in anticipation of something like that, that I made
> >> steering programming so generic.
> 
> >> I think TX follows RX is more immediately useful for reasons above
> >> but we can add both to spec and let drivers and devices
> >> decide what they want to support.
> 
> You mean "RX follows TX"?  ie. accelerated RFS.  I agree.


Yes that's what I meant. Thanks for the correction.

> 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.

Basically this has tx vq per cpu and relies on scheduler not bouncing threads
between cpus too aggressively. Appears to be what ixgbe does.

> > AFAIK, ixgbe does "rx follows tx". The only differences between ixgbe 
> > and virtio-net is that ixgbe driver programs the flow director during 
> > packet transmission but we suggest to do it silently in the device for 
> > simplicity.
> 
> Implying the receive queue by xmit will be slightly laggy.  Don't know
> if that's a problem.
> 
> Cheers,
> Rusty.

Doesn't seem to be a problem in Jason's testing so far.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ