All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Joel Stanley <joel@jms.id.au>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Dylan Hung <dylan_hung@aspeedtech.com>,
	David Wilder <dwilder@us.ibm.com>,
	netdev@vger.kernel.org, openbmc@lists.ozlabs.org,
	David Wilder <wilder@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: ftgmac100: Disable hardware checksum on AST2600
Date: Fri, 13 May 2022 07:11:25 +0200	[thread overview]
Message-ID: <b6da2e5a-eb85-d3cf-d4c3-ca9c0f0c04a4@molgen.mpg.de> (raw)
In-Reply-To: <20220512231938.228651-1-joel@jms.id.au>

Dear Joel,


Am 13.05.22 um 01:19 schrieb Joel Stanley:
> The AST2600 when using the i210 NIC over NC-SI has been observed to
> produce incorrect checksum results with specific MTU values. This was
> first observed when sending data across a long distance set of networks.
> 
> On a local network, the following test was performed using a 1MB file of
> random data.
> 
> On the receiver run this script:
> 
>   #!/bin/bash
>   while [ 1 ]; do
>          # Zero the stats
>          nstat -r  > /dev/null
>          nc -l 9899 > test-file
>          # Check for checksum errors
>          TcpInCsumErrors=$(nstat | grep TcpInCsumErrors)
>          if [ -z "$TcpInCsumErrors" ]; then
>                  echo No TcpInCsumErrors
>          else
>                  echo TcpInCsumErrors = $TcpInCsumErrors
>          fi
>   done
> 
> On an AST2600 system:
> 
>   # nc <IP of  receiver host> 9899 < test-file
> 
> The test was repeated with various MTU values:
> 
>   # ip link set mtu 1410 dev eth0
> 
> The observed results:
> 
>   1500 - good
>   1434 - bad
>   1400 - good
>   1410 - bad
>   1420 - good

Sort the values? As some MTUs are good, should a allow list for these 
values be added?

> The test was repeated after disabling tx checksumming:
> 
>   # ethtool -K eth0 tx-checksumming off
> 
> And all MTU values tested resulted in transfers without error.
> 
> An issue with the driver cannot be ruled out, however there has been no
> bug discovered so far.
> 
> David has done the work to take the original bug report of slow data
> transfer between long distance connections and triaged it down to this
> test case.
> 
> The vendor suspects this this is a hardware issue when using NC-SI. The fixes line refers
> to the patch that introduced AST2600 support.

Please wrap the line after 75 characters.

Can the problem be reproduced with QEMU?

> Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property")
> Reported-by: David Wilder <wilder@us.ibm.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>

Should the intel-wired-lan folks be put in Cc?

> ---
> v2 updates the commit message with confirmation form the vendor that

from

> this is a hardware issue, and clarifes why the commit used in the fixes

clarifies

> tag was chosen.
> 
>   drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
> index caf48023f8ea..5231818943c6 100644
> --- a/drivers/net/ethernet/faraday/ftgmac100.c
> +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> @@ -1928,6 +1928,11 @@ static int ftgmac100_probe(struct platform_device *pdev)
>   	/* AST2400  doesn't have working HW checksum generation */
>   	if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac")))
>   		netdev->hw_features &= ~NETIF_F_HW_CSUM;
> +
> +	/* AST2600 tx checksum with NC-SI is broken */

Does ASPEED have an internal bug for this, so should there be new 
revisions of the AST2600, the bug can be fixed?

> +	if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac"))
> +		netdev->hw_features &= ~NETIF_F_HW_CSUM;
> +

I would fancy a note or even warning about this hardware issue.

>   	if (np && of_get_property(np, "no-hw-checksum", NULL))
>   		netdev->hw_features &= ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM);
>   	netdev->features |= netdev->hw_features;


Kind regards,

Paul

WARNING: multiple messages have this Message-ID (diff)
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Joel Stanley <joel@jms.id.au>
Cc: David Wilder <dwilder@us.ibm.com>,
	openbmc@lists.ozlabs.org, David Wilder <wilder@us.ibm.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Jakub Kicinski <kuba@kernel.org>,
	Dylan Hung <dylan_hung@aspeedtech.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH net v2] net: ftgmac100: Disable hardware checksum on AST2600
Date: Fri, 13 May 2022 07:11:25 +0200	[thread overview]
Message-ID: <b6da2e5a-eb85-d3cf-d4c3-ca9c0f0c04a4@molgen.mpg.de> (raw)
In-Reply-To: <20220512231938.228651-1-joel@jms.id.au>

