All of lore.kernel.org
 help / color / mirror / Atom feed
From: "G, GurucharanX" <gurucharanx.g@intel.com>
To: "Keller, Jacob E" <jacob.e.keller@intel.com>,
	Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
Subject: Re: [Intel-wired-lan] [net-next PATCH 1/7] ice: implement adjfine with mul_u64_u64_div_u64
Date: Tue, 26 Jul 2022 12:48:05 +0000	[thread overview]
Message-ID: <BYAPR11MB3367B0D86E6C29F2E7928B58FC949@BYAPR11MB3367.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220721213001.2483596-2-jacob.e.keller@intel.com>



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: Friday, July 22, 2022 3:00 AM
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Subject: [Intel-wired-lan] [net-next PATCH 1/7] ice: implement adjfine with
> mul_u64_u64_div_u64
> 
> The PTP frequency adjustment code needs to determine an appropriate
> adjustment given an input scaled_ppm adjustment.
> 
> We calculate the adjustment to the register by multiplying the base
> (nominal) increment value by the scaled_ppm and then dividing by the
> scaled one million value.
> 
> For very large adjustments, this might overflow. To avoid this, both the
> scaled_ppm and divisor values are downshifted.
> 
> We can avoid that on X86 architectures by using mul_u64_u64_div_u64. This
> helper function will perform the multiplication and division with 128bit
> intermediate values. We know that scaled_ppm is never larger than the
> divisor so this operation will never result in an overflow.
> 
> This improves the accuracy of the calculations for large adjustment values on
> X86. It is likely an improvement on other architectures as well because the
> default implementation of mul_u64_u64_div_u64 is smarter than the original
> approach taken in the ice code.
> 
> Additionally, this implementation is easier to read, using fewer local variables
> and lines of code to implement.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_ptp.c | 16 +++-------------
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 

Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2022-07-26 12:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 21:29 [Intel-wired-lan] [net-next PATCH 0/7] intel: ptp: convert .adjfreq to .adjfine Jacob Keller
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 1/7] ice: implement adjfine with mul_u64_u64_div_u64 Jacob Keller
2022-07-26 12:48   ` G, GurucharanX [this message]
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 1/1] igb: convert .adjfreq to .adjfine Jacob Keller
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 2/7] e1000e: remove unnecessary range check in e1000e_phc_adjfreq Jacob Keller
2022-07-25  4:44   ` naamax.meir
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 3/7] e1000e: convert .adjfreq to .adjfine Jacob Keller
2022-07-25 11:37   ` naamax.meir
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 4/7] i40e: use mul_u64_u64_div_u64 for PTP frequency calculation Jacob Keller
2022-07-26 12:48   ` G, GurucharanX
2022-07-21 21:29 ` [Intel-wired-lan] [net-next PATCH 5/7] i40e: convert .adjfreq to .adjfine Jacob Keller
2022-07-27  8:18   ` G, GurucharanX
2022-07-21 21:30 ` [Intel-wired-lan] [net-next PATCH 6/7] ixgbe: " Jacob Keller
2022-07-28  9:51   ` G, GurucharanX
2022-07-21 21:30 ` [Intel-wired-lan] [net-next PATCH 7/7] igb: " Jacob Keller
2022-07-28  9:52   ` G, GurucharanX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR11MB3367B0D86E6C29F2E7928B58FC949@BYAPR11MB3367.namprd11.prod.outlook.com \
    --to=gurucharanx.g@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.