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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <448285BC-C58E-475C-BAA2-001501503D6C@timebeat.app> Date: Sat, 10 Sep 2022 16:07:48 +0100 From: Lasse Johnsen <lasse@...ebeat.app> To: Richard Cochran <richardcochran@...il.com> Cc: netdev@...r.kernel.org, Tony Nguyen <anthony.l.nguyen@...el.com>, Jesse Brandeburg <jesse.brandeburg@...el.com>, "Stanton, Kevin B" <kevin.b.stanton@...el.com>, Jonathan Lemon <bsd@...com> Subject: Re: [PATCH net-next 1/1] igc: ptp: Add 1-step functionality to igc driver Hi Richard, I understand your point and your concern. Would you be amenable to an addition to the API so we can take advantage of hardware that offers only a subset of the options? We could for example extend granularity of the HWTSTAMP TX API to make requests for different features visible to the user space applications directly. So the TX side would become much more granular as is already the case with the RX side. We could add HWTSTAMP_TX_ONESTEP_SYNC_L2_V2, HWTSTAMP_TX_ONESTEP_SYNC_L4_V2 etc. My worry is that if we do not do this, then the ONESTEP option will continue to not see much use because so many permutations (L2, UDPv4, UDPv6, V1, V2, VLAN etc.) currently have to be supported by the hardware. I like Intel’s cards. I want to support the features provided by the hardware… :-) If you agree with this approach, then I will submit instead two patches: One patch that extends the API and another modified version of the current igc patch which will use the new more granular option. For the former, I will try and persuade (...beg... I will beg...) JL to supervise the API work so it does not go off the rails :-) In parallel, I have reached out to Kevin and asked if the 1-step logic will ever be able to update the UDP checksum on-the-fly in which case I shall certainly include this functionality as well. Let me know what you think. All the best, Lasse > On 9 Sep 2022, at 15:21, Richard Cochran <richardcochran@...il.com> wrote: > > On Fri, Sep 09, 2022 at 09:51:23AM +0100, Lasse Johnsen wrote: > >> So where the driver received an ioctl with tx config option HWTSTAMP_TX_ONESTEP_SYNC it will process >> skbs not matching the above criteria (including PTP_CLASS_IPV4) as it would have had the tx config option >> been HWTSTAMP_TX_ON. This patch does not change the behaviour of the latter in any way. >> >> Therefore a user space application which has used the HWTSTAMP_TX_ONESTEP_SYNC tx config option >> and is sending UDP messages will as usual receive those messages back in the error queue with >> hardware timestamps in the normal fashion. (provided of course in the case of this specific driver that >> another tx timestamping operation is not in progress.) > > Okay, then I must NAK this patch. If driver offers one-step and user > enables it, then it should work. > > The option, HWTSTAMP_TX_ONESTEP_SYNC, means to apply one-step to any > and all Sync frames, not just layer 2. The API does not offer a way > to advertise or configure one-step selectively based on network layer. > > Thanks, > Richard
Powered by blists - more mailing lists