Bug 1460862 - Sanity check for coalesce setting in virtual interface
Sanity check for coalesce setting in virtual interface
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Martin Kletzander
yalzhang@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-12 21:37 EDT by yalzhang@redhat.com
Modified: 2017-08-23 08:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-23 08:27:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description yalzhang@redhat.com 2017-06-12 21:37:27 EDT
Description of problem:
coalesce setting only support in network and bridge type interface devices with virtio model type and vhost as backend driver currently. But now, guest with coalesce settings can start without these prerequisites.

Version-Release number of selected component (if applicable):
libvirt-3.2.0-9.el7.x86_64
kernel-3.10.0-671.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
Scenario 1: interface type = network, with hostdev or macvtap network, the guest can start with coalesce setting, but coalesce setting takes no effect.
1.
# virsh net-dumpxml direct-macvtap
<network>
  <name>direct-macvtap</name>
  <uuid>06848478-25db-4edc-8a85-27a0778b3f50</uuid>
  <forward dev='enp0s25' mode='bridge'>
    <interface dev='enp0s25'/>
  </forward>
</network>

2.
# virsh start rhel7
Domain rhel7 started

3.
# virsh dumpxml rhel7 --inactive | grep /interface -B10
    <interface type='network'>
      <mac address='52:54:00:65:60:17'/>
      <source network='direct-macvtap'/>
      <model type='virtio'/>
      <coalesce>
        <rx>
          <frames max='32'/>
        </rx>
      </coalesce>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

# virsh dumpxml rhel7 | grep /interface -B12
    <interface type='direct'>
      <mac address='52:54:00:65:60:17'/>
      <source network='direct-macvtap' dev='enp0s25' mode='bridge'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <coalesce>
        <rx>
          <frames max='32'/>
        </rx>
      </coalesce>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
4. 
# ethtool -c macvtap0 
Coalesce parameters for macvtap0:
Cannot get device coalesce settings: Operation not supported

---------------------------hostdev----------------------
1. 
# virsh dumpxml test --inactive | grep /interface -B10
    <interface type='network'>
      <mac address='52:54:00:08:da:72'/>
      <source network='hostnet'/>
      <model type='virtio'/>
      <coalesce>
        <rx>
          <frames max='64'/>
        </rx>
      </coalesce>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

2. 
# virsh start test
virsh Domain test started

3. 
# virsh dumpxml test | grep /interface -B14
    <interface type='hostdev' managed='yes'>
      <mac address='52:54:00:08:da:72'/>
      <driver name='vfio'/>
      <source>
        <address type='pci' domain='0x0000' bus='0x86' slot='0x10' function='0x1'/>
      </source>
      <model type='virtio'/>
      <coalesce>
        <rx>
          <frames max='64'/>
        </rx>
      </coalesce>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


Scenario 2: For model type other than virtio(rtl8139, e1000, e1000e), coalesce setting can be set in interface xml, but in fact it takes no effect as it needs vhost as backend driver. 

1.
# virsh start rhel7
Domain rhel7 started

2. live xml still contain the coalesce setting for other model type.

# virsh dumpxml rhel7 | grep /interface -B12
    <interface type='network'>
      <mac address='52:54:00:cf:82:da'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <coalesce>
        <rx>
          <frames max='64'/>
        </rx>
      </coalesce>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

3. although the tap device got the coalesce setting, but it needs vhost as backend.

# ethtool -c vnet0 | grep rx-frames:
rx-frames: 64


Scenario 3: If we specify the driver to <driver name='qemu'/>, coalesce setting will take no effect as it needs vhost as backend.  

1.
# virsh dumpxml rhel7 | grep /interface -B11
    <interface type='network'>
      <mac address='52:54:00:cf:82:da'/>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='qemu'/>
      <coalesce>
        <rx>
          <frames max='64'/>
        </rx>
      </coalesce>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

2.
# virsh start rhel7
Domain rhel7 started

3.
# virsh dumpxml rhel7 | grep /interface -B13
    <interface type='network'>
      <mac address='52:54:00:cf:82:da'/>
      <source network='default' bridge='virbr0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <driver name='qemu'/>
      <coalesce>
        <rx>
          <frames max='64'/>
        </rx>
      </coalesce>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

4. 
# ethtool -c vnet0  | grep rx-frames:
rx-frames: 64


Actual results:
guest with coalesce settings can start without the prerequisites, and the coalesce makes no sense.

Expected results:
libvirt will do the check and report clear error message or warning when start the guest.

Additional info:
For hostdev, there is a similar scenario refer to Bug 1311928
Comment 2 yalzhang@redhat.com 2017-06-18 00:48:29 EDT
in scenario 1 for hostdev type, similar situation is discussed on bug 1408701,
https://bugzilla.redhat.com/show_bug.cgi?id=1408701#c23
Comment 3 Martin Kletzander 2017-06-21 04:01:32 EDT
It makes sense, but I'm not convinced we should disable all such usage.  For some things it can't make any change/difference, but there is no disadvantage for it.  For some other cases, and I admit my lack of full understanding here, I can't wrap my head around why it wouldn't change anything.  Moreover, in cases where there are no differences to whether it is set or not, if that will change in the future, libvirt is ready for it.  If we disable any of those now, we'll need to enable them afterwards.
Comment 4 Martin Kletzander 2017-08-23 08:27:17 EDT
Thinking about it, I feel like whoever is setting this should already know the impact and details behind it.  So I think it's pretty safe to assume that such user doesn't need libvirt to hold their hands.

If more reasons arise, feel free to reopen this BZ or discuss below.  For now I'm closing this as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.