[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YamHCHzmmQFA6Wxb@Laptop-X1>
Date: Fri, 3 Dec 2021 10:55:04 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Jay Vosburgh <j.vosburgh@...il.com>,
Veaceslav Falico <vfalico@...il.com>,
Andy Gospodarek <andy@...yhouse.net>, davem@...emloft.net,
Richard Cochran <richardcochran@...il.com>,
Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [PATCH net-next] bond: pass get_ts_info and SIOC[SG]HWTSTAMP
ioctl to active device
On Thu, Dec 02, 2021 at 06:59:23AM -0800, Jakub Kicinski wrote:
> On Thu, 2 Dec 2021 11:04:40 +0800 Hangbin Liu wrote:
> > > Yeah, there should be some form of well understood indication in the
> > > uAPI telling the user space daemon that the PHC may get swapped on the
> > > interface, and a reliable notification which indicates PHC change.
> > > There is a number of user space daemons out there, fixing linuxptp does
> > > not mean other user space won't be broken/surprised/angry.
> >
> > This is a RFE, I don't think this patch will affect the current user space as
> > the new topology is not supported before. i.e. no user space tool will configure
> > PTP based on bond or vlan over bond. And even the user space use other ways to
> > get bond's active interface, e.g. via netlink message. It still not affected
> > and could keep using the old way. So I think this patch should be safe.
> >
> > Did I miss any thing?
>
> User can point their PTP daemon at any interface. Since bond now
> supports the uAPI the user will be blissfully unaware that their
> configuration will break if failover happens.
>
> We can't expect every user and every PTP daemon to magically understand
> the implicit quirks of the drivers. Quirks which are not even
> documented.
Thanks for the explanation. I understand what you mean now.
>
> What I'm saying is that we should have a new bit in the uAPI that
> tells us that the user space can deal with unstable PHC idx and reject
> the request forwarding in bond if that bit is not set. We have a flags
> field in hwtstamp_config which should fit the bill. Make sense?
Yes, this makes sense for me. I check this and try post a patch next week.
Thanks
Hangbin
Powered by blists - more mailing lists