On Wed, Dec 16, 2015 at 04:37:39PM +0200, Sagi Grimberg wrote:
This patch exists to provide parity for what is in qib. Should we not
have it? If not, why do we have:
commit 38071a461f0a ("IB/qib: Support the new memory registration API")
That was done by me because I saw this in qib and assumed that it was
supported. Now that I found out that it isn't, I'd say it should be
removed altogether shouldn't it?
I am not opposed to leaving the code in rdmavt. It gets removed from qib in
the other patch series I posted. My preference is to leave it in rdmavt
since it will be needed down the road. However I can go either way here, its
easy to add back later.
That doesn't mean it can't be added to rdmavt as a future enhancement
though if there is a need.
Well, given that we're trying to consolidate on post send registration
interface it's kind of a must I'd say.
Are you asking because soft-roce will need it?
I was asking in general, but in specific soft-roce as a consumer will
need to support that yes.
I think it makes sense to revisit when soft-roce comes in,
I agree.
since qib/hfi do not need IB_WR_LOCAL_INV.
Can you explain? Does qib/hfi have a magic way to invalidate memory
regions?
Hfi1 does not currently have any support for memory registration in its post
send. Qib had the "old FRWR API" support in post_send, which you removed
since according to the commit message, is not used anymore.
I suppose a follow on patch to your "new memory registration API" patch
would be needed to add the invalidate. This is the piece I think can be
added later in rdmavt.
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
