linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Bryan.Whitehead@microchip.com>
To: <thesven73@gmail.com>, <UNGLinuxDriver@microchip.com>,
	<davem@davemloft.net>, <kuba@kernel.org>
Cc: <andrew@lunn.ch>, <rtgbnm@gmail.com>, <sbauer@blackbox.su>,
	<tharvey@gateworks.com>, <anders@ronningen.priv.no>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next v1 1/6] lan743x: boost performance on cpu archs w/o dma cache snooping
Date: Sat, 30 Jan 2021 22:10:52 +0000	[thread overview]
Message-ID: <MN2PR11MB3662C6C13B2D549E339D7DD1FAB89@MN2PR11MB3662.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210129195240.31871-2-TheSven73@gmail.com>

Sven, see below comments

> @@ -2148,11 +2149,18 @@ static int lan743x_rx_process_packet(struct
> lan743x_rx *rx)
>                         descriptor = &rx->ring_cpu_ptr[first_index];
> 
>                         /* unmap from dma */
> +                       packet_length = RX_DESC_DATA0_FRAME_LENGTH_GET_
> +                                       (descriptor->data0);
It appears you moved this packet_length assignment from just below the following if block, however  you left out the le32_to_cpu.See next comment

>                         if (buffer_info->dma_ptr) {
> -                               dma_unmap_single(&rx->adapter->pdev->dev,
> -                                                buffer_info->dma_ptr,
> -                                                buffer_info->buffer_length,
> -                                                DMA_FROM_DEVICE);
> +                               dma_sync_single_for_cpu(&rx->adapter->pdev->dev,
> +                                                       buffer_info->dma_ptr,
> +                                                       packet_length,
> +                                                       DMA_FROM_DEVICE);
> +                               dma_unmap_single_attrs(&rx->adapter->pdev->dev,
> +                                                      buffer_info->dma_ptr,
> +                                                      buffer_info->buffer_length,
> +                                                      DMA_FROM_DEVICE,
> +
> + DMA_ATTR_SKIP_CPU_SYNC);
>                                 buffer_info->dma_ptr = 0;
>                                 buffer_info->buffer_length = 0;
>                         }
Just below here is the following line
		packet_length = RX_DESC_DATA0_FRAME_LENGTH_GET_
				(le32_to_cpu(descriptor->data0));
This line was moved above the previous if block, but the le32_to_cpu was removed. Is that intentional?
Also I don't see any mention of this packet_length assignment (after the if block) being removed.
Since packet_length already contains this value, it seems unnecessary to keep this assignment.

> @@ -2167,8 +2175,8 @@ static int lan743x_rx_process_packet(struct
> lan743x_rx *rx)
>                         int index = first_index;
> 
>                         /* multi buffer packet not supported */
> -                       /* this should not happen since
> -                        * buffers are allocated to be at least jumbo size
> +                       /* this should not happen since buffers are allocated
> +                        * to be at least the mtu size configured in the mac.
>                          */
> 
>                         /* clean up buffers */ @@ -2628,6 +2636,9 @@ static int
> lan743x_netdev_change_mtu(struct net_device *netdev, int new_mtu)
>         struct lan743x_adapter *adapter = netdev_priv(netdev);
>         int ret = 0;
> 
> +       if (netif_running(netdev))
> +               return -EBUSY;
> +
>         ret = lan743x_mac_set_mtu(adapter, new_mtu);
>         if (!ret)
>                 netdev->mtu = new_mtu;
> --
> 2.17.1


  parent reply	other threads:[~2021-01-30 22:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 19:52 [PATCH net-next v1 0/6] lan743x speed boost Sven Van Asbroeck
2021-01-29 19:52 ` [PATCH net-next v1 1/6] lan743x: boost performance on cpu archs w/o dma cache snooping Sven Van Asbroeck
2021-01-29 20:36   ` Andrew Lunn
2021-01-29 22:49     ` Sven Van Asbroeck
2021-01-29 22:01   ` Jakub Kicinski
2021-01-29 22:46     ` Sven Van Asbroeck
2021-01-30 22:10   ` Bryan.Whitehead [this message]
2021-01-30 23:59     ` Sven Van Asbroeck
2021-01-31  0:14     ` Sven Van Asbroeck
     [not found]   ` <20210204060210.2362-1-hdanton@sina.com>
2021-02-05  9:31     ` Christoph Hellwig
2021-02-05 14:01       ` Sven Van Asbroeck
2021-02-05 12:44   ` Sergej Bauer
2021-02-05 14:07     ` Sven Van Asbroeck
2021-02-05 15:09       ` Sergej Bauer
2021-02-05 16:39         ` Sven Van Asbroeck
2021-02-05 16:59           ` Sergej Bauer
2021-01-29 19:52 ` [PATCH net-next v1 2/6] lan743x: support rx multi-buffer packets Sven Van Asbroeck
2021-01-29 22:11   ` Willem de Bruijn
2021-01-29 23:02     ` Sven Van Asbroeck
2021-01-29 23:08       ` Willem de Bruijn
2021-01-29 23:10         ` Sven Van Asbroeck
2021-01-31  7:06   ` Bryan.Whitehead
2021-01-31 15:25     ` Sven Van Asbroeck
2021-02-01 18:04       ` Bryan.Whitehead
2021-02-03 18:53         ` Sven Van Asbroeck
2021-02-03 20:14           ` Bryan.Whitehead
2021-02-03 20:25             ` Sven Van Asbroeck
2021-02-03 20:41               ` Bryan.Whitehead
2021-01-29 19:52 ` [PATCH net-next v1 3/6] lan743x: allow mtu change while network interface is up Sven Van Asbroeck
2021-01-29 19:52 ` [PATCH net-next v1 4/6] TEST ONLY: lan743x: limit rx ring buffer size to 500 bytes Sven Van Asbroeck
2021-01-29 19:52 ` [PATCH net-next v1 5/6] TEST ONLY: lan743x: skb_alloc failure test Sven Van Asbroeck
2021-01-29 19:52 ` [PATCH net-next v1 6/6] TEST ONLY: lan743x: skb_trim " Sven Van Asbroeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR11MB3662C6C13B2D549E339D7DD1FAB89@MN2PR11MB3662.namprd11.prod.outlook.com \
    --to=bryan.whitehead@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=anders@ronningen.priv.no \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rtgbnm@gmail.com \
    --cc=sbauer@blackbox.su \
    --cc=tharvey@gateworks.com \
    --cc=thesven73@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).