Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 9 Mar 2022 13:16:32 +0100
From:   'Horatiu Vultur' <horatiu.vultur@microchip.com>
To:     David Laight <David.Laight@aculab.com>
CC:     Andrew Lunn <andrew@lunn.ch>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>
Subject: Re: [PATCH net-next] net: lan966x: Improve the CPU TX bitrate.
Message-ID: <20220309121632.d77v2x27kfaqiuzo@soft-dev3-1.localhost>
References: <20220308165727.4088656-1-horatiu.vultur@microchip.com>
 <YifMSUA/uZoPnpf1@lunn.ch>
 <20220308223000.vwdc6tk6wa53x64c@soft-dev3-1.localhost>
 <c85c188f9074456e92e9c4f8d8290ec2@AcuMS.aculab.com>
 <20220309091129.b5q3gtiuqlk5skka@soft-dev3-1.localhost>
 <45a9f88b140d44af8522e7d8a6abcbbf@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <45a9f88b140d44af8522e7d8a6abcbbf@AcuMS.aculab.com>
Precedence: bulk

The 03/09/2022 09:57, David Laight wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: 'Horatiu Vultur'
> > Sent: 09 March 2022 09:11
> >
> > The 03/08/2022 22:46, David Laight wrote:
> > >
> > > From: Horatiu Vultur
> > > > Sent: 08 March 2022 22:30
> > > >
> > > > The 03/08/2022 22:36, Andrew Lunn wrote:
> > > > >
> > > > > >  static int lan966x_port_inj_ready(struct lan966x *lan966x, u8 grp)
> > > > > >  {
> > > > > > -     u32 val;
> > > > > > +     unsigned long time = jiffies + usecs_to_jiffies(READL_TIMEOUT_US);
> > > > > > +     int ret = 0;
> > > > > >
> > > > > > -     return readx_poll_timeout_atomic(lan966x_port_inj_status, lan966x, val,
> > > > > > -                                      QS_INJ_STATUS_FIFO_RDY_GET(val) & BIT(grp),
> > > > > > -                                      READL_SLEEP_US, READL_TIMEOUT_US);
> > > > > > +     while (!(lan_rd(lan966x, QS_INJ_STATUS) &
> > > > > > +              QS_INJ_STATUS_FIFO_RDY_SET(BIT(grp)))) {
> > > > > > +             if (time_after(jiffies, time)) {
> > > > > > +                     ret = -ETIMEDOUT;
> > > > > > +                     break;
> > > > > > +             }
> > > > >
> > > > > Did you try setting READL_SLEEP_US to 0? readx_poll_timeout_atomic()
> > > > > explicitly supports that.
> > > >
> > > > I have tried but it didn't improve. It was the same as before.
> > >
> > > How many times round the loop is it going ?
> >
> > In the tests that I have done, I have never seen entering in the loop.
> 
> In which case I'd do an initial status check before even
> faffing with 'jiffies'.

That is a good idea. I will do this change in the next version.

> 
> It might even be that the status read is so slow that space
> is always available by the time it is processed.
> PCIe reads can be horribly slow.
> Into our fgpa they end up being slower than old ISA bus cycles.
> Probably several thousand cpu clocks.
> 
>         David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

-- 
/Horatiu