Thanks very much !!! ---- Simon Jones
Ilya Maximets <[email protected]> 于2021年9月18日周六 上午6:44写道： > > 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
