Received: by 10.192.165.156 with SMTP id m28csp752303imm; Mon, 16 Apr 2018 08:10:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx49kwTKAuw5en5J9wHXbbTmu4bBUaLR465Wr6fMn/stLuz2hLuPW7iZKuAFp/sI0jtKcQjon X-Received: by 10.99.99.196 with SMTP id x187mr9866036pgb.154.1523891452343; Mon, 16 Apr 2018 08:10:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523891452; cv=none; d=google.com; s=arc-20160816; b=dQtyDEPv4SFtMbFqQjYIr+vaQeerSe1Ah+6fjAW8LqKZvE5zYtQJWP1wQPgtvzc4qu y3IsvDn3bfLxD7m5SDeuMIiPekZxOZoNu3kskibtjlSlLq31mCc+IyykaMaGRIGP3dqx m9TnaHFkNpDFGpaPtuSdJsovOI14/2cEQVP8R7ATg+eloOkRvz/bCx2b/gmWDfNSQNZS yZXVOo8oetVI83ve6xLn9T5CDG81vcnG1oppWP0bcHDHQEU5/aH1kPAipCMkHkiGsVBc Ro7wTT3eMOZPzMkCv2tU+qpj65xPDzcX9ROBRpqU6wO3iFBI7ufA6oJkmuf7oE/VxY9T LXHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=qJZ1xGH+y9aiNN9bayH/f213KdG/ieNqcorHjaS30BA=; b=Ue8wNFrArN2NwYmWJ1MLgcQAgQ0h6rWOvmL8f/61R2NH9+9tvx4GvTW+0selq2PpJ9 DDo/Vuneo6APcRkBUQiRPE5cXoaUTPMps+UMA3/q5j2bfBQEswvBOhkFbhJxBw8n0oXP GXCp/xO7dv0804IKZigkKgbCk3GJVbyu/UwCS+q6Rw6NCbJYieqOYc4sCjHJbv/3n5l0 mUD86hJFNa2T0tAaR3f0NmQLB9KiWkgEqybGhSAyoUdUT+lXRvcTwxL+l0zFSy8WKLDP 7sNKdoXUG1QZeu5LuXILJ3xcpLtvkDg7ripg77o6OW8WGhUlhyBqOiguhDlyEwobXvnn llfQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9-v6si3751850plp.389.2018.04.16.08.10.38; Mon, 16 Apr 2018 08:10:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752708AbeDPPI6 (ORCPT + 99 others); Mon, 16 Apr 2018 11:08:58 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:42380 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751135AbeDPPI5 (ORCPT ); Mon, 16 Apr 2018 11:08:57 -0400 Received: from localhost (pool-173-77-163-229.nycmny.fios.verizon.net [173.77.163.229]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 6D7BC14167DDC; Mon, 16 Apr 2018 08:08:56 -0700 (PDT) Date: Mon, 16 Apr 2018 11:08:55 -0400 (EDT) Message-Id: <20180416.110855.61732218036810337.davem@davemloft.net> To: rafalo@cadence.com Cc: nicolas.ferre@microchip.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] Receive Side Coalescing for macb driver From: David Miller In-Reply-To: <1523739187-20077-1-git-send-email-rafalo@cadence.com> References: <1523739187-20077-1-git-send-email-rafalo@cadence.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 16 Apr 2018 08:08:56 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafal Ozieblo Date: Sat, 14 Apr 2018 21:53:07 +0100 > This patch series adds support for receive side coalescing > for Cadence GEM driver. Receive segmentation coalescing > is a mechanism to reduce CPU overhead. This is done by > coalescing received TCP message segments together into > a single large message. This means that when the message > is complete the CPU only has to process the single header > and act upon the one data payload. You're going to have to think more deeply about enabling this feature. If you can't adjust the receive buffer offset, then the various packet header fields will be unaligned. On certain architectures this will result in unaligned traps all over the networking stack as the packet is being processed. So enabling this by default will hurt performance on such systems a lot. The whole "skb_reserve(skb, NET_IP_ALIGN)" is not just for fun, it is absolutely essential.