From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH bpf-next 2/7] lib: reciprocal_div: implement the
 improved algorithm on the paper mentioned
Date: Tue, 26 Jun 2018 13:52:58 -0700
Message-ID: <20180626135258.7e80bead@cakuba.netronome.com>
References: <20180625035421.2991-1-jakub.kicinski@netronome.com>
        <20180625035421.2991-3-jakub.kicinski@netronome.com>
        <CAPhsuW4P5J1ZgUVKGfwWs7vX_7thc5cr1x6mrY8Wx3d2dqEDTw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        oss-drivers@netronome.com, Networking <netdev@vger.kernel.org>,
        Jiong Wang <jiong.wang@netronome.com>
To: Song Liu <liu.song.a23@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f181.google.com ([209.85.216.181]:44473 "EHLO
        mail-qt0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751569AbeFZUxD (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 26 Jun 2018 16:53:03 -0400
Received: by mail-qt0-f181.google.com with SMTP id 92-v6so12004211qta.11
        for <netdev@vger.kernel.org>; Tue, 26 Jun 2018 13:53:03 -0700 (PDT)
In-Reply-To: <CAPhsuW4P5J1ZgUVKGfwWs7vX_7thc5cr1x6mrY8Wx3d2dqEDTw@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, 25 Jun 2018 23:21:10 -0700, Song Liu wrote:
> > +struct reciprocal_value_adv reciprocal_value_adv(u32 d, u8 prec)
> > +{
> > +       struct reciprocal_value_adv R;
> > +       u32 l, post_shift;
> > +       u64 mhigh, mlow;
> > +
> > +       l = fls(d - 1);
> > +       post_shift = l;
> > +       /* NOTE: mlow/mhigh could overflow u64 when l == 32 which means d has
> > +        * MSB set. This case needs to be handled before calling
> > +        * "reciprocal_value_adv", please see the comment at
> > +        * include/linux/reciprocal_div.h.
> > +        */  
> 
> Shall we handle l == 32 case better? I guess the concern here is extra
> handling may slow down the fast path? If that's the case, we should
> at least add a WARNING on the slow path.

Agreed, I think Jiong is travelling, hence no response.  We'll respin.