We neglected virtio-net userspace in rhel6 since the default is vhost.
Practically there is no need to use virtio-net at all.

So, I don't think we should diverge from upstream for this. It is nice to fix so we'll have a userspace solution too. Let's do it on upstream first.

Until that happens, just ignore virtio-net on rhel6 and use vhost only.

So, I'm not sure that I agree with Dors assessment of the need to continue to neglect this.

This is a 75% performance regression from the previous release. 

This performance makes this *non-competitive* 
    in fact we got exceptions at the end of the RHEL5.4 release to add changes that brought similar performance close to the levels we see now.  

If we are no longer going to support this functionality then drop it from this release. Otherwise it needs to get corrected. 

Other factors to consider:
1) while vhost_net is planned to be the default in RHEL6, I am assuming that will only apply to new guests, not existing configurations. So to not fix this implies the need for tools to update existing RHEL5 based configurations to use vhost net. Are there plans to do that ? 

1a) Any solution to 1 needs to include RHEV-M, libvirt, and command line usage.

(In reply to comment #3)
> So, I'm not sure that I agree with Dors assessment of the need to continue to
> neglect this.
> 
> This is a 75% performance regression from the previous release. 
> 
> This performance makes this *non-competitive* 
>     in fact we got exceptions at the end of the RHEL5.4 release to add changes
> that brought similar performance close to the levels we see now.  
> 
> If we are no longer going to support this functionality then drop it from this
> release. Otherwise it needs to get corrected. 
> 
> Other factors to consider:
> 1) while vhost_net is planned to be the default in RHEL6, I am assuming that
> will only apply to new guests, not existing configurations. So to not fix this
> implies the need for tools to update existing RHEL5 based configurations to use
> vhost net. Are there plans to do that ? 


vhost-net and virtio-net are backends. It is 100% transparent for the guest. So we can easily switch to using vhost without *any* guest change.
This is the plan.

> 
> 1a) Any solution to 1 needs to include RHEV-M, libvirt, and command line usage.    

Use vhost and only vhost.

is there any reason why we'd keep virtio-net? If it's performance is degraded and we've effectively deprecated it, is there any reason to keep it?

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

(In reply to comment #5)
> is there any reason why we'd keep virtio-net? If it's performance is degraded
> and we've effectively deprecated it, is there any reason to keep it?    

There isn't. That's why I'm closing it as won't fix.
Mark, all components - libvirt/vdsm will use vhost by default. It is transparent to the guest. If we'll have any motivation to fix it, I'll be the first to ask for this fix.

To what extent are you proposing to drop virtio-net?  As a kernel
module or from KVM?  We have guests where virtio-net is hard-coded,
eg if you have ever installed RHEL 5 as a guest on top of KVM:

# guestfish -i RHEL55x64 --ro
><fs> cat /etc/modprobe.conf 
alias scsi_hostadapter ata_piix
alias eth0 virtio_net
alias scsi_hostadapter1 virtio_blk

Let me clarify: the issue is that the compatibility -net flag is used.
offloads are currently silently disabled unless the new -netdev flag is used.
This is what hurts performance.

So the proposal is to exit unless user explicitly disabled offloads.