[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0fc50b8e6ff44c43b10481da608c95c3@AcuMS.aculab.com>
Date: Sat, 28 Oct 2023 06:38:51 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Shinas Rasheed' <srasheed@...vell.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
CC: "hgani@...vell.com" <hgani@...vell.com>, "vimleshk@...vell.com"
<vimleshk@...vell.com>, "egallen@...hat.com" <egallen@...hat.com>,
"mschmidt@...hat.com" <mschmidt@...hat.com>, "pabeni@...hat.com"
<pabeni@...hat.com>, "horms@...nel.org" <horms@...nel.org>, "kuba@...nel.org"
<kuba@...nel.org>, "davem@...emloft.net" <davem@...emloft.net>,
"wizhao@...hat.com" <wizhao@...hat.com>, "konguyen@...hat.com"
<konguyen@...hat.com>, Veerasenareddy Burru <vburru@...vell.com>, "Sathesh
Edara" <sedara@...vell.com>, Eric Dumazet <edumazet@...gle.com>
Subject: RE: [PATCH net-next v2 3/4] octeon_ep: implement xmit_more in
transmit
From: Shinas Rasheed
> Sent: 24 October 2023 15:51
>
> Add xmit_more handling in tx datapath for octeon_ep pf.
>
...
> -
> - /* Ring Doorbell to notify the NIC there is a new packet */
> - writel(1, iq->doorbell_reg);
> - iq->stats.instr_posted++;
> + /* Ring Doorbell to notify the NIC of new packets */
> + writel(iq->fill_cnt, iq->doorbell_reg);
> + iq->stats.instr_posted += iq->fill_cnt;
> + iq->fill_cnt = 0;
> return NETDEV_TX_OK;
Does that really need the count?
A 'doorbell' register usually just tells the MAC engine
to go and look at the transmit ring.
It then continues to process transmits until it fails
to find a packet.
So if the transmit is active you don't need to set the bit.
(Although that is actually rather hard to detect.)
The 'xmit_more' flag is useful if (the equivalent of) writing
the doorbell register is expensive since it can be delayed
to a later frame and only done once - adding a slight latency
to the earlier transmits if the mac engine was idle.
I'm not sure how much (if any) performance gain you actually
get from avoiding the writel().
Single PCIe writes are 'posted' and pretty much completely
asynchronous.
The other problem I've seen is that netdev_xmit_more() is
the state of the queue when the transmit was started, not
the current state.
If a packet is added while the earlier transmit setup code
is running (setting up the descriptors etc) the it isn't set.
So the fast path doesn't get taken.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists