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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 F22C2C43603 for ; Thu, 5 Dec 2019 12:58:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BA8AE2245C for ; Thu, 5 Dec 2019 12:58:51 +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="ISS+iwm4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729482AbfLEM6u (ORCPT ); Thu, 5 Dec 2019 07:58:50 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:38046 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729099AbfLEM6u (ORCPT ); Thu, 5 Dec 2019 07:58:50 -0500 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=Re18R+zvHW22gTZUWM5G+y1mglFdF33WZZhd8u13ENU=; b=ISS+iwm4GEajcnWmdI+CAx1dLq /pA0TK0twSbpVXEiHZUfMswjcFncqO8a+fpeQuEx9p4FYARYyLozq/Jtwd5/XCSxYyY67Jk/7Sl7I hxY5Z3ZwD+8yUG/F1DJbo/zGql4/FJ/wj0M/YlPTTIBK/g0KfqVbGKLSUWXZF7RifIJE=; Received: from andrew by vps0.lunn.ch with local (Exim 4.92.2) (envelope-from ) id 1icqiB-0007OM-Fl; Thu, 05 Dec 2019 13:58:27 +0100 Date: Thu, 5 Dec 2019 13:58:27 +0100 From: Andrew Lunn To: Alexander Lobakin Cc: "David S. Miller" , Muciri Gatimu , Shashidhar Lakkavalli , John Crispin , Vivien Didelot , Florian Fainelli , Stanislav Fomichev , Daniel Borkmann , Song Liu , Alexei Starovoitov , Matteo Croce , Jakub Sitnicki , Eric Dumazet , Paul Blakey , Yoshiki Komachi , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: dsa: fix flow dissection on Tx path Message-ID: <20191205125827.GA28269@lunn.ch> References: <20191205100235.14195-1-alobakin@dlink.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191205100235.14195-1-alobakin@dlink.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 05, 2019 at 01:02:35PM +0300, Alexander Lobakin wrote: > Commit 43e665287f93 ("net-next: dsa: fix flow dissection") added an > ability to override protocol and network offset during flow dissection > for DSA-enabled devices (i.e. controllers shipped as switch CPU ports) > in order to fix skb hashing for RPS on Rx path. > > However, skb_hash() and added part of code can be invoked not only on > Rx, but also on Tx path if we have a multi-queued device and: > - kernel is running on UP system or > - XPS is not configured. > > The call stack in this two cases will be like: dev_queue_xmit() -> > __dev_queue_xmit() -> netdev_core_pick_tx() -> netdev_pick_tx() -> > skb_tx_hash() -> skb_get_hash(). > > The problem is that skbs queued for Tx have both network offset and > correct protocol already set up even after inserting a CPU tag by DSA > tagger, so calling tag_ops->flow_dissect() on this path actually only > breaks flow dissection and hashing. Hi Alexander What i'm missing here is an explanation why the flow dissector is called here if the protocol is already set? It suggests there is a case when the protocol is not correctly set, and we do need to look into the frame? Andrew