> Hi all, > > I'm deploy OVS-DPDK into a server (to be ECS hypervisor), this server have > two NIC. > NIC-1(ens5s0f0) support DPDK, I use this NIC as datapath NIC. > NIC-2(ens5s0f1) does NOT support DPDK, I use this NIC as management NIC. > And I fork two vlan subinterface on ens5s0f1, which is ens5s0f1.1000 and > ens5s0f1.1001 > > As ens5s0f1.1000 and ens5s0f1.1001 does NOT support DPDK, I use ovs > bridge(type system) to add these NIC to br_mgmt_system and br_ctrl_system. > For openstack OVS-DPDK usage, it create bridges br-ctrl/br-int/br-mgmt/... > (br-nsp is my private bridge, omit it) as type netdev. > > To connect br_ctrl_system and br-ctrl (and br_mgmt_system and br-mgmt), > which is NOT same type bridge, I use veth-pair NIC (veth-x as bellow). > Add I add 192.168.2.10/24 as management IP on br-mgmt. > > This deploy is ok, as I ping 192.168.2.10 from another server, it's ok. > > I'm new user of OVS-DPDK, I want to know detail(like how code works). So my > question is: > > 1) Why veth-pair NIC could add to bridge type netdev? In my opinion, only > dpdkxxx NIC could add into bridge type netdev, as PMD thread has dpdkxxx > driver to poll packages from NIC. Is veth-pair NIC NOT attach into PMD > thread(which is DPDK fast-path), but attach to openvswitch.ko module(which > is kernel fast-path)? If it's true, a bridge type netdev have to fast-path, > which in code, PMD thread have dpdkxxx driver and also could talk to > openvswitch.ko?
Hi, Simon. It's a common misconception about userspace datapath (type=netdev) in OVS. In fact, there is no such thing as "OVS-DPDK" or "DPDK bridge" or "DPDK datapath". Let me explain why. Userspace datapath (bridges with type=netdev) supports a wide variety of port types: - system (type=system/not set) it's a default port type. It opens existing kernel network interface with AF_PACKET socket and send/receives packets from the kernel through it. - tap (type=tap/internal). For these ports OVS will, obviously, create a TAP interface in kernel, and will send/receive packets through it. - dpdk (type=dpdk/dpdkvhostuser*). For these you need DPDK configured, so OVS will be able to open certain network intrfaces with DPDK drivers or create vhost-user interfaces. - afxdp (type=afxdp/afxdp-nonpmd). This port will open existing kernel network interface with AF_XDP socket, and will use it to send/receive packets. - dummy (type=dummy/dummy-pmd). Dummy, emulated in userspace for testing purposes. So, what you call an "OVS-DPDK" is just an OVS with userspace datapath bridges that happened to have a few dpdk ports attached. DPDK port is just one of the possible port types for userspace datapath bridges. And userspace datapath doesn't have hard dependency on DPDK. You can use it even if you built OVS without DPDK support, and you can even run pretty high-performance packet forwarding, for example, with afxdp ports on modern kernels. Answering your questions: - veth interfaces are opened by default with 'system' type ports, i.e. they are connected to userspace datapath with AF_PACKET sockets. - No, they are not attached to the openvswitch.ko, unless you add them to a different bridge with type=system. Though, I would not advise doing that as it would be a weird network topology. - 'system', 'tap'/'internal', 'afxdp-nonpmd' and 'dummy' are not polled by PMD threads, but polled by main thread (still in userspace) when there is something to receive on them (e.g. wake up on POLLIN on sockets). - 'afxdp', 'dpdk'/'dpdkvhostuser*', 'dummy-pmd' are polled by PMD threads. 'PMD thread' is a bad name too, even though it's used everywhere. It has no relation to actual driver. It should be called Poll Mode Thread or Polling Thread instead. (We need to work on terminology here, I agree.) So, these threads polls ports that require to be constantly polled, i.e. DPDK ports, afxdp ports with interrupts disabled. - If the traffic needs to flow from dpdk port to some system port, it will be sent to that port, i.e. it will be sent to the AF_PACKET socket to the host kernel's networking stack. And vice versa. > > 2) Why IP on OVS-DPDK bridge type netdev could work? In my opinion, IP > could only work in kernel TCPIP stack. bridge type netdev is in user space > PMD thread, hsa no kernel TCPIP stack. So why 192.168.2.10 could ping ok? Bridge port in userspace datapath is a port with 'internal' type, that maps to the 'type=tap'. Hence, it's a usual TAP interface, created by OVS in kernel. And so you can assign IP, MAC, attach qdisks or whatever else you can do with a normal kernel network interface. Packets received from kernel on this port will be received by the OVS's main thread and will be forwarded according to installed OpenFlow rules. Packets that needs to be sent to this port, will be sent to the kernel via tap file descriptor and will be handled by the normal kernel network stack after that. Best regards, Ilya Maximets. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
