On Thu, 2018-01-18 at 11:10 -0500, Sowmini Varadhan wrote: > On (01/18/18 07:54), Eric Dumazet wrote: > > > > Some applications out there would break horribly, trust me. > > > > so I'm not particularly attached to that solution, and I appreciate > the wisdom (and the NACK), but lets try to find a useful alternative > > The current zcopy completion notification mechanism involves syscall > overhead already, and is also inadequate for threaded applications sharing > an fd. Plus it wont work for datagram sockets. > > I'm fine with Willem's suggestion of passing a fixed number of cookies > as ancillary data (with CTRUNC to denote inadequate buffer) but if we > are really so thrifty about syscall overhead, we should not be using > sk_error_queue in the first place- perhaps we can pass up the completion > notification as ancillary data with recvmsg() on the POLLIN channel > itself (which is weird if there is no data to recv, and only ancillary > info to pass up, but hey, we are "performant"!).
The thing is : MSG_PEEK 'support' will also need SO_PEEK_OFF support. And begins the crazy stuff. So lets properly design things, and not re-use legacy stuff that is proven to be not multi-thread ready and too complex. If you want to design a new channel of communication, do it, and maintain it.
