Hi,
I would like to bring up my kvm guest with dpdk vhost interface. Before
I run qemu, I have added
dpdkvhost interface in ovs bridge, so as to attach with qemu later (wrt
INSTALL.DPDK.md).
Once I created dpdkvhost interface, I noticed that dpdkvhost0 was in
LINK_DOWN (I think it is
expected as the device does not exist yet).
Correct.
ovs-master# ovs-vsctl add-port br0 dpdkvhost0 -- set Interface
dpdkvhost0 type=dpdkvhost
ovs-master# ovs-ofctl show br0
OFPT_FEATURES_REPLY (xid=0x2): dpid:000090e2ba1524ac
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src
mod_tp_dst
1(dpdk0): addr:90:e2:ba:15:24:ac
config: 0
state: 0
current: 10GB-FD
supported: 10MB-HD 100MB-HD 1GB-HD COPPER AUTO_NEG
AUTO_PAUSE
speed: 10000 Mbps now, 1000 Mbps max
2(dpdkvhost0): addr:00:00:00:00:00:00
config: PORT_DOWN
state: LINK_DOWN <<<<<<
speed: 0 Mbps now, 0 Mbps max
LOCAL(br0): addr:90:e2:ba:15:24:ac
config: 0
state: 0
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
From ovs-vswitchd.log (with debug info):
2015-06-02T14:49:38.149Z|00464|bridge|INFO|bridge br0: added interface
dpdkvhost0 on port 2
2015-06-
02T14:49:38.149Z|00465|netlink_socket|DBG|nl_sock_transact_multiple__
(Success): nl(len:52, type=37(family-defined), flags=1[REQUEST], seq=1a,
pid=4294962434
2015-06-02T14:49:38.149Z|00466|netlink_socket|DBG|nl_sock_recv__
(Success): nl(len:72, type=2(error), flags=0, seq=1a, pid=4294962434
error(-2(No such file or directory), in-reply-to(nl(len:52,
type=37(family-defined), flags=1[REQUEST], seq=1a, pid=4294962434))
2015-06-02T14:49:38.149Z|00467|netlink_socket|DBG|received NAK error=0
(No such file or directory)
Then I brought up qemu kvm, but still the state of dpdkvhost0 remains
same. Networking params I used in qemu are:
LINK_DOWN here is still normal behaviour. Since you can see the ARP request on
the port, it is safe to assume the port is up.
-netdev
tap,id=hostnet2,script=no,downscript=no,ifname=dpdkvhost0,vhost=on
-device
virtio-net-
pci,netdev=hostnet2,csum=off,gso=off,guest_tso4=off,guest_tso6=off,gues
t_ecn=off,id=net2,mac=52:54:00:a3:a3:5d,ioeventfd=on
-object
memory-backend-file,id=mem,size=4096M,mem-
path=/dev/hugepages,share=on
-numa node,memdev=mem -mem-prealloc
Am I missing something here ?
These parameters look ok, although I'm not sure if the ioeventfd=on parameter
is needed.
dpdk0 port is Intel 82599 10Gbps NIC bound on igb_uio driver. VM could
recieve arp req from remote system (on dpdk0 port), but VM's arp
response does not seem to cross ovs.
I did not see any arp response reportedly logged by vswitchd even with
debug info turned on, or may be that ovs is dropping them internally ?.
Or, Should dpdkvhost0 be internal port (tap) here for ovs to handle arp
response from VM ?
This shouldn't be necessary.
from ovs-ofctl dump-flows:
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=47.090s, table=0, n_packets=59, n_bytes=3741,
idle_age=1, in_port=1 actions=output:2
cookie=0x0, duration=42.129s, table=0, n_packets=0, n_bytes=0,
idle_age=42, in_port=2 actions=output:1
This is blocking the connection to get established with VM (from remote
system talking through dpdk0).
My env info:
Ubuntu 14.10
ovs-vsctl (Open vSwitch) 2.3.90
Compiled May 19 2015 04:27:58
DB Schema 7.12.1
dpdk-2.0.0
Any help/pointer to further diagnose is greatly appreciated.
I've created a similar setup on a Fedora system and I unfortunately I cannot
reproduce. I have one bridge, with 1 x dpdkport and 1 x dpdkvhost port, and the
same flows; in_port=1,output:2 & in_port=2,output:1
I'm using a traffic generator to simulate the ARP request.
On my guest, I bring up the dpdkvhost Ethernet device, assign it an IP address, and "arp -s
<IP of sender of ARP req> <MAC of sender of ARP req>"
When I send the ARP req, I see the response going through the switch and back
to the traffic generator.
Potentially there is an issue with your OS, I had a quick look and found a post
in the discuss archive about a potential problem with Debian/Ubuntu systems and
how they handle ARP packets with OVS:
http://openvswitch.org/pipermail/discuss/2012-May/007348.html
It is quite old however so I'm not sure if the issue still exists, or if this
is relevant to your set up.
--
Regards,
Gowrishankar M
