On Thu, 15 Dec 2016, Jesper Dangaard Brouer wrote: > > It sounds like Christoph's RDMA approach might be the way to go. > > I'm getting more and more fond of Christoph's RDMA approach. I do > think we will end-up with something close to that approach. I just > wanted to get review on my idea first. > > IMHO the major blocker for the RDMA approach is not HW filters > themselves, but a common API that applications can call to register > what goes into the HW queues in the driver. I suspect it will be a > long project agreeing between vendors. And agreeing on semantics. Some of the methods from the RDMA subsystem (like queue pairs, the various queues etc) could be extracted and used here. Multiple vendors already support these features and some devices operate both in an RDMA and a network stack mode. Having that all supported by the networks stack would reduce overhead for those vendors. Multiple new vendors are coming up in the RDMA subsystem because the regular network stack does not have the right performance for high speed networking. I would rather see them have a way to get that functionality from the regular network stack. Please add some extensions so that the RDMA style I/O can be made to work. Even the hardware of the new NICs is already prepared to work with the data structures of the RDMA subsystem. That provides an area of standardization where we could hook into but do that properly and in a nice way in the context of main stream network support. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>