linux-kernel - Re: [PATCH v2] usbnet: optimize usbnet

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-prev] [day] [month] [year] [list]

Message-ID: <1ba25d2e-6b46-dd8d-60d9-99cf2e7cd897@ooseel.net>
Date:   Wed, 21 Dec 2022 16:50:39 +0900
From:   Leesoo Ahn <lsahn@...eel.net>
To:     Greg KH <greg@...ah.com>
Cc:     Oliver Neukum <oneukum@...e.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usbnet: optimize usbnet_bh() to reduce CPU load


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@...eel.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