From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4444A3B0AC8 for ; Thu, 12 Mar 2026 07:49:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773301796; cv=none; b=oliJSGb63Y/2z4yfSQTbb5FgUY/bPpt+eX1Kf52WeSW6vc6y7VLqU2Ck2vfYvYaeybO4xiDFt+uE2i6yAmliA/WZZ1Uhk2ETb+obWN1SGezUhdL8p3+ps28IYW7f44EEszscA5gWlvRZVHBGjLqOlcexPJo2WIlylQKzWy094CU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773301796; c=relaxed/simple; bh=qc6nhP5c2KbUKz7TVprgeRZu7pcKDVuliPuq3MEFpFk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RlJvRa/iL4DbfjyqBkpQLgYww5EsYNRZFwGyIyaywv3kccRMglYFebHrdVVGLLbmuHAavywHGjqp1npIk4vuPYoWshXT2vUo0Yl7RYfPn6vs8flE6X0Q31dAhu5wOijaI7EUYeHdIqtrZG4F5azxFdfpmd+vi6MLwHspyvTVN7I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=Ax/gNMry; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="Ax/gNMry" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 1E85F1A2DAB; Thu, 12 Mar 2026 07:49:50 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id D2AC65FDEB; Thu, 12 Mar 2026 07:49:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id BE4DD103685B6; Thu, 12 Mar 2026 08:49:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1773301788; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=oT1XxdAl50AWEmjTvDhxYXZzFl6EH2KJUz4HxFpnESQ=; b=Ax/gNMry1zn+jSGCJbygPm1MqxQ4xxoTT66fSRTc5nLHZg0smRQfQsCBxzFAgGLzAa5lfd Af4Hzw3beOAKGJa2JoN1tyRRgpFbt2P1DrjSQJLrLuFisE3KcRi9NuOajpxaUhtjQbuHEK kR3cJQ7kSGJyJSKLk1FFFNgbzO9Llxvoc0l+zkG8/VZWxfJJLvshOLgAEPhd0YVzYaaAc3 wf1CqHn90p9oxKToETmVmvknFNcnGt4nnaLz9lclipHxPR9jfhGQ3zeSz9iFLtb5+nxz2S 99oywt/IIeSV4UXD45vO3Bd0BvPnK1F/DNbgdI8WLyq0hFw/oXtfNgrByjMj/Q== Message-ID: Date: Thu, 12 Mar 2026 08:49:39 +0100 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 02/11] ethtool: Add loopback netlink UAPI definitions To: Oleksij Rempel , Jakub Kicinski Cc: Andrew Lunn , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , netdev@vger.kernel.org, "David S. Miller" , Andrew Lunn , Donald Hunter , Eric Dumazet , Naveen Mamindlapalli , Paolo Abeni , Simon Horman , Danielle Ratson , Hariprasad Kelam , Ido Schimmel , Kory Maincent , Leon Romanovsky , Michael Chan , Pavan Chebbi , Piergiorgio Beruto , Russell King , Saeed Mahameed , Shuah Khan , Tariq Toukan , Willem de Bruijn , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org References: <20260310104743.907818-1-bjorn@kernel.org> <20260310104743.907818-3-bjorn@kernel.org> <580debbb-8f6c-4b60-95ef-22c68480ded1@bootlin.com> <085bb0a9-85d3-4d62-9ac4-3461b61da5f3@bootlin.com> <438dae03-4dac-4e66-9f4d-e08b0434c9b4@lunn.ch> <20260311195052.1202174f@kernel.org> From: Maxime Chevallier Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 12/03/2026 06:04, Oleksij Rempel wrote: > On Wed, Mar 11, 2026 at 07:50:52PM -0700, Jakub Kicinski wrote: >> On Wed, 11 Mar 2026 20:26:39 +0100 Andrew Lunn wrote: >>>> For that we have what we need with phy_link_topology, as each PHY has >>>> its index, we should be good to go in that regard hopefully :) >>> >>> So depth would be local to a component? We could have two PHY >>> components, each with a different index, and depth = 0? >>> >>> I _think_ Jakub's depth was more at a global level? But then it would >>> need to be passed down as we do the enumeration. >> >> Oh, sorry, I responded without reading the whole discussion :) >> No, I imagined the depth would be within a single component, >> so under control of a single driver (instance). The ordering >> between components should be defined by PHY topology etc so >> it's outside of the loopback config. > > As for me, it is problematic to help the user to understand the datapath > depth on a switch. For example: > > CPU -- xMII --- MAC1 [loop] --- fabric --- MAC2 [loop] --- xMII -- PHY > \----- MACx [loop] --- > > ... each port has two xMII loop configurations: towards the xMII or towards > the fabric. From a driver perspective, a loop towards the xMII is > "remote." However, from a system perspective, a "remote" loop on MAC1 is > a local loop at depth=0, whereas a "local" loop on MAC2 is a local loop > at depth=1. What's important is to specify clearly in the documentation from which end do we start, where representing the topology. From your scenario here, each block is already well represented and exposed, and if we use local depth definitions we should be fine ? > > Other example would be where we have a chain of components which are > attached on the system in a unexpected direction, where the MDI > interface is pointing towards the main CPU, so the remote loopbacks > became to local loop. I have a few of these types of setup on my desk, where 3 PHY devices are daisy-chained, we don't support that for now. If we one day add support for standalone PHYs acting as media converters, I expect we'll be able to tell which end is pointing where, and let it up to the user to figure out what "remote" and "local" means in that case. > > One more issue is the test data generator location. The data generator > is not always the CPU. We have HW generators located in components like > PHYs or we may use external source (remote loopback). There were discussions about PRBS, I think the same idea of "pinpointing which block we want to use" can be applied for both loopback and generation ? Maxime