On 01.12.2016 21:13, Sowmini Varadhan wrote: > On (12/01/16 11:05), Tom Herbert wrote: >> >> Polling does not necessarily imply that networking monopolizes the CPU >> except when the CPU is otherwise idle. Presumably the application >> drives the polling when it is ready to receive work. > > I'm not grokking that- "if the cpu is idle, we want to busy-poll > and make it 0% idle"? Keeping CPU 0% idle has all sorts > of issues, see slide 20 of > http://www.slideshare.net/shemminger/dpdk-performance > >>> and one other critical difference from the hot-potato-forwarding >>> model (the sort of OVS model that DPDK etc might aruguably be a fit for) >>> does not apply: in order to figure out the ethernet and IP headers >>> in the response correctly at all times (in the face of things like VRRP, >>> gw changes, gw's mac addr changes etc) the application should really >>> be listening on NETLINK sockets for modifications to the networking >>> state - again points to needing a select() socket set where you can >>> have both the I/O fds and the netlink socket, >>> >> I would think that that is management would not be implemented in a >> fast path processing thread for an application. > > sure, but my point was that *XDP and other stack-bypass methods needs > to provide a select()able socket: when your use-case is not about just > networking, you have to snoop on changes to the control plane, and update > your data path. In the OVS case (pure networking) the OVS control plane > updates are intrinsic to OVS. For the rest of the request/response world, > we need a select()able socket set to do this elegantly (not really > possible in DPDK, for example)
Busypoll on steroids is what windows does by mapping the user space "doorbell" into a vDSO and let user space loop on that maybe with MWAIT/MONITOR. The interesting thing is that you can map other events to this notification event, too. It sounds like a usable idea to me and reassembles what we already do with futexes. Bye, Hannes
