diff mbox series

[RFC,v1,net-next,1/1] net: ethernet: ti: cpsw: allow MTU > 1500 when overridden by module parameter

Message ID 20210721210538.22394-1-colin.foster@in-advantage.com (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series [RFC,v1,net-next,1/1] net: ethernet: ti: cpsw: allow MTU > 1500 when overridden by module parameter | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers warning 6 maintainers not CCed: zhangchangzhong@huawei.com lorenzo@kernel.org michael@walle.cc shayagr@amazon.com yanaijie@huawei.com yangyingliang@huawei.com
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 14 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link

Commit Message

Colin Foster July 21, 2021, 9:05 p.m. UTC
The module parameter rx_packet_max can be overridden at module load or
boot args. But it doesn't adjust the max_mtu for the device accordingly.

If a CPSW device is to be used in a DSA architecture, increasing the
MTU by small amounts to account for switch overhead becomes necessary.
This way, a boot arg of cpsw.rx_packet_max=1600 should allow the MTU
to be increased to values of 1520, which is necessary for DSA tagging
protocols like "ocelot" and "seville".

Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
---
 drivers/net/ethernet/ti/cpsw.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Andrew Lunn July 22, 2021, 2:05 p.m. UTC | #1
On Wed, Jul 21, 2021 at 02:05:38PM -0700, Colin Foster wrote:
> The module parameter rx_packet_max can be overridden at module load or
> boot args. But it doesn't adjust the max_mtu for the device accordingly.
> 
> If a CPSW device is to be used in a DSA architecture, increasing the
> MTU by small amounts to account for switch overhead becomes necessary.
> This way, a boot arg of cpsw.rx_packet_max=1600 should allow the MTU
> to be increased to values of 1520, which is necessary for DSA tagging
> protocols like "ocelot" and "seville".

Hi Colin

As far as your patch goes, it makes sense.

However, module parameters are unlikely by netdev maintainers. Having
to set one in order to make DSA work is not nice. What is involved in
actually removing the module parameter and making the MTU change work
without it?

> Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> ---
>  drivers/net/ethernet/ti/cpsw.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index c0cd7de88316..d400163c4ef2 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1625,6 +1625,14 @@ static int cpsw_probe(struct platform_device *pdev)
>  		goto clean_cpts;
>  	}
>  
> +	/* adjust max_mtu to match module parameter rx_packet_max */
> +	if (cpsw->rx_packet_max > CPSW_MAX_PACKET_SIZE) {
> +		ndev->max_mtu = ETH_DATA_LEN + (cpsw->rx_packet_max -
> +				CPSW_MAX_PACKET_SIZE);
> +		dev_info(dev, "overriding default MTU to %d\n\n",
> +			 ndev->max_mtu);

There is no need for dev_info(). You could consider dev_dbg(), or just
remove it.

       Andrew
Colin Foster July 22, 2021, 3:33 p.m. UTC | #2
On Thu, Jul 22, 2021 at 04:05:33PM +0200, Andrew Lunn wrote:
> On Wed, Jul 21, 2021 at 02:05:38PM -0700, Colin Foster wrote:
> > The module parameter rx_packet_max can be overridden at module load or
> > boot args. But it doesn't adjust the max_mtu for the device accordingly.
> > 
> > If a CPSW device is to be used in a DSA architecture, increasing the
> > MTU by small amounts to account for switch overhead becomes necessary.
> > This way, a boot arg of cpsw.rx_packet_max=1600 should allow the MTU
> > to be increased to values of 1520, which is necessary for DSA tagging
> > protocols like "ocelot" and "seville".
> 
> Hi Colin
> 
> As far as your patch goes, it makes sense.
> 
> However, module parameters are unlikely by netdev maintainers. Having
> to set one in order to make DSA work is not nice. What is involved in
> actually removing the module parameter and making the MTU change work
> without it?

Thanks for the feedback Andrew.

That's a good idea. I used the module parameter because it was already 
there.

My intent was to not change any existing default behavior. The below 
forum post makes me think that simply changing the default value of 
rx_packet_max from 1500 to 1998 alongside this patch is all that is 
needed. It all seems too easy, so either my use-case is rare enough 
that nobody considered it, or there's some limitation I'm missing.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/461724/how-to-send-receive-jumbo-packet-by-am335x-emac

> 
> > Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
> > ---
> >  drivers/net/ethernet/ti/cpsw.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> > index c0cd7de88316..d400163c4ef2 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -1625,6 +1625,14 @@ static int cpsw_probe(struct platform_device *pdev)
> >  		goto clean_cpts;
> >  	}
> >  
> > +	/* adjust max_mtu to match module parameter rx_packet_max */
> > +	if (cpsw->rx_packet_max > CPSW_MAX_PACKET_SIZE) {
> > +		ndev->max_mtu = ETH_DATA_LEN + (cpsw->rx_packet_max -
> > +				CPSW_MAX_PACKET_SIZE);
> > +		dev_info(dev, "overriding default MTU to %d\n\n",
> > +			 ndev->max_mtu);
> 
> There is no need for dev_info(). You could consider dev_dbg(), or just
> remove it.

Understood.

> 
>        Andrew
Andrew Lunn July 22, 2021, 4:50 p.m. UTC | #3
On Thu, Jul 22, 2021 at 08:33:51AM -0700, Colin Foster wrote:
> On Thu, Jul 22, 2021 at 04:05:33PM +0200, Andrew Lunn wrote:
> > On Wed, Jul 21, 2021 at 02:05:38PM -0700, Colin Foster wrote:
> > > The module parameter rx_packet_max can be overridden at module load or
> > > boot args. But it doesn't adjust the max_mtu for the device accordingly.
> > > 
> > > If a CPSW device is to be used in a DSA architecture, increasing the
> > > MTU by small amounts to account for switch overhead becomes necessary.
> > > This way, a boot arg of cpsw.rx_packet_max=1600 should allow the MTU
> > > to be increased to values of 1520, which is necessary for DSA tagging
> > > protocols like "ocelot" and "seville".
> > 
> > Hi Colin
> > 
> > As far as your patch goes, it makes sense.
> > 
> > However, module parameters are unlikely by netdev maintainers. Having
> > to set one in order to make DSA work is not nice. What is involved in
> > actually removing the module parameter and making the MTU change work
> > without it?
> 
> Thanks for the feedback Andrew.
> 
> That's a good idea. I used the module parameter because it was already 
> there.

Yes, i understand the rational for what you did. KISS. But this is
also a chance to improve the code.

> My intent was to not change any existing default behavior. The below 
> forum post makes me think that simply changing the default value of 
> rx_packet_max from 1500 to 1998 alongside this patch is all that is 
> needed. It all seems too easy, so either my use-case is rare enough 
> that nobody considered it, or there's some limitation I'm missing.

Probably nobody has done it before. The internal switch for the cpsw
is probably enough for most users, and it is happy with the default
MTU. And anybody using jumbo seems to be happy to hack the driver and
not post the fix upstream?

I've not looked at what is actually required to make this dynamic.
Maybe you need to destroy all the descriptors and buffers and
re-create them?

[Goes an looks at the code]

On the RX side, it is using a page pool, order 0. So it looks like it
already supports MTU of 4K - overheads. And changing the default max
MTU costs nothing. And on the TX side, i don't see any restrictions.

I guess when the page pool was added, nobody considered what affect
this has on the module parameter, and the MTU. It looks like 99% of
the work is done to allow bigger MTU at no cost. But the devil is in
the details.

   Andrew
diff mbox series

Patch

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c0cd7de88316..d400163c4ef2 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1625,6 +1625,14 @@  static int cpsw_probe(struct platform_device *pdev)
 		goto clean_cpts;
 	}
 
+	/* adjust max_mtu to match module parameter rx_packet_max */
+	if (cpsw->rx_packet_max > CPSW_MAX_PACKET_SIZE) {
+		ndev->max_mtu = ETH_DATA_LEN + (cpsw->rx_packet_max -
+				CPSW_MAX_PACKET_SIZE);
+		dev_info(dev, "overriding default MTU to %d\n\n",
+			 ndev->max_mtu);
+	}
+
 	priv = netdev_priv(ndev);
 	priv->cpsw = cpsw;
 	priv->ndev = ndev;