<font color="#3333ff"><font size="2"><font face="times new roman,serif">Hi Alexey,<br><br>That surely helps.Thanks for all the help till now.<br><br clear="all"></font></font></font><font style="color: rgb(51, 51, 255);" size="2" color="#3333ff"><font face="'times new roman', serif">Thanks,<br>
Vilobh<br>
</font></font><i><font style="color: rgb(51, 51, 255);" size="2">Graduate Research Associate<br>Department of Computer Science<br>The Ohio State University Columbus Ohio</font></i><br>
<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 11:45 AM, Alexey Lyashkov <span dir="ltr"><<a href="mailto:alexey.lyashkov@clusterstor.com">alexey.lyashkov@clusterstor.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;">Hi Vilobh,<div><br></div><div>interop == interoperability between nodes with different version of software.</div><div><br></div><div>in general we have two ways to solve that - for requests with mdc_body - you can set flag in body and analyze that flag in server/client side.</div>
<div>if you want add new operation - better way add new flag into connect_data (look to OBD_CONNECT_* macroses handling)</div><div>that flag can checked via export->connect_flags on client or server side for remote side features.</div>
<div>as example 1.x and 2.0 have a different format for setattr requests :</div><div>int mdc_setattr</div><div>...</div><div><div> if (mdc_exp_is_2_0_server(exp)) { </div>
<div> size[REQ_REC_OFF] = sizeof(struct mdt_rec_setattr); </div><div> size[REQ_REC_OFF + 1] = 0; /* capa */ </div><div>
size[REQ_REC_OFF + 2] = 0; //sizeof (struct mdt_epoch); </div><div> size[REQ_REC_OFF + 3] = ealen; </div><div> size[REQ_REC_OFF + 4] = ea2len; </div>
<div> size[REQ_REC_OFF + 5] = sizeof(struct ldlm_request); </div><div> offset = REQ_REC_OFF + 5; </div><div>
bufcount = 6; </div><div> replybufcount = 6; </div><div> } else { </div>
<div> bufcount = 4; </div><div> } </div><div>
</div></div><div>example of client features are checking version based recovery support for client </div><div>mds_version_get_check</div><div>...</div><div><div> if (inode == NULL || !exp_connect_vbr(req->rq_export)) </div>
</div><div><br></div><div><br></div><div>I hope that help you.</div><div><div></div><div class="h5"><div><br></div><div><br><div><div>On Oct 14, 2010, at 18:29, Vilobh Meshram wrote:</div><br><blockquote type="cite"><font color="#3333ff"><font size="2"><font face="times new roman,serif">Hi Alexey,<br>
<br>Thanks again for the reply.<br><br>Can you briefly give me some pointers about this interop issue and in which kind of RPC should this issue arise ? How should we resolve this what kind of flag needs to be set in ?<br>
<br>I went through the bugzilla entry mentioned by you it seems like for RPCs dealing with LDLM may cause this issue.Please correct me if I am wrong.<br><br clear="all"></font></font></font><font style="color: rgb(51, 51, 255);" size="2" color="#3333ff"><font face="'times new roman', serif">Thanks,<br>
Vilobh<br>
</font></font><i><font style="color: rgb(51, 51, 255);" size="2">Graduate Research Associate<br>Department of Computer Science<br>The Ohio State University Columbus Ohio</font></i><br>
<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 11:10 AM, Alexey Lyashkov <span dir="ltr"><<a href="mailto:alexey.lyashkov@clusterstor.com" target="_blank">alexey.lyashkov@clusterstor.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;">Hi Vilobh,<div><br></div><div>as i see, you touched code related to locking. struct ldm_request used to lock enqueue process - that why i say about interop issue in ELC code, which solved with export flag.</div>
<div>for common mdc requests you can resolve interop issue with flags in mdc_body (mdt_body), but that not possible for ldlm requests.</div><div><div></div><div><div> </div><div><br><div><div>On Oct 14, 2010, at 18:04, Vilobh Meshram wrote:</div>
<br><blockquote type="cite"><font color="#3333ff"><font size="2"><font face="times new roman,serif">Hi Alexey,<br>
<br>
Thanks again for your reply.<br>
<br>
I am trying to embed a buffer in the RPC which will get filled in with some values which MDS is aware of which the client calling the RPC is not aware <a href="http://of.It/" target="_blank">of.It</a> has nothing to do with locking.I just want to fill in the buffer which I embedd in the RPC with some suitable data from the MDS end and then do operations on that data at the client side.So I think the approach suggested by you and Nicholas of just including the sizeof(str) [the size of the expected information from the MDS] in the size[] array should be fine as done below :-<br>
<br><br><br></font></font></font><font face="'times new roman', serif"><font color="#3333ff">__u32 size[2] = { [MSG_PTLRPC_BODY_OFF] = sizeof(struct ptlrpc_body),</font></font>
<div><font face="'times new roman', serif"><font color="#3333ff"> [DLM_LOCKREQ_OFF] = sizeof(struct ldlm_request) };</font></font></div>
<div><font face="'times new roman', serif"><font color="#3333ff"><br></font></font></div><div><font face="'times new roman', serif"><font color="#3333ff">---->> </font></font></div>
<div><font face="'times new roman', serif"><font color="#3333ff"> __u32 size[3] = { [MSG_PTLRPC_BODY_OFF] = sizeof(struct ptlrpc_body),</font></font></div><div>
<font face="'times new roman', serif"><font color="#3333ff"> [DLM_LOCKREQ_OFF] = sizeof(struct ldlm_request) ,</font></font></div>
<div><font face="'times new roman', serif"><font color="#3333ff">
//how to add "char *str=Hello" ofcourse we
will have sizeof(str) but how to choose the MACRO like </font></font><span style="font-family: 'times new roman',serif; color: rgb(51, 51, 255);">DLM_LOCKREQ_OFF bcz for a specific kind of RPC there are limited number of such MACROS</span></div>
<font color="#3333ff"><font size="2"><font face="times new roman,serif"> <br><br><b>Please correct me if I am wrong or please guide me if I need to consider few corner cases to handle this use case.<br><br></b>Thanks again.<br>
<br clear="all"></font></font></font><font style="color: rgb(51, 51, 255);" size="2" color="#3333ff"><font face="'times new roman', serif">Thanks,<br>Vilobh<br>
</font></font><i><font style="color: rgb(51, 51, 255);" size="2">Graduate Research Associate<br>Department of Computer Science<br>The Ohio State University Columbus Ohio</font></i><br>
<br clear="all"><font style="color: rgb(51, 51, 255);" size="2" color="#3333ff"><font face="'times new roman', serif"></font></font><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 10:40 AM, Alexey Lyashkov <span dir="ltr"><<a href="mailto:alexey.lyashkov@clusterstor.com" target="_blank">alexey.lyashkov@clusterstor.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andreas,<br>
<div><br>
On Oct 14, 2010, at 17:31, Andreas Dilger wrote:<br>
<br>
> On 2010-10-13, at 23:18, Nicolas Williams wrote:<br>
>> On Thu, Oct 14, 2010 at 06:38:16AM +0300, Alexey Lyashkov wrote:<br>
>>> On Oct 14, 2010, at 03:28, Nicolas Williams wrote:<br>
>>>> Yes, it's possible to add buffers to requests. It's not possible to add<br>
>>>> buffers to _replies_ to existing RPCs unless you know the client expects<br>
>>>> those additional buffers -- existing clients expect a given maxsize for<br>
>>>> each reply, and if your reply is bigger then it will get dropped.<br>
>>> It is wrong for last ~1year.<br>
>>> ~1year ago i add code to ptlrpc layer which a adjust buffer for reply, and resend a request.<br>
>><br>
>> Ah, I didn't know that was in 1.8. Are there interop issues (with older<br>
>> clients) though with sending larger replies than expected?<br>
><br>
> Nico, it has always been possible in the past to increase the size of any buffer in a request, or in a reply (if the total reply size will fit into the pre-allocated reply buffer). An older peer would just ignore the bytes beyond the known part of the buffer.<br>
><br>
</div>I think that question don't about rebalance buffers size in message,<br>
i think that sending large reply in smaller reply buffer.<br>
LNet don't able to put large reply to small buffer (without truncate flag, which is not exist in older ptlrpc version).<br>
without that flag you will see messages<br>
>><br>
CERROR("Matching packet from %s, match "LPU64<br>
" length %d too big: %d left, %d allowed\n",<br>
libcfs_id2str(src), match_bits, rlength,<br>
md->md_length - offset, mlength);<br>
>><br>
and LNet will drop message without notify PtlRPC.<br>
<div><br>
<br>
> Is that not true with the 2.x RPC handling?<br>
><br>
</div>2.x able to rebalance space between buffers (but looks by hand), and able adjust reply buffer after truncated reply.<br>
<div><div></div><div><br>
<br>
<br>
--------------------------------------<br>
Alexey Lyashkov<br>
<a href="mailto:alexey.lyashkov@clusterstor.com" target="_blank">alexey.lyashkov@clusterstor.com</a><br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br>