RE: Question about Transaction::get_data_alignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sage,

       I think I have make a draft of this patch, could you pls kindly take a review at https://github.com/xiaoxichen/ceph/commit/983a36be52d4ddd17133979c17b25e9e319a5dad ?

      By "streamline the encode path for these messages", do you mean we can do something like below so we can skip the initialize of some fields?
     
               MOSDClientSubOp(ALL_ARGS_NEED_TO_SEND)
    : Message(MSG_OSD_CLIENT_SUBOP, HEAD_VERSION, COMPAT_VERSION)
    {
              encode_payload(uint64_t features, ALL_ARGS_NEED_TO_SEND) ;
    }

													Xiaoxi

-----Original Message-----
From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil
Sent: Friday, November 21, 2014 9:33 AM
To: Chen, Xiaoxi
Cc: jianpeng; ceph-devel@xxxxxxxxxxxxxxx; Cook, Nigel
Subject: RE: Question about Transaction::get_data_alignment

On Fri, 21 Nov 2014, Chen, Xiaoxi wrote:
> Hi,
>       I have cleanup the MOSDClientSubOP and changed the issue_op. The receive side is still wip. Sorry for the slow progress since blocked by a customer support case for some weeks. 
>      Here is the brunch to see if I goes on the right path.
>      
> https://github.com/xiaoxichen/ceph/commit/621c2a7dc2bc9724e9d2106b52aa
> 9eedd2c793e8

Yep, this looks like the right direction!

Once the reply path is in place, I think there are some things we can do to streamline the encode path for these messages (by, e.g., passing everything to the constructor and encoding directly there instead of copying into member variables and then encoding).  Let's start with something simple first, though.

Thanks-
sage

 > 
> -----Original Message-----
> From: Sage Weil [mailto:sage@xxxxxxxxxxxx]
> Sent: Friday, November 21, 2014 1:30 AM
> To: Chen, Xiaoxi
> Cc: jianpeng; ceph-devel@xxxxxxxxxxxxxxx; Cook, Nigel
> Subject: RE: Question about Transaction::get_data_alignment
> 
> Hi Xiaoxi,
> 
> Just wanted to touch base and see how things are going here.  I have some time to spend on this and the related efforts so please let me know if you have any questions or if you have some work-in-progress code I can help review.
> 
> Thanks!
> sage
> 
> 
> On Thu, 6 Nov 2014, Chen, Xiaoxi wrote:
> 
> > Hi Sage,
> >      As discussed with Jianpeng, I would like to take this job.
> >     Thank you.
> > 				Xiaoxi
> > 
> > -----Original Message-----
> > From: ceph-devel-owner@xxxxxxxxxxxxxxx 
> > [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil
> > Sent: Wednesday, November 5, 2014 9:20 PM
> > To: jianpeng
> > Cc: ceph-devel@xxxxxxxxxxxxxxx
> > Subject: Re: Question about Transaction::get_data_alignment
> > 
> > On Wed, 5 Nov 2014, jianpeng wrote:
> > > Dong Yuan <yuandong <at> unitedstack.com> writes:
> > > 
> > > > 
> > > > Hi Sage,
> > > > 
> > > > I am now working with the BP osd: update Transaction encoding, 
> > > > but the Transaction::get_data_alignment make me confused.
> > > > 
> > > > This method give the alignment which is used by FileJournal to 
> > > > do better buffer build. It calculate the alignment by 
> > > > largest_data_off and get_data_offset() while the first is an 
> > > > offset of some object and the second is an offset of the 
> > > > transaction encode result. I am not sure there is any reason to do calculation between them.
> > > > 
> > > > The code works fine, probably because any result is fine for 
> > > > Transaction::get_data_alignment, while 
> > > > FileJournal::prepare_single_write can use any alignment value to 
> > > > build logical bufferlist.
> > > > 
> > > > Can you give me some explanation?  Thank you.
> > > > 
> > > 
> > > Hi, i send a pull request to reduce the memcopy cause by unalignment.
> > > https://github.com/ceph/ceph/pull/2803
> > > I think get_data_offset() should not care largest_data_off.
> > 
> > I finally got to testing this and it looks good.  Pulled the patches manually into master.  Sorry it took so long!
> > 
> > For the last two MOSDSubOp, I think those changes should be done as 
> > part of this ticket
> > 
> > 	http://tracker.ceph.com/issues/9961
> > 
> > which will replace the common client replication op to use a fresh message type that is properly optimized.  Jianpeng, is this something you might be interested in working on?  We talked with Haomai about it during CDS but I think he and Yuan Dong will be occupied with the ObjectStore::Transaction encoding first, and I would really like to see this done in time for hammer (jan 1f freeze).
> > 
> > Thanks!
> > sage
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" 
> > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" 
> > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> > 
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" 
> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux