<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 7, 2013 at 5:32 AM, Yufei Ren <span dir="ltr"><<a href="mailto:yufei.ren@stonybrook.edu" target="_blank">yufei.ren@stonybrook.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">On Fri, Dec 6, 2013 at 7:04 AM, jagadeesh kumar<br>
<<a href="mailto:jagadeesh414.ece@gmail.com">jagadeesh414.ece@gmail.com</a>> wrote:<br>
</div><div class="im HOEnZb">> Hi all,<br>
><br>
>        I am learning RDMA_WRITE operation using OFED Verbs(Kernel space).<br>
> As RDMA_WRITE operation will not generate completion entry on Responder<br>
> side,<br>
> I am following the technique like polling on the last byte of receive<br>
> buffer.<br>
><br>
> Steps i followed are:<br>
> 1. kmalloc is used for memory allocation,<br>
> 2. ib_reg_phys_mr is used for memory registration,<br>
> 3. RDMA WRITE is requested on initiator side and the completion entry is<br>
> success,<br>
> 4. Responder is polling on last byte of receive buffer to be set,<br>
> but Responder is not able to find the buffer updation and stuck in infinite<br>
> loop.<br>
><br>
> Please help me in solving the above mentioned problem. Let me know if<br>
> something is missed.<br>
><br>
<br>
</div><div class="im HOEnZb">The `last byte' in your responder is cached in a CPU cache line and<br>
your responder is checking this CPU cached `last byte'. Because<br>
RDMA_WRITE is CPU bypass, the CPU in your responder is not aware of<br>
the modified memory status, thus it still keeps checking the outdated<br>
CPU cache line even though this `last byte' in memory is actually<br>
already updated. Therefore, your responder is busy-waiting there.<br></div></blockquote><div><br></div><div>Thanks Yufei, for your reply.<br><br></div><div>     When  i used last byte polling approach using uverbs it works fine,  <br>
where as in using kernel verbs above mentioned problem is seen. <br>Can you please share some information on, How user space is not facing the problem of CPU caching ? <br>and how it is managed ?<br><br></div><div>Thanks & Regards <br>
</div><div>Jagadeesh.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im HOEnZb">
<br>
BTW, it seems your approach is wasting CPU cycles on checking the<br>
`last byte'. Your might be interested in RDMA write with immediate<br>
data.<br>
<a href="https://oss.oracle.com/pipermail/rds-devel/2007-November/000208.html" target="_blank">https://oss.oracle.com/pipermail/rds-devel/2007-November/000208.html</a><br>
quote:<br>
"Generally, rdma operations do not provide a notification to the remote<br>
host when they complete. It is possible to setup for notification -<br>
using IB native "immediate" data (4 bytes) for example - but the data<br>
size is limited."<br>
<br>
<br>
Thanks<br>
Yufei<br>
<br>
<br>
</div><div class="im HOEnZb">>      The same approach i.e. polling on last byte of receive buffer works for<br>
> me in<br>
> user space(uverbs) RDMA_WRITE operation.<br>
><br>
> My host machine is running Linux kernel 2.6.18.<br>
><br>
> Any reference or web links will be useful.<br>
><br>
> Thanks & Regards<br>
> Jagadeesh.<br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.openfabrics.org">Users@lists.openfabrics.org</a><br>
> <a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
</div></div></blockquote></div><br></div></div>