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;
Message-ID: <1ba25d2e-6b46-dd8d-60d9-99cf2e7cd897@ooseel.net>
Date:   Wed, 21 Dec 2022 16:50:39 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH v2] usbnet: optimize usbnet_bh() to reduce CPU load
Content-Language: en-US
To:     Greg KH <greg@kroah.com>
Cc:     Oliver Neukum <oneukum@suse.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20221221044230.1012787-1-lsahn@ooseel.net>
 <Y6KoglOyuFEqfp2k@kroah.com>
 <2d4033ea-3034-24cf-493c-f60258f9988d@ooseel.net>
 <Y6K2L+t5NjK/3ipj@kroah.com>
From:   Leesoo Ahn <lsahn@ooseel.net>
In-Reply-To: <Y6K2L+t5NjK/3ipj@kroah.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 22. 12. 21. 16:30, Greg KH wrote:
> On Wed, Dec 21, 2022 at 04:19:45PM +0900, Leesoo Ahn wrote:
>> On 22. 12. 21. 15:32, Greg KH wrote:
>>> On Wed, Dec 21, 2022 at 01:42:30PM +0900, Leesoo Ahn wrote:
>>>> The current source pushes skb into dev->done queue by calling
>>>> skb_queue_tail() and then pop it by calling skb_dequeue() to branch to
>>>> rx_cleanup state for freeing urb/skb in usbnet_bh(). It takes extra CPU
>>>> load, 2.21% (skb_queue_tail) as follows.
>>>>
>>>> -   11.58%     0.26%  swapper          [k] usbnet_bh
>>>>      - 11.32% usbnet_bh
>>>>         - 6.43% skb_dequeue
>>>>              6.34% _raw_spin_unlock_irqrestore
>>>>         - 2.21% skb_queue_tail
>>>>              2.19% _raw_spin_unlock_irqrestore
>>>>         - 1.68% consume_skb
>>>>            - 0.97% kfree_skbmem
>>>>                 0.80% kmem_cache_free
>>>>              0.53% skb_release_data
>>>>
>>>> To reduce the extra CPU load use return values jumping to rx_cleanup
>>>> state directly to free them instead of calling skb_queue_tail() and
>>>> skb_dequeue() for push/pop respectively.
>>>>
>>>> -    7.87%     0.25%  swapper          [k] usbnet_bh
>>>>      - 7.62% usbnet_bh
>>>>         - 4.81% skb_dequeue
>>>>              4.74% _raw_spin_unlock_irqrestore
>>>>         - 1.75% consume_skb
>>>>            - 0.98% kfree_skbmem
>>>>                 0.78% kmem_cache_free
>>>>              0.58% skb_release_data
>>>>           0.53% smsc95xx_rx_fixup
>>>>
>>>> Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
>>>> ---
>>>> v2:
>>>>     - Replace goto label with return statement to reduce goto entropy
>>>>     - Add CPU load information by perf in commit message
>>>>
>>>> v1 at:
>>>>     https://patchwork.kernel.org/project/netdevbpf/patch/20221217161851.829497-1-lsahn@ooseel.net/
>>>> ---
>>>>    drivers/net/usb/usbnet.c | 19 +++++++++----------
>>>>    1 file changed, 9 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>>>> index 64a9a80b2309..6e82fef90dd9 100644
>>>> --- a/drivers/net/usb/usbnet.c
>>>> +++ b/drivers/net/usb/usbnet.c
>>>> @@ -555,32 +555,30 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
>>>>    /*-------------------------------------------------------------------------*/
>>>> -static inline void rx_process (struct usbnet *dev, struct sk_buff *skb)
>>>> +static inline int rx_process(struct usbnet *dev, struct sk_buff *skb)
>>>>    {
>>>>    	if (dev->driver_info->rx_fixup &&
>>>>    	    !dev->driver_info->rx_fixup (dev, skb)) {
>>>>    		/* With RX_ASSEMBLE, rx_fixup() must update counters */
>>>>    		if (!(dev->driver_info->flags & FLAG_RX_ASSEMBLE))
>>>>    			dev->net->stats.rx_errors++;
>>>> -		goto done;
>>>> +		return 1;
>>> "1" means that you processed 1 byte, not that this is an error, which is
>>> what you want to say here, right?
>> No not at all..
>>> Please return a negative error value
>>> like I asked this to be changed to last time :(
>> Could you help me to decide the message type at this point please? I am
>> confused.
> I do not know, pick something that seems correct and we can go from
> there.  The important thing is that it is a -ERR value, not a positive
> one as that makes no sense for kernel functions.

Thank you for reviewing, v3 will be sent soon.

Best regards,
Leesoo