From patchwork Fri Nov 23 12:40:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Dryomov X-Patchwork-Id: 10695749 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8F8DC175A for ; Fri, 23 Nov 2018 12:40:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 80A2F2C013 for ; Fri, 23 Nov 2018 12:40:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7515C2C080; Fri, 23 Nov 2018 12:40:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 13D502C057 for ; Fri, 23 Nov 2018 12:40:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409863AbeKWXYo (ORCPT ); Fri, 23 Nov 2018 18:24:44 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:45788 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2409857AbeKWXYn (ORCPT ); Fri, 23 Nov 2018 18:24:43 -0500 Received: by mail-wr1-f68.google.com with SMTP id v6so12198226wrr.12 for ; Fri, 23 Nov 2018 04:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=RasxTOW8z8b2iOFHaISwLWQ0ieYMTTVtj45gAbBESWs=; b=ZX9KoSIFemTpbLYbPd12eqmqEn4fG12gEsO3Q5aiA3+JDD9XwBR0EaRA6t1lwUc64s WnU8OjDVGmF131uqO5P52aDpP9p4YoMoxu87geh/op4XdkkrbflIhZdrBVPYpdHp0nDZ iO2ml+Qd2k6vd9nOj2knTKwOfYKv92vOpmKwU0ng8FZ/6pssVLTwgz6/ryZ9DiW2/6QE SlwMKrgyxBG3PC5isnuPARWd2R1V7g7mQsU+vG9ku5ub0VtiiSnQJyme60No7z0f66Gf E/7kStEFOAraXgI18232UTcPovddfp4E0DQxnomlwZ32Vkgaw+5qKCUs/znDqFHgc3Mg puIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=RasxTOW8z8b2iOFHaISwLWQ0ieYMTTVtj45gAbBESWs=; b=cLg7Haxw/gFfjYThBoF9gMwx4YJPZxl1mDAUQO4hVS4CIP92F8K4tfC52Y1JhNRHNY MPqk29lUZwt9l118w1bahYirLEPYPi7mEIvHCvy6lZDjTiXfAFg10+xVKad3xus064Mh KSXNmuMXDQIjBhEHT02FpC4AequlykWh2nAizlyv1wKCPJs+TPRZ8CTsFphNvB2ykxyi av2aziDGEkAN3KsI9yZmejx+Yo8W8TXUKVo3Tl8TZ44iK7CuG7It7AMjKkZDbTXUPxQz OfU8d5cdiJ0RoUvvKddaQTtTEcul45ZZ7qYqbs5L+greqfi5+gx114rGHwWfMCdygpgN MsgA== X-Gm-Message-State: AA+aEWbCc6Howe4wE6JrhUL8Y7uPPd+y/30XD10D+CD+rzvcTmPmcEMQ jOa4jx2dlToZZIT0h5vXsPftQ53v X-Google-Smtp-Source: AFSGD/UCWL1FTlFZNtA7Fz1sdJnWQdIBhCPSTaFGmWg0IMz7J0XFKOLnQ31dQsIaj+qBCIAZJWdjFQ== X-Received: by 2002:a5d:6302:: with SMTP id i2mr11746890wru.14.1542976839202; Fri, 23 Nov 2018 04:40:39 -0800 (PST) Received: from orange.local (ip-94-112-136-201.net.upcbroadband.cz. [94.112.136.201]) by smtp.gmail.com with ESMTPSA id l3sm31077857wru.36.2018.11.23.04.40.38 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Nov 2018 04:40:38 -0800 (PST) From: Ilya Dryomov To: ceph-devel@vger.kernel.org Subject: [PATCH 1/4] libceph: drop last_piece logic from write_partial_message_data() Date: Fri, 23 Nov 2018 13:40:17 +0100 Message-Id: <20181123124020.4637-2-idryomov@gmail.com> X-Mailer: git-send-email 2.14.4 In-Reply-To: <20181123124020.4637-1-idryomov@gmail.com> References: <20181123124020.4637-1-idryomov@gmail.com> Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP last_piece is for the last piece in the current data item, not in the entire data payload of the message. This is harmful for messages with multiple data items. On top of that, we don't need to signal the end of a data payload either because it is always followed by a footer. We used to signal "more" unconditionally, until commit fe38a2b67bc6 ("libceph: start defining message data cursor"). Part of a large series, it introduced cursor->last_piece and also mistakenly inverted the hint by passing last_piece for "more". This was corrected with commit c2cfa1940097 ("libceph: Fix ceph_tcp_sendpage()'s more boolean usage"). As it is, last_piece is not helping at all: because Nagle algorithm is disabled, for a simple message with two 512-byte data items we end up emitting three packets: front + first data item, second data item and footer. Go back to the original pre-fe38a2b67bc6 behavior -- a single packet in most cases. Signed-off-by: Ilya Dryomov --- net/ceph/messenger.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c index 2f126eff275d..cca96d32ac64 100644 --- a/net/ceph/messenger.c +++ b/net/ceph/messenger.c @@ -1592,7 +1592,6 @@ static int write_partial_message_data(struct ceph_connection *con) struct page *page; size_t page_offset; size_t length; - bool last_piece; int ret; if (!cursor->resid) { @@ -1600,10 +1599,9 @@ static int write_partial_message_data(struct ceph_connection *con) continue; } - page = ceph_msg_data_next(cursor, &page_offset, &length, - &last_piece); - ret = ceph_tcp_sendpage(con->sock, page, page_offset, - length, !last_piece); + page = ceph_msg_data_next(cursor, &page_offset, &length, NULL); + ret = ceph_tcp_sendpage(con->sock, page, page_offset, length, + true); if (ret <= 0) { if (do_datacrc) msg->footer.data_crc = cpu_to_le32(crc);