On 21/05/2015 15:48, "Traynor, Kevin" <kevin.tray...@intel.com> wrote:
> >> -----Original Message----- >> From: Daniele Di Proietto [mailto:diproiet...@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.tray...@intel.com> wrote: >> >> > >> > >> >> -----Original Message----- >> > >> >> From: Daniele Di Proietto [mailto:diproiet...@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 _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
