> > Point is others have looked at the code. No issues have been called out to > date as to why what is there won't work for everyone. > http://marc.info/?l=linux-rdma&m=144968107508268&w=2 Your answer to the send() issue is first an agreement with the comment and later says that it can't be done because of how PIO and SDMA (Intel specific implementation) This is an example for a discussion that never ended with an agreement. > > Yes it is specific to Intel *now*, that doesn't mean it should stay that > way. Rdmavt could, and in my opinion should, be extended to support > soft-roce. I don't think replicating the same thing is a great idea. > But you post *now* a so called generic driver so it must now fit any possible driver (including Soft RoCE) > As to the location, where do you think it should go. drivers/infiniband/sw > makes the most sense to me, but open to suggestions. > > And for the question of why publish when it's not ready, the better question > is why not? Is it not good to see the work in progress as it evolves so the > community can provide feedback? > What kind of a feedback you expect when I don't have an idea about your plans for rdmavt Interfaces, flows, data structures... all is missing from the documentation to rdmavt. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
