netdev - Re: [PATCH net-next v2 0/2] Provide direct access to 1588 one step register

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 18 Feb 2022 21:27:20 +0200
From:   Radu Bulie <radu-andrei.bulie@....com>
To:     davem@...emloft.net, kuba@...nel.org
Cc:     netdev@...r.kernel.org, ioana.ciornei@....com, yangbo.lu@....com,
        richardcochran@...il.com
Subject: Re: [PATCH net-next v2 0/2] Provide direct access to 1588 one step register

On Fri, 18 Feb 2022 20:37:55 +0200, Radu Bulie wrote:
> DPAA2 MAC supports 1588 one step timestamping.
> If this option is enabled then for each transmitted PTP event packet,
> the 1588 SINGLE_STEP register is accessed to modify the following fields:
> 
> -offset of the correction field inside the PTP packet
> -UDP checksum update bit,  in case the PTP event packet has
>  UDP encapsulation
> 
> These values can change any time, because there may be multiple
> PTP clients connected, that receive various 1588 frame types:
> - L2 only frame
> - UDP / Ipv4
> - UDP / Ipv6
> - other
> 
> The current implementation uses dpni_set_single_step_cfg to update the
> SINLGE_STEP register.
> Using an MC command  on the Tx datapath for each transmitted 1588 message
> introduces high delays, leading to low throughput and consequently to a
> small number of supported PTP clients. Besides these, the nanosecond
> correction field from the PTP packet will contain the high delay from the
> driver which together with the originTimestamp will render timestamp
> values that are unacceptable in a GM clock implementation.
> 
> This patch series replaces the dpni_set_single_step_cfg function call from
> the Tx datapath for 1588 messages (when one step timestamping is enabled) 
> with a callback that either implements direct access to the SINGLE_STEP
> register, eliminating the overhead caused by the MC command that will need
> to be dispatched by the MC firmware through the MC command portal
> interface or falls back to the dpni_set_single_step_cfg in case the MC
> version does not have support for returning the single step register
> base address.
> 
> In other words all the delay introduced by dpni_set_single_step_cfg
> function will be eliminated (if MC version has support for returning the
> base address of the single step register), improving the egress driver
> performance for PTP packets when single step timestamping is enabled.
> 
> The first patch adds a new attribute that contains the base address of
> the SINGLE_STEP register. It will be used to directly update the register
> on the Tx datapath.
> 
> The second patch updates the driver such that the SINGLE_STEP
> register is either accessed directly if MC version >= 10.32 or is
> accessed through dpni_set_single_step_cfg command when 1588 messages
> are transmitted.
> 
> Changes in v2:
>  - move global function pointer into the driver's private structure in 2/2
>  - move common code outside the body of the callback functions  in 2/2
>  - update function dpaa2_ptp_onestep_reg_update_method  and remove goto 
>    statement from paths that do not treat an error case in 2/2	
>  
> Radu Bulie (2):
>   dpaa2-eth: Update dpni_get_single_step_cfg command
>   dpaa2-eth: Provide direct access to 1588 one step register

I have messed up something in the 2/2 patch and the dpaa2 eth driver will not compile.
I will fix this in v3.