David> Roland, there is no way in the world we would have let
David> support for RDMA into the kernel tree had we seen and
David> reviewed it on netdev. I've discussed this with Andrew
David> Morton, and we'd like you to please revert all of the RDMA
David> code from Linus's tree immedialtely.
David> Folks are well aware how against RDMA and TOE type schemes
David> the Linux networking developers are. So the fact that none
David> of these RDMA changes went up for review on netdev strikes
David> me as just a little bit more than suspicious.
[I'm really on paternity leave, but this was brought to my attention
and seems important enough to respond to]
Dave, you're going to have to be more specific. What do you mean by
RDMA? The whole drivers/infiniband infrastructure, which handles RDMA
over IB, has been upstream for a year and a half, and was in fact
originally merged by you, so I'm guessing that's not what you mean.
If you're talking about the "RDMA CM" (drivers/infiniband/core/cma.c
et al) that was just merged, then you should be aware that that was
posted by Sean Hefty to netdev for review, multiple times (eg a quick
search finds <http://lwn.net/Articles/170202/>). It is true that the
intention of the abstraction is to provide a common mechanism for
handling IB and iWARP (RDMA/TCP) connections, but at the moment no
iWARP code is upstream. Right now all it does is allow IP addressing
to be used for IB connections.
In any case I think we need to find a way for Linux to support iWARP
hardware, since there are users that want this, and (some of) the
vendors are working hard to do things the right way (including cc'ing
netdev on the conversation). I don't think it's good for Linux for
the answer to just be, "sorry, you're wrong to want to use that hardware."
- Roland
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
