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-next>] [day] [month] [year] [list]
Message-ID: <7853649c6c1f2f4ce6d8bf9643cd1a43@linux.vnet.ibm.com>
Date:   Thu, 19 Nov 2020 14:38:02 -0600
From:   ljp <ljp@...ux.vnet.ibm.com>
To:     Thomas Falcon <tlfalcon@...ux.ibm.com>
Cc:     kuba@...nel.org, cforno12@...ux.ibm.com, netdev@...r.kernel.org,
        ricklind@...ux.ibm.com, dnbanerg@...ibm.com,
        drt@...ux.vnet.ibm.com, brking@...ux.vnet.ibm.com,
        sukadev@...ux.vnet.ibm.com, linuxppc-dev@...ts.ozlabs.org,
        Linuxppc-dev 
        <linuxppc-dev-bounces+ljp=linux.ibm.com@...ts.ozlabs.org>
Subject: Re: [PATCH net-next v2 9/9] ibmvnic: Do not replenish RX buffers
 after every polling loop

On 2020-11-19 14:26, Thomas Falcon wrote:
> On 11/19/20 3:43 AM, ljp wrote:
> 
>> On 2020-11-18 19:12, Thomas Falcon wrote:
>> 
>>> From: "Dwip N. Banerjee" <dnbanerg@...ibm.com>
>>> 
>>> Reduce the amount of time spent replenishing RX buffers by
>>> only doing so once available buffers has fallen under a certain
>>> threshold, in this case half of the total number of buffers, or
>>> if the polling loop exits before the packets processed is less
>>> than its budget.
>>> 
>>> Signed-off-by: Dwip N. Banerjee <dnbanerg@...ibm.com>
>>> ---
>>> drivers/net/ethernet/ibm/ibmvnic.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
>>> b/drivers/net/ethernet/ibm/ibmvnic.c
>>> index 96df6d8fa277..9fe43ab0496d 100644
>>> --- a/drivers/net/ethernet/ibm/ibmvnic.c
>>> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
>>> @@ -2537,7 +2537,10 @@ static int ibmvnic_poll(struct napi_struct
>>> 
>>> *napi, int budget)
>>> frames_processed++;
>>> }
>>> 
>>> - if (adapter->state != VNIC_CLOSING)
>>> + if (adapter->state != VNIC_CLOSING &&
>>> + ((atomic_read(&adapter->rx_pool[scrq_num].available) <
>>> + adapter->req_rx_add_entries_per_subcrq / 2) ||
>>> + frames_processed < budget))
>> 
>> 1/2 seems a simple and good algorithm.
>> Explaining why "frames_process < budget" is necessary in the commit
>> message
>> or source code also helps.
> 
> Hello, Lijun. The patch author, Dwip Banerjee, suggested the modified
> commit message below:
> 
> Reduce the amount of time spent replenishing RX buffers by
>  only doing so once available buffers has fallen under a certain
>  threshold, in this case half of the total number of buffers, or
>  if the polling loop exits before the packets processed is less
>  than its budget. Non-exhaustion of NAPI budget implies lower
>  incoming packet pressure, allowing the leeway to refill the buffers
>  in preparation for any impending burst.

It looks good to me.

> 
> Would such an update require a v3?

I assume you ask Jakub, right?


>>> replenish_rx_pool(adapter, &adapter->rx_pool[scrq_num]);
>>> if (frames_processed < budget) {
>>> if (napi_complete_done(napi, frames_processed)) {

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