Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-02-26

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:39 bala joined #gluster-dev
02:44 lpabon joined #gluster-dev
02:52 vshankar joined #gluster-dev
03:30 lpabon joined #gluster-dev
03:36 anmol joined #gluster-dev
03:46 an joined #gluster-dev
03:50 mohankumar joined #gluster-dev
03:51 sgowda joined #gluster-dev
04:05 bala joined #gluster-dev
04:34 bulde joined #gluster-dev
04:37 sripathi joined #gluster-dev
04:48 hagarth joined #gluster-dev
04:55 bharata joined #gluster-dev
04:56 bharata What does "rsp" stand for or what is the significance of the term "rsp" in rsp* arguments of xlators/protocol/client/src/c‚Äčlient.c:client_submit_request ?
05:00 bulde response
05:02 bulde rsp in request means, if a response comes, and you already have the arguments given, then do the socket readv/writev to that buffer itself
05:04 bharata bulde, ok, so I guess I could use rsp_payload iovec in client_submit_request to mean(or point to) the user supplied iovec for zero copy read ?
05:05 bharata bulde, but the problem is that rpc receive section of the code doesn't seem to have visibility into this iovec (rsp_payload)
05:06 bharata bulde, basically I am trying to figure out the best/easiest way to pass user supplied buffer that could be used in the socket read side
05:06 bulde hmm, it should
05:06 bulde i guess your approach is in right direction
05:08 bharata bulde, Currently I am overwhelmed by the number of iovecs one has to deal with in the rpc code :)
05:08 bulde :-) thats the reason why we did RPC readahead
05:08 bharata bulde, s/number of iovecs/different types of iovecs/
05:08 bulde what you should be bothered is frag header
05:09 bulde mostly there will just 2, but are pointing to the same pointer by different name
05:09 bala joined #gluster-dev
05:09 bharata bulde, I am realizing that they kind of point to the same thing, but not able to clearly appreciate the reason for that
05:10 bulde ok... we tried to keep RPC decoding as segment by segment
05:10 bulde and for each segment (like auth/prog hdr/rpc hdr/ payload)
05:10 bulde we have different names for iovecs
05:10 bulde i guess while writing the code they thought its more meaningful... :p
05:11 bharata bulde, I thought I should be only bothered about the payload right since that's what holds the actual read data
05:11 bulde yes... thats right
05:12 bulde that too goto 'vectored_reply' part
05:12 bulde thats where it reads the 'READV reply'
05:12 bharata bulde, Right, so the key is to make in->pending_vector pickup or point to the "right" (aka user supplied iovec)
05:13 an joined #gluster-dev
05:13 bharata ah! s/"right"/right vecotr
05:15 deepakcs joined #gluster-dev
05:16 bulde bharata: yes
05:18 bharata bulde, If I can't do it the right way, I will do some hacks initially just to measure the performance gain we get by doing zero copy
05:32 bulde bharata: i guess thats the best approach IMO
05:32 bulde gives us an understanding of perf numbers and then we can think of CLEAN approach
05:33 bulde that even means, we may have to refactor the code which is already present
05:38 bharata bulde, right
05:38 bharata bulde, very complicated code in rpc, difficult to follow :)
05:48 sahina joined #gluster-dev
05:49 sripathi joined #gluster-dev
06:25 sripathi1 joined #gluster-dev
06:31 sripathi joined #gluster-dev
07:12 hagarth bharata: yeah, worth re-factoring it at some point of time
07:34 aravindavk joined #gluster-dev
07:51 nixpanic joined #gluster-dev
08:14 bulde johnmark: around?
08:40 hagarth joined #gluster-dev
08:52 gbrand_ joined #gluster-dev
10:05 hagarth joined #gluster-dev
10:56 an joined #gluster-dev
11:07 an joined #gluster-dev
11:44 sahina joined #gluster-dev
11:53 edward1 joined #gluster-dev
11:59 jdarcy joined #gluster-dev
12:03 hagarth Hi Jeff
12:03 jdarcy Good morning.
12:04 hagarth Good morning. I don't think we have got anybody else for the meeting today.
12:05 jdarcy Do you think it makes sense to get those last four patches reviewed and then make one last alpha?
12:06 jdarcy I guess KP's syncop change should be on that list too.
12:06 hagarth yeah, we would need that too.
12:07 hagarth Yeah, we will need to get a few backports from the alpha blocker to release-3.4
12:07 hagarth *from the alpha blocker list
12:09 hagarth how about targeting another alpha for this thursday?
12:09 jdarcy That sounds pretty good.
12:10 hagarth Okay, let us work towards that. We can initiate separate threads with original submitters for backports.
12:15 jdarcy Short meeting, huh?
12:15 jdarcy :)
12:17 hagarth yeah :)
12:18 hagarth let us send out an email on that thread and inform everybody about the thursday schedule.
12:21 jdarcy OK.
12:26 an joined #gluster-dev
12:56 mohankumar joined #gluster-dev
13:17 jdarcy joined #gluster-dev
13:24 jdarcy joined #gluster-dev
13:31 johnmark hagarth_: heya. Thursday schedule?
14:09 jdarcy_ joined #gluster-dev
14:13 mohankumar joined #gluster-dev
14:27 vshankar joined #gluster-dev
14:32 hagarth joined #gluster-dev
14:54 lpabon joined #gluster-dev
15:12 wushudoin joined #gluster-dev
15:15 jdarcy joined #gluster-dev
16:00 lpabon joined #gluster-dev
16:03 bala joined #gluster-dev
16:05 sghosh joined #gluster-dev
16:37 hagarth joined #gluster-dev
18:04 portante joined #gluster-dev
19:14 puebele joined #gluster-dev
19:30 hagarth joined #gluster-dev
20:06 lpabon joined #gluster-dev
20:07 lpabon joined #gluster-dev
21:17 lpabon joined #gluster-dev
21:23 lpabon_ joined #gluster-dev
22:09 foster joined #gluster-dev
22:45 jdarcy joined #gluster-dev
22:53 jdarcy joined #gluster-dev
23:43 hagarth joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary