From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAF70C2BA80 for ; Mon, 6 Apr 2020 14:48:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A18A12415B for ; Mon, 6 Apr 2020 14:48:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="uenn7vmk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728747AbgDFOsd (ORCPT ); Mon, 6 Apr 2020 10:48:33 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:50916 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728697AbgDFOsc (ORCPT ); Mon, 6 Apr 2020 10:48:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jndYh7GlwNS3Suqwh3rj4zu5D8kBRWnhUuUbjJc1gaY=; b=uenn7vmk6Yn/aMdzsb5yOlZEQg lmUvAB9L8kZcEAW7MJWAVVXcYp1+GBAIwLi8LhwAV/FaBpePG5WM97NOX9y6nSyonXUXC6+NHwot1 dmw7unMoScx35Irnh5jLDmwtEB9ck2xeUJPQP0Y6+rmARhSanowU7kPspgLzREWlV5oQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jLT2c-001HDo-6R; Mon, 06 Apr 2020 16:47:58 +0200 Date: Mon, 6 Apr 2020 16:47:58 +0200 From: Andrew Lunn To: Alexander Lobakin <79537434260@yandex.com> Cc: "David S. Miller" , Jakub Kicinski , Woojung Huh , Florian Fainelli , Hauke Mehrtens , Linus Walleij , Sean Wang , Russell King , Microchip Linux Driver Support , Claudiu Manoil , netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Philipp Zabel , Vladimir Oltean , Matthias Brugger , Oleksij Rempel , Vivien Didelot , linux-kernel@vger.kernel.org, Mao Wenan Subject: Re: [PATCH net-next] net: dsa: add GRO support via gro_cells Message-ID: <20200406144758.GC301483@lunn.ch> References: <20200406105910.32339-1-79537434260@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200406105910.32339-1-79537434260@yandex.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Apr 06, 2020 at 01:59:10PM +0300, Alexander Lobakin wrote: > gro_cells lib is used by different encapsulating netdevices, such as > geneve, macsec, vxlan etc. to speed up decapsulated traffic processing. > CPU tag is a sort of "encapsulation", and we can use the same mechs to > greatly improve overall DSA performance. > skbs are passed to the GRO layer after removing CPU tags, so we don't > need any new packet offload types as it was firstly proposed by me in > the first GRO-over-DSA variant [1]. > > The size of struct gro_cells is sizeof(void *), so hot struct > dsa_slave_priv becomes only 4/8 bytes bigger, and all critical fields > remain in one 32-byte cacheline. > The other positive side effect is that drivers for network devices > that can be shipped as CPU ports of DSA-driven switches can now use > napi_gro_frags() to pass skbs to kernel. Packets built that way are > completely non-linear and are likely being dropped without GRO. > > This was tested on to-be-mainlined-soon Ethernet driver that uses > napi_gro_frags(), and the overall performance was on par with the > variant from [1], sometimes even better due to minimal overhead. > net.core.gro_normal_batch tuning may help to push it to the limit > on particular setups and platforms. > > [1] https://lore.kernel.org/netdev/20191230143028.27313-1-alobakin@dlink.ru/ Hi Alexander net-next is closed at the moment. So you should of posted this with an RFC prefix. The implementation looks nice and simple. But it would be nice to have some performance figures. Andrew