All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
	<UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH net 3/3] net: lan966x: Fix FDMA when MTU is changed
Date: Tue, 25 Oct 2022 19:34:05 -0700	[thread overview]
Message-ID: <20221025193405.1c8f6e74@kernel.org> (raw)
In-Reply-To: <20221023184838.4128061-4-horatiu.vultur@microchip.com>

On Sun, 23 Oct 2022 20:48:38 +0200 Horatiu Vultur wrote:
> +		mtu = lan_rd(lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));

I'm slightly confused about the vlan situation, does this return the
vlan hdr length when enabled? or vlans are always communicated
out-of-band so don't need to count here?

Unrelated potential issue I spotted:

        skb = build_skb(page_address(page), PAGE_SIZE << rx->page_order);       
        if (unlikely(!skb))                                                     
                goto unmap_page;                                                
                                                                                
        dma_unmap_single(lan966x->dev, (dma_addr_t)db->dataptr,                 
                         FDMA_DCB_STATUS_BLOCKL(db->status),                    
                         DMA_FROM_DEVICE);  

Are you sure it's legal to unmap with a different length than you
mapped? Seems questionable - you can unmap & ask the unmap to skip
the sync, then sync manually only the part that you care about - if you
want to avoid full sync.

What made me pause here is that you build_skb() and then unmap which is
also odd because normally (if unmap was passed full len) unmap could
wipe what build_skb() initialized.

  reply	other threads:[~2022-10-26  2:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-23 18:48 [PATCH net 0/3] net: lan966x: Fixes for when MTU is changed Horatiu Vultur
2022-10-23 18:48 ` [PATCH net 1/3] net: lan966x: Fix the MTU calculation Horatiu Vultur
2022-10-23 18:48 ` [PATCH net 2/3] net: lan966x: Adjust maximum frame size when vlan is enabled/disabled Horatiu Vultur
2022-10-23 18:48 ` [PATCH net 3/3] net: lan966x: Fix FDMA when MTU is changed Horatiu Vultur
2022-10-26  2:34   ` Jakub Kicinski [this message]
2022-10-26 18:35     ` Horatiu Vultur

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=20221025193405.1c8f6e74@kernel.org \
    --to=kuba@kernel.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.