Query regarding Phy loopback support

Query regarding Phy loopback support

[Hariprasad Kelam]

We're looking for a standard way to configure PHY loopback on a network 
interface using common Linux tools like ethtool, ip, or devlink.

Currently, ethtool -k eth0 loopback on enables a generic loopback, but it 
doesn't specify if it's an internal, external, or PHY loopback. 
Need suggestions to implement this feature in a standard way.

Re: Query regarding Phy loopback support

[Andrew Lunn]

On Tue, Sep 16, 2025 at 04:48:56PM +0530, Hariprasad Kelam wrote:
> We're looking for a standard way to configure PHY loopback on a network 
> interface using common Linux tools like ethtool, ip, or devlink.
> 
> Currently, ethtool -k eth0 loopback on enables a generic loopback, but it 
> doesn't specify if it's an internal, external, or PHY loopback. 
> Need suggestions to implement this feature in a standard way.

What actually do you mean by PHY loopback?

88e1118R supports two different loopbacks. It can do the loop at the
PCS, looping packets from the MAC back to the MAC. Or it can do the
loop at the PCS, looping packets from the media back to the media and
also deliver them to the MAC.

The 88e1510 has a slight different loopback. When used with copper, it
can loopback frames from the MAC back to the MAC in the copper
PCS. When used with Fibre is can loopback frames from the MAC to the
MAC in the fibre PCS. Additionally, it can loop back frames from the
MAC in the SERDES layer. And it can loopback frames from the media
back out the media.

From what a know of the aquantia PHY, it can loopback frames from the
MAC at the PCS or the PMA. And frames from the media can be looped
back at the PMA or the PCS.

I expect other vendors have a similar set of different places they can
do loopback, probably with variations.

Or do you simply mean as defined in 802.3, c22.2.4.1.2? And
c45.2.1.1.4, C45.2.1.1.5, taking into account c45.2.1.7.15 and
c45.2.1.12.1? And c45.2.1.18.1, c45.2.1.21.1, c45.2.1.22.1,
c45.2.1.231.6, c45.2.1.232.1, c45.2.1.234.5, c45.2.1.235.1, ...

	Andrew

Re: Query regarding Phy loopback support

[Hariprasad Kelam]

On 2025-09-16 at 22:13:20, Andrew Lunn (andrew@lunn.ch) wrote:
> On Tue, Sep 16, 2025 at 04:48:56PM +0530, Hariprasad Kelam wrote:
> > We're looking for a standard way to configure PHY loopback on a network 
> > interface using common Linux tools like ethtool, ip, or devlink.
> > 
> > Currently, ethtool -k eth0 loopback on enables a generic loopback, but it 
> > doesn't specify if it's an internal, external, or PHY loopback. 
> > Need suggestions to implement this feature in a standard way.
> 
> What actually do you mean by PHY loopback?

The Octeon silicon series supports both MAC (RPM) and PHY (GSERM) loopback 
modes for testing.

We are seeking a solution to support the following loopback types:

MAC Level

Far-end loopback: Ingress data is routed back to egress data (MAC-to-MAC).

Near-end external loopback: Egress traffic is routed back to ingress traffic at the PCS layer.

PHY Level

Near-end digital loopback

Near-end analog loopback

Far-end digital loopback

Far-end analog loopback

We need suggestions on how to enable and manage these specific modes.

Thanks,
Hariprasad k

Re: Query regarding Phy loopback support

[Andrew Lunn]

On Sun, Sep 21, 2025 at 11:14:55PM +0530, Hariprasad Kelam wrote:
> On 2025-09-16 at 22:13:20, Andrew Lunn (andrew@lunn.ch) wrote:
> > On Tue, Sep 16, 2025 at 04:48:56PM +0530, Hariprasad Kelam wrote:
> > > We're looking for a standard way to configure PHY loopback on a network 
> > > interface using common Linux tools like ethtool, ip, or devlink.
> > > 
> > > Currently, ethtool -k eth0 loopback on enables a generic loopback, but it 
> > > doesn't specify if it's an internal, external, or PHY loopback. 
> > > Need suggestions to implement this feature in a standard way.
> > 
> > What actually do you mean by PHY loopback?
> 
> The Octeon silicon series supports both MAC (RPM) and PHY (GSERM) loopback 
> modes for testing.
> 
> We are seeking a solution to support the following loopback types:
> 
> MAC Level
> 
> Far-end loopback: Ingress data is routed back to egress data (MAC-to-MAC).
> 
> Near-end external loopback: Egress traffic is routed back to ingress traffic at the PCS layer.
> 
> PHY Level
> 
> Near-end digital loopback
> 
> Near-end analog loopback
> 
> Far-end digital loopback
> 
> Far-end analog loopback
> 
> We need suggestions on how to enable and manage these specific modes.

Whatever you put in place, it needs to be generic to support other
modes. So you need some sort of enum which can be extended. When
describing the different modes, please try to reference 802.3, so it
is clear what each actually means. And if it is a vendor mode, please
describe it well, so other vendors know what it is, and can match
their vendor names to it.

Frames received on the Media loopback vs host transmitted frames
should be another property.

Are you wanting to use this with ethtool --test? That operation is
still using IOCTL. So you will want to add netlink support, both in
ethtool(1) and net/ethtool/netlink.c, so you can add the extra
optional parameters to indicate where loopback should be
performed. And them plumb this through the MAC ethtool to phylink and
phylib, and maybe the PCS layer, if you have a linux PCS involved.

	Andrew

Re: Query regarding Phy loopback support

[Maxime Chevallier]

Hi,

On 22/09/2025 00:12, Andrew Lunn wrote:
> On Sun, Sep 21, 2025 at 11:14:55PM +0530, Hariprasad Kelam wrote:
>> On 2025-09-16 at 22:13:20, Andrew Lunn (andrew@lunn.ch) wrote:
>>> On Tue, Sep 16, 2025 at 04:48:56PM +0530, Hariprasad Kelam wrote:
>>>> We're looking for a standard way to configure PHY loopback on a network
>>>> interface using common Linux tools like ethtool, ip, or devlink.
>>>>
>>>> Currently, ethtool -k eth0 loopback on enables a generic loopback, but it
>>>> doesn't specify if it's an internal, external, or PHY loopback.
>>>> Need suggestions to implement this feature in a standard way.
>>>
>>> What actually do you mean by PHY loopback?
>>
>> The Octeon silicon series supports both MAC (RPM) and PHY (GSERM) loopback
>> modes for testing.
>>
>> We are seeking a solution to support the following loopback types:
>>
>> MAC Level
>>
>> Far-end loopback: Ingress data is routed back to egress data (MAC-to-MAC).
>>
>> Near-end external loopback: Egress traffic is routed back to ingress traffic at the PCS layer.
>>
>> PHY Level
>>
>> Near-end digital loopback
>>
>> Near-end analog loopback
>>
>> Far-end digital loopback
>>
>> Far-end analog loopback
>>
>> We need suggestions on how to enable and manage these specific modes.
> 
> Whatever you put in place, it needs to be generic to support other
> modes. So you need some sort of enum which can be extended. When
> describing the different modes, please try to reference 802.3, so it
> is clear what each actually means. And if it is a vendor mode, please
> describe it well, so other vendors know what it is, and can match
> their vendor names to it.
> 
> Frames received on the Media loopback vs host transmitted frames
> should be another property.
> 
> Are you wanting to use this with ethtool --test? That operation is
> still using IOCTL. So you will want to add netlink support, both in
> ethtool(1) and net/ethtool/netlink.c, so you can add the extra
> optional parameters to indicate where loopback should be
> performed. And them plumb this through the MAC ethtool to phylink and
> phylib, and maybe the PCS layer, if you have a linux PCS involved.

There were some previous discussions here [1] and [2] for more pointers 
on what to support with such a loopback feature. I'd be happy to help 
testing that work should you send any series.

[1]: https://lore.kernel.org/netdev/20240913093453.30811cb3@fedora.home/
[2]: https://lore.kernel.org/netdev/ZuJyJT-HgXJFe5ul@pengutronix.de/

Thanks,

Maxime