Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2143768yba; Sun, 7 Apr 2019 09:55:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqw59ARQ5i4AqmSrVlVnidTFwcEAJP2Y7uW5tHn959pyr5duqgr1pO+knnwLQbCTXKMu5//F X-Received: by 2002:a62:b602:: with SMTP id j2mr25341592pff.68.1554656155245; Sun, 07 Apr 2019 09:55:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554656155; cv=none; d=google.com; s=arc-20160816; b=wPGkQwyacdnLzD5MJLJ6cuNMB0CseW2uk26FZGOJBbMX94XhToYYcN0TZism+SyHdd WXPMD9AJVhe4HUlmQpmf3snq1Av6UfRLfs6mM1QG+ol6YR69w9/k7zO0xecPw54DFNo1 +tH0sBXg1a25IwqyysgAn6K5rzM4NH1pq1Cji0qn0A9YWyG4XCMzunbw/tsT6FjpGGV8 eFZtqGlrtwp3mPjahshbybiCNmLVtizCMDBbY0fd5xOvSf6jbW3R/aVIO8QV/gIEM+rT 1f9kXTqj9XR1ze86YmadNDjPTW5H/YX70MAdjhtJBa8LGcMWhUwVMAhHA/OOq+b3Deuh OmSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QRCzw6TvLhmt6AW9ABGkZ66+fU1rhSJoGwJbTv6KsN8=; b=BIJevqsSjhB7bC8PfN7z45Bnkzi1pWJ0ffB4QY5LRby6uuvZezpWJeSNvXMNSghn4B 87hcirtvKkUyIRT+6a9cChdqAf22XshHZlbHTJmYvqp+7iHCyDfWjTkDXVvSAEHzpeJz D1ZjFKejNcy4mgBDyhfYHX1rx3ndA83BYnY2b4CxqBG4Qa4zoFfEcNglhb8a/sKkgSjR gch1UnTiWqj/w87IHNQ68ras8FXCx5CL7rHUFkrzNMjn57eNBg7uyQnWFNsTxxEX2csC oO3om5yebPU7SCd1U3wbs17FJcoMlAPFwKdFC4g7/HTq33uQwWfMZj3Ez84cmmbHxqQl 22wA== 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 p5si23903261plo.36.2019.04.07.09.55.39; Sun, 07 Apr 2019 09:55:55 -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 S1726471AbfDGQy3 (ORCPT + 99 others); Sun, 7 Apr 2019 12:54:29 -0400 Received: from bmailout2.hostsharing.net ([83.223.90.240]:43471 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726335AbfDGQy3 (ORCPT ); Sun, 7 Apr 2019 12:54:29 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id CC55E2800B3D1; Sun, 7 Apr 2019 18:54:25 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 4D20613BBF6; Sun, 7 Apr 2019 18:54:25 +0200 (CEST) Date: Sun, 7 Apr 2019 18:54:25 +0200 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Michael Jamet , Yehezkel Bernat , Andreas Noever , Andy Shevchenko , Christian Kellner , Mario.Limonciello@dell.com Subject: Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches Message-ID: <20190407165425.2z5kqm3wcfrxvqzb@wunner.de> References: <20190328123633.42882-1-mika.westerberg@linux.intel.com> <20190328123633.42882-20-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190328123633.42882-20-mika.westerberg@linux.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 28, 2019 at 03:36:16PM +0300, Mika Westerberg wrote: > +struct tb_path *tb_path_alloc(struct tb *tb, struct tb_port *src, int src_hopid, > + struct tb_port *dst, int dst_hopid, int link_nr, > + const char *name) > { [...] > + in_hopid = src_hopid; > + out_port = NULL; > + > + for (i = 0; i < num_hops; i++) { > + in_port = tb_next_port_on_path(src, dst, out_port); > + if (!in_port) > + goto err; > + > + if (in_port->dual_link_port && in_port->link_nr != link_nr) > + in_port = in_port->dual_link_port; > + > + ret = tb_port_alloc_in_hopid(in_port, in_hopid, -1); > + if (ret < 0) > + goto err; > + in_hopid = ret; > + > + out_port = tb_next_port_on_path(src, dst, in_port); > + if (!out_port) > + goto err; > + > + if (out_port->dual_link_port && out_port->link_nr != link_nr) > + out_port = out_port->dual_link_port; > + > + if (i == num_hops - 1) > + ret = tb_port_alloc_out_hopid(out_port, dst_hopid, > + dst_hopid); > + else > + ret = tb_port_alloc_out_hopid(out_port, -1, -1); > + > + if (ret < 0) > + goto err; > + out_hopid = ret; > + > + path->hops[i].in_hop_index = in_hopid; > + path->hops[i].in_port = in_port; > + path->hops[i].in_counter_index = -1; > + path->hops[i].out_port = out_port; > + path->hops[i].next_hop_index = out_hopid; > + > + in_hopid = out_hopid; > + } According to the code comment in struct tb_regs_hop (in tb_regs.h), the out_hopid ("next_hop" in struct tb_regs_hop) denotes the "hop to take after sending the packet through out_port (on the incoming port of the next switch)". So intuitively, the hop config space is like a routing table and the entry in in_port's hop config space specifies through which out_port the packets shall be routed, and which entry to look up on the remote port reachable through out_port. This means that the out_hopid must always be identical to the in_hopid of out_port->remote. Otherwise the routing wouldn't work. And yet, you've introduced *two* struct ida for each port in patch 16. This doesn't seem to make sense: The out_hopids ida of a port always has to be identical to the in_hopids ida of that port's remote. But if it's identical, why does it have to exist twice? Also, the above algorithm fails to ensure that the two struct ida are always identical: It uses the out_hopid on the previous switch as *minimum* for the in_hopid on the current switch. If that hopid is already taken by an existing tunnel, tb_port_alloc_in_hopid() will allocate a *different* hopid and thereby break the routing. So either the code comment in struct tb_regs_hop is wrong, or this algorithm and the duplicate struct ida in patch 16 are wrong, or I'm missing something. Thanks, Lukas