lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Mar 2022 21:51:45 +0100 From: Gerhard Engleder <gerhard@...leder-embedded.com> To: Richard Cochran <richardcochran@...il.com> Cc: yangbo.lu@....com, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, mlichvar@...hat.com, Vinicius Costa Gomes <vinicius.gomes@...el.com>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH net-next v1 5/6] ptp: Support late timestamp determination > > > > > diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c > > > > > index 54b9f54ac0b2..b7a8cf27c349 100644 > > > > > --- a/drivers/ptp/ptp_clock.c > > > > > +++ b/drivers/ptp/ptp_clock.c > > > > > @@ -450,6 +450,33 @@ void ptp_cancel_worker_sync(struct ptp_clock *ptp) > > > > > } > > > > > EXPORT_SYMBOL(ptp_cancel_worker_sync); > > > > > > > > > > +ktime_t ptp_get_timestamp(int index, > > > > > + const struct skb_shared_hwtstamps *hwtstamps, > > > > > + bool cycles) > > > > > +{ > > > > > + char name[PTP_CLOCK_NAME_LEN] = ""; > > > > > + struct ptp_clock *ptp; > > > > > + struct device *dev; > > > > > + ktime_t ts; > > > > > + > > > > > + snprintf(name, PTP_CLOCK_NAME_LEN, "ptp%d", index); > > > > > + dev = class_find_device_by_name(ptp_class, name); > > > > > > > > This seems expensive for every single Rx frame in a busy PTP network. > > > > Can't this be cached in the socket? > > > I thought that PTP packages are rare and that bloating the socket is > > > not welcome. > > > > Some PTP profiles use insanely high frame rates. like G.8275.1 with > > Sync and Delay Req at 16/sec each. times the number of clients. > > times the number of vclocks/Domains. Getting the physical clock in __sock_recv_timestamp() is the expensive path. The network device is already available __sock_recv_timestamp(). Timestamp determination based on address/cookie could be done by the network device instead of the physical clock. In my opinion, that would be a good fit, because timestamp generation is already a task of the network device and implementation would be faster/simpler. What do you think? Gerhard
Powered by blists - more mailing lists