Dear Joel,


Am 13.05.22 um 01:19 schrieb Joel Stanley:
> The AST2600 when using the i210 NIC over NC-SI has been observed to
> produce incorrect checksum results with specific MTU values. This was
> first observed when sending data across a long distance set of networks.
> 
> On a local network, the following test was performed using a 1MB file of
> random data.
> 
> On the receiver run this script:
> 
>   #!/bin/bash
>   while [ 1 ]; do
>          # Zero the stats
>          nstat -r  > /dev/null
>          nc -l 9899 > test-file
>          # Check for checksum errors
>          TcpInCsumErrors=$(nstat | grep TcpInCsumErrors)
>          if [ -z "$TcpInCsumErrors" ]; then
>                  echo No TcpInCsumErrors
>          else
>                  echo TcpInCsumErrors = $TcpInCsumErrors
>          fi
>   done
> 
> On an AST2600 system:
> 
>   # nc <IP of  receiver host> 9899 < test-file
> 
> The test was repeated with various MTU values:
> 
>   # ip link set mtu 1410 dev eth0
> 
> The observed results:
> 
>   1500 - good
>   1434 - bad
>   1400 - good
>   1410 - bad
>   1420 - good

Sort the values? As some MTUs are good, should a allow list for these 
values be added?

> The test was repeated after disabling tx checksumming:
> 
>   # ethtool -K eth0 tx-checksumming off
> 
> And all MTU values tested resulted in transfers without error.
> 
> An issue with the driver cannot be ruled out, however there has been no
> bug discovered so far.
> 
> David has done the work to take the original bug report of slow data
> transfer between long distance connections and triaged it down to this
> test case.
> 
> The vendor suspects this this is a hardware issue when using NC-SI. The fixes line refers
> to the patch that introduced AST2600 support.

Please wrap the line after 75 characters.

Can the problem be reproduced with QEMU?

> Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property")
> Reported-by: David Wilder <wilder@us.ibm.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>

Should the intel-wired-lan folks be put in Cc?

> ---
> v2 updates the commit message with confirmation form the vendor that

from

> this is a hardware issue, and clarifes why the commit used in the fixes

clarifies

> tag was chosen.
> 
>   drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
> index caf48023f8ea..5231818943c6 100644
> --- a/drivers/net/ethernet/faraday/ftgmac100.c
> +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> @@ -1928,6 +1928,11 @@ static int ftgmac100_probe(struct platform_device *pdev)
>   	/* AST2400  doesn't have working HW checksum generation */
>   	if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac")))
>   		netdev->hw_features &= ~NETIF_F_HW_CSUM;
> +
> +	/* AST2600 tx checksum with NC-SI is broken */

Does ASPEED have an internal bug for this, so should there be new 
revisions of the AST2600, the bug can be fixed?

> +	if (priv->use_ncsi && of_device_is_compatible(np, "aspeed,ast2600-mac"))
> +		netdev->hw_features &= ~NETIF_F_HW_CSUM;
> +

I would fancy a note or even warning about this hardware issue.

>   	if (np && of_get_property(np, "no-hw-checksum", NULL))
>   		netdev->hw_features &= ~(NETIF_F_HW_CSUM | NETIF_F_RXCSUM);
>   	netdev->features |= netdev->hw_features;


Kind regards,

Paul

  parent reply	other threads:[~2022-05-13  5:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 23:19 [PATCH net v2] net: ftgmac100: Disable hardware checksum on AST2600 Joel Stanley
2022-05-12 23:19 ` Joel Stanley
2022-05-13  1:46 ` Dylan Hung
2022-05-13  1:46   ` Dylan Hung
2022-05-17  9:20   ` Joel Stanley
2022-05-17  9:20     ` Joel Stanley
2022-05-13  5:11 ` Paul Menzel [this message]
2022-05-13  5:11   ` Paul Menzel
2022-05-17  9:19   ` Joel Stanley
2022-05-17  9:19     ` Joel Stanley

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=b6da2e5a-eb85-d3cf-d4c3-ca9c0f0c04a4@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=dwilder@us.ibm.com \
    --cc=dylan_hung@aspeedtech.com \
    --cc=joel@jms.id.au \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=pabeni@redhat.com \
    --cc=wilder@us.ibm.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.