RE: [PATCH net-next 4/6] rtnetlink: Add support for SyncE recovered clock configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Roopa Prabhu <roopa@xxxxxxxxxx>
> Sent: Thursday, November 4, 2021 7:25 PM
> To: Machnikowski, Maciej <maciej.machnikowski@xxxxxxxxx>;
> netdev@xxxxxxxxxxxxxxx; intel-wired-lan@xxxxxxxxxxxxxxxx
> Cc: richardcochran@xxxxxxxxx; abyagowi@xxxxxx; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> linux-kselftest@xxxxxxxxxxxxxxx; idosch@xxxxxxxxxx; mkubecek@xxxxxxx;
> saeed@xxxxxxxxxx; michael.chan@xxxxxxxxxxxx
> Subject: Re: [PATCH net-next 4/6] rtnetlink: Add support for SyncE recovered
> clock configuration
> 
> 
> On 11/4/21 1:12 AM, Maciej Machnikowski wrote:
> > Add support for RTNL messages for reading/configuring SyncE recovered
> > clocks.
> > The messages are:
> > RTM_GETRCLKRANGE: Reads the allowed pin index range for the
> recovered
> > 		  clock outputs. This can be aligned to PHY outputs or
> > 		  to EEC inputs, whichever is better for a given
> > 		  application
> >
> > RTM_GETRCLKSTATE: Read the state of recovered pins that output
> recovered
> > 		  clock from a given port. The message will contain the
> > 		  number of assigned clocks (IFLA_RCLK_STATE_COUNT) and
> > 		  a N pin inexes in IFLA_RCLK_STATE_OUT_IDX
> >
> > RTM_SETRCLKSTATE: Sets the redirection of the recovered clock for
> > 		  a given pin
> >
> > Signed-off-by: Maciej Machnikowski <maciej.machnikowski@xxxxxxxxx>
> > ---
> 
> 
> Can't we just use a single RTM msg with nested attributes ?
> 
> With separate RTM msgtype for each syncE attribute we will end up
> bloating the RTM msg namespace.
> 
> (these api's could also be in ethtool given its directly querying the
> drivers)

I'm not a fan of merging those messages. The mergeable ones are
GETRCLKRANGE and GETCLKSTATE, but the get range function may be
result in a significantly longer call if the information about the underlying
HW require any HW calls.
They are currently grouped in 3 categories:
- reading the boundaries in GetRclkRange (we can later add more to it, like
	configurable frequency limits)
- Reading current configuration
- setting the required configuration

I don't plan adding any additional RTM msg types for those (and that's
the reason why I pulled them before EEC state which may have more
messages in the future)

We also discussed ethtool way in the past RFCs, but this concept
is applicable to any transport layer so I'd rather not limit it to ethernet
devices (i.e. SONET, infiniband and others).

Regards
Maciek




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux