From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id CC1E46FC8F; Fri, 16 Apr 2021 02:19:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CC1E46FC8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618528766; bh=sasf7NlEtdnuzgCdoAQFtwHOmYNRgOCSIVh0QajV1/g=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=TP0dvoHL3fFPoG4uE+LGKohsli+tTb/v2c+szM33tRq84i4JICawfYh0WqCh4VjJJ G2T4uTzUfsYUU81pKhuBjBREkPt1eBKD6tk/TXxGJXnLQaNYIpEXKDmtmAxYLbhZ/T t2CtMlFGKzaZbquuRSuivKI8gMeV3qjb0isS/68Y= Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 864816FC8F for ; Fri, 16 Apr 2021 02:19:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 864816FC8F Received: by smtp50.i.mail.ru with esmtpa (envelope-from ) id 1lXBGe-000485-Uo; Fri, 16 Apr 2021 02:19:25 +0300 To: Serge Petrenko , gorcunov@gmail.com Cc: tarantool-patches@dev.tarantool.org References: <78fd722e0cd1e6edcdd8e081c7e40a5d0bcf7ec7.1618409665.git.sergepetrenko@tarantool.org> Message-ID: <704d7361-d27e-9fb5-0957-487af57b4628@tarantool.org> Date: Fri, 16 Apr 2021 01:19:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <78fd722e0cd1e6edcdd8e081c7e40a5d0bcf7ec7.1618409665.git.sergepetrenko@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E7480B1C8842CE613979723F2FB4628545A35182A05F538085040099AE312ECBC69E33883F696E9AF430848122D00730D05C2C8EDE7FFC371EDBF X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE78BAADB77C21FF6F2EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AF78C68CB7D402738638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2BD393A5E64B4C36CF3E2FD66E7E409831DC1F2ED7A42611AD2E47CDBA5A96583C09775C1D3CA48CFED8438A78DFE0A9E117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE74A95F4E53E8DCE969FA2833FD35BB23DF004C90652538430302FCEF25BFAB3454AD6D5ED66289B5278DA827A17800CE703683914FDCF891BD32BA5DBAC0009BE395957E7521B51C20BC6067A898B09E4090A508E0FED6299176DF2183F8FC7C0140F7C78AFD19228CD04E86FAF290E2D7E9C4E3C761E06A71DD303D21008E298D5E8D9A59859A8B6B372FE9A2E580EFC725E5C173C3A84C34B08FA16E56A400835872C767BF85DA2F004C90652538430E4A6367B16DE6309 X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2368A440D3B0F6089093C9A16E5BC824A2A04A2ABAA09D25379311020FFC8D4AD6C30AE2B5E62355B70653F46ACEF1176 X-C1DE0DAB: 0D63561A33F958A5C53801F10DDE1651322DCD2266BA11D582C595176F51343DD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D347215713CF3EEE9D1F3AD786E8097A79FF7CB1FFA359B7770863C9BF105F03B929054525DDAEDED3E1D7E09C32AA3244CD7E26DB1BBC88CF97BBE436337592F29C3B3ADDA61883BB5FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj3S6P1v0GIqQBBuXcI6kKGw== X-Mailru-Sender: 504CC1E875BF3E7D9BC0E5172ADA3110415A4DEC7DEADBE5E38E512E14967F8C668D67891A60A96D07784C02288277CA03E0582D3806FB6A5317862B1921BA260ED6CFD6382C13A6112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v3 02/10] xrow: introduce a PROMOTE entry X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" I appreciate the work you did here! See 2 comments below. > diff --git a/src/box/xrow.c b/src/box/xrow.c > index cc8e43ed4..5d515ce92 100644 > --- a/src/box/xrow.c > +++ b/src/box/xrow.c > @@ -884,28 +884,63 @@ xrow_encode_dml(const struct request *request, struct region *region, > return iovcnt; > } > > -void > -xrow_encode_synchro(struct xrow_header *row, > - struct synchro_body_bin *body, > - const struct synchro_request *req) > +static void > +xrow_encode_synchro_body(struct synchro_body_bin *body, > + const struct synchro_request *req) > { > /* > - * A map with two elements. We don't compress > + * A map with two or three elements. We don't compress > * numbers to have this structure constant in size, > * which allows us to preallocate it on stack. > */ > - body->m_body = 0x80 | 2; > + body->m_body = 0x80 | (req->type == IPROTO_PROMOTE ? 3 : 2); > body->k_replica_id = IPROTO_REPLICA_ID; > body->m_replica_id = 0xce; > body->v_replica_id = mp_bswap_u32(req->replica_id); > body->k_lsn = IPROTO_LSN; > body->m_lsn = 0xcf; > body->v_lsn = mp_bswap_u64(req->lsn); > +} > + > +void > +xrow_encode_synchro(struct xrow_header *row, > + struct synchro_body_bin *body, > + const struct synchro_request *req) > +{ > + assert(req->type == IPROTO_CONFIRM || req->type == IPROTO_ROLLBACK); > + > + xrow_encode_synchro_body(body, req); > > memset(row, 0, sizeof(*row)); > + row->type = req->type; > + row->body[0].iov_base = body; > + row->body[0].iov_len = sizeof(*body); > + row->bodycnt = 1; > +} > + > +static inline void > +xrow_encode_promote_body(struct promote_body_bin *body, > + const struct synchro_request *req) 1. I would propose to inline it. It is used in a single place, and now it looks like if we would have more than 1 place where we would need the promote body. But more interestingly, it looks you could keep it a single function xrow_encode_synchro. Although we wouldn't be able to have a PACKED struct with predefined fields. Not a big deal anyway. The reasoning is similar to xrow_encode_dml(). It also uses a single struct request for all kinds of DML, and conditionally encodes the non-zero fields. I think your case is the same. It would simplify some code, and remove branching from other places. For example, from txn_limbo_write_synchro(), where you branch between PROMOTE and non-PROMOTE when decide what to encode. We even had the same issue when tried to encode CONFIRM and ROLLBACK via separate functions. > +{ > + xrow_encode_synchro_body(&body->base, req); > + > + body->k_term = IPROTO_TERM; > + body->m_term = 0xcf; > + body->v_term = mp_bswap_u64(req->term); > +} > + > > +void > +xrow_encode_promote(struct xrow_header *row, struct promote_body_bin *body, > + const struct synchro_request *req) > +{ > + assert(req->type == IPROTO_PROMOTE); > + > + xrow_encode_promote_body(body, req); > + > + memset(row, 0, sizeof(*row)); > row->type = req->type; > - row->body[0].iov_base = (void *)body; > + row->body[0].iov_base = body; 2. Unnecessary change. But I don't mind, up to you. > row->body[0].iov_len = sizeof(*body); > row->bodycnt = 1; > }