[ovs-discuss] For help about ssh between vms through ovs-dkdp

Daniele Di Proietto diproiettod at vmware.com
Thu May 21 15:23:13 UTC 2015



On 21/05/2015 15:48, "Traynor, Kevin" <kevin.traynor at intel.com> wrote:

>
>> -----Original Message-----
>> From: Daniele Di Proietto [mailto:diproiettod at vmware.com]
>> Sent: Wednesday, May 20, 2015 4:12 PM
>> To: Traynor, Kevin
>> Cc: ???0280; discuss; ??0310
>> Subject: Re: [ovs-discuss] For help about ssh between vms through
>>ovs-dkdp
>> 
>> 
>> On 20/05/2015 15:21, "Traynor, Kevin" <kevin.traynor at intel.com> wrote:
>> 
>> >
>> >
>> >> -----Original Message-----
>> >
>> >> From: Daniele Di Proietto [mailto:diproiettod at vmware.com]
>> >
>> >> Sent: Wednesday, May 20, 2015 1:47 PM
>> >
>> >> To: 钢锁0310
>> >
>> >> Cc: 通天晓0280; discuss; Traynor, Kevin
>> >
>> >> Subject: Re: [ovs-discuss] For help about ssh between vms through
>> >>ovs-dkdp
>> >
>> >>
>> >
>> >> This might be related to offloading features.
>> >
>> >>
>> >
>> >> Could you try again with this qemu "-device" option and let us know?
>> >
>> >> -device
>> >
>> >>
>> 
>>>>virtio-net-pci,netdev=net1,csum=off,gso=off,guest_tso4=off,guest_tso6=o
>>>>ff
>> >>,g
>> >
>> >> uest_ecn=off
>> >
>> >
>> >
>> >I checked this previously and the DPDK vhost lib will report those
>> >features
>> >
>> >as not available during negotiation so you should be ok with not
>> >specifying
>> >
>> >them explicitly in the qemu cmd line. I haven't tested with qemu 2.3.
>> >
>> >
>> >
>> >>
>> >
>> >>
>> >
>> >> Kevin, do you this we should mention this in INSTALL.DPDk.md?
>> >
>> >
>> >
>> >I had changed the original patch to make it optional in 3a based on
>> >feedback
>> >
>> >from Michael Tsirkin and testing. So unless we find an issue, I'd
>>prefer
>> >to
>> >
>> >leave optional.
>> >
>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswi
>>>tc
>> 
>>>h_ovs_blob_master_INSTALL.DPDK.md-23dpdk-2Dvhost-2Dvm-2Dconfiguration&d=
>>>Aw
>> 
>>>IGoQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=SmB5nZacmXNq0gKCC1s
>>>_C
>> 
>>>w5yUNjxgD4v5kJqZ2uWLlE&m=iM-aCjDqF2zfP98Zeafj9Z78WnCYvkzPSyZeV1kVGWg&s=S
>>>Om
>> >_egKoAfzUwWioueTrQ9W2sa_WSUwKC74LO5SNvWs&e=
>> >
>> 
>> If I don't add the extra options, my guests (Debian wheezy kernel 3.2
>>and
>> Ubuntu 14.04 kernel 3.13, running on QEMU 2.1.3) see these features
>> 
>> # ethtool -k eth0
>> 
>> Features for eth0:
>>                                                 rx-checksumming: off
>> [fixed]
>>                                                 tx-checksumming: on
>>         tx-checksum-ipv4: off [fixed]
>>         tx-checksum-unneeded: off [fixed]
>>         tx-checksum-ip-generic: on
>>         tx-checksum-ipv6: off [fixed]
>>         tx-checksum-fcoe-crc: off [fixed]
>>         tx-checksum-sctp: off [fixed]
>>                                                 scatter-gather: on
>>         tx-scatter-gather: on
>>         tx-scatter-gather-fraglist: on
>>                 
>>tcp-segmentation-offload:
>> on
>>         tx-tcp-segmentation: on
>>         tx-tcp-ecn-segmentation: on
>>         tx-tcp6-segmentation: on
>>                 
>>udp-fragmentation-offload:
>> on
>> 
>> generic-segmentation-offload: on
>>                 
>>generic-receive-offload: on
>>                                                 large-receive-offload:
>>off
>> [fixed]
>> [...]
>> 
>> 
>> Pings work, but everything else (e.g. DNS lookups) doesn't.
>> To fix the setup I have either to add the extra options or to disable
>>the
>> offloads (inside the guest) with
>> 
>>   ethtool -K eth0 tx off
>
>I'm seeing that too. I can see that the dpdk vhost is reporting the
>correct
>features it supports:
>VHOST_CONFIG: (0) Device configuration started
>vhost: get_features() returning: pu=0x0000000000068000
>
>where the bits represent
>#define VIRTIO_NET_F_MRG_RXBUF  0x08000 /* Host can merge receive
>buffers. */
>#define VIRTIO_NET_F_CTRL_VQ    0x20000 /* Control channel available */
>#define VIRTIO_NET_F_CTRL_RX    0x40000 /* Control channel RX mode
>support */
>
>and then the negotiation appears to complete correctly when the dpdk vhost
>set_features() is called:
>
>vhost: set_features called: pu=0x0000000000008000
>2015-05-21T14:08:56Z|00001|dpdk(cuse_thread2)|INFO|vHost Device
>'dpdkvhost0' (0) has been added
>
>but it looks like the negotiated features are not being reported or used?
># ethtool -k eth1
>Offload parameters for eth1:
>rx-checksumming: off
>tx-checksumming: on
>scatter-gather: on
>tcp-segmentation-offload: on
>udp-fragmentation-offload: on
>generic-segmentation-offload: on
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: off
>ntuple-filters: off
>receive-hashing: off
>
>Previously when I had tested, I had checked the negotiation but went on to
>run a dpdk app in the guest and didn't see this issue. So, I think it may
>need to go back into the docs...let me know what you think and I can
>adjust.

Thanks for confirming that Kevin,

It appears that qemu only negotiates offloadings with a vhost-user peer.
Looking at qemu(2.3.0) hw/net/vhost_net.c:110 it seems that
`vhost_net_get_features()` will consider disabling offloadings only if
dealing with a `NET_CLIENT_OPTIONS_KIND_VHOST_USER` peer (since vhost-cuse
"emulates" a kernel vhost, our devices will appear as
`NET_CLIENT_OPTIONS_KIND_TAP`).

I don't know why qemu behaves like this (I'm definitely not a QEMU expert),
but I'm sure it has its good reasons.

Unless you want to dig further I suggest we add the extra QEMU options to
INSTALL.DPDK.md.  Vhost-user shouldn't have this problem.

What do you think?

Daniele



More information about the discuss mailing list