From: Vijay Khemka <vijaykhemka@fb.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"David S. Miller" <davem@davemloft.net>,
Kate Stewart <kstewart@linuxfoundation.org>,
"Sven Van Asbroeck" <TheSven73@gmail.com>,
Mark Brown <broonie@kernel.org>,
"Bhupesh Sharma" <bhsharma@redhat.com>,
YueHaibing <yuehaibing@huawei.com>,
"Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "openbmc @ lists . ozlabs . org" <openbmc@lists.ozlabs.org>,
"joel@jms.id.au" <joel@jms.id.au>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
Sai Dasari <sdasari@fb.com>
Subject: Re: [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500
Date: Fri, 18 Oct 2019 22:50:32 +0000 [thread overview]
Message-ID: <529EF9B4-DFDE-4DB7-BE26-3AED8D814134@fb.com> (raw)
In-Reply-To: <f6d5cb45a9aa167533135c5b218b45b1d210d31a.camel@kernel.crashing.org>
On 10/17/19, 5:33 PM, "Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
On Fri, 2019-10-18 at 00:06 +0000, Vijay Khemka wrote:
>
> > This is not a matter of unsupported csum, it is broken hw csum.
> > That's why we disable hw checksum. My guess is once we disable
> > Hw checksum, it will use sw checksum. So I am just disabling hw
> > Checksum.
>
> I don't understand what you are saying. You reported a problem with
> IPV6 checksums generation. The HW doesn't support it. What's "not a
> matter of unsupported csum" ?
>
> Your patch uses a *deprecated* bit to tell the network stack to only do
> HW checksum generation on IPV4.
>
> This bit is deprecated for a reason, again, see skbuff.h. The right
> approach, *which the driver already does*, is to tell the stack that we
> support HW checksuming using NETIF_F_HW_CSUM, and then, in the transmit
> handler, to call skb_checksum_help() to have the SW calculate the
> checksum if it's not a supported type.
>
> My understanding was when we enable NETIF_F_HW_CSUM means network
> stack enables HW checksum and doesn't calculate SW checksum. But as per
> this supported types HW checksum are used only for IPV4 and not for IPV6 even
> though driver enabled NETIF_F_HW_CSUM. For IPV6 it is always a SW generated
> checksum, please correct me here.
Have you actually read the comments in skbuff.h that I pointed you to ?
And the rest of my email for that matter ?
Yes, I went through comments in skbuff.h and your comments as well. I knew about
this deprecated bit that's why I have disabled NETIF_F_HW_CSUM completely in my
V1 patch. Then Florian gave a comment and asked me to disable only IPV6 not IPV4
as it is working for IPV4 and issue with only IPV6. That's why I sent patch V2
accommodating his feedback.
I don't have much understanding of IP Stack but I went through code details and
you are right and found that it should fallback to SW calculation for IPV6 but it doesn't
happen because ftgmac100_hard_start_xmit checks for CHECKSUM_PARTIAL before
setting HW checksum and calling ftgmac100_prep_tx_csum function. And in my
understanding, this value is set CHECKSUM_PARTIAL in IP stack. I looked up IP stack for
IPV6, file net/ipv6/ip6_output.c, function __ip6_append_data: here it sets
CHECKSUM_PARTIAL only for UDP packets not for TCP packets. Please look at line
number 1880. This could be an issue we are seeing here as why
ftgmac100_prep_tx_csum is not getting triggered for IPV6 with TCP. Please correct
me if my understanding is wrong.
> This is exactly what ftgmac100_prep_tx_csum() does. It only enables HW
> checksum generation on supported types and uses skb_checksum_help()
> otherwise, supported types being protocol ETH_P_IP and IP protocol
> being raw IP, TCP and UDP.
>
>
> So this *should* have fallen back to SW for IPV6. So either something
> in my code there is making an incorrect assumption, or something is
> broken in skb_checksum_help() for IPV6 (which I somewhat doubt) or
> something else I can't think of, but setting a *deprecated* flag is
> definitely not the right answer, neither is completely disabling HW
> checksumming.
>
> So can you investigate what's going on a bit more closely please ? I
> can try myself, though I have very little experience with IPV6 and
> probably won't have time before next week.
>
> Cheers,
> Ben.
>
> > The driver should have handled unsupported csum via SW fallback
> > already in ftgmac100_prep_tx_csum()
> >
> > Can you check why this didn't work for you ?
> >
> > Cheers,
> > Ben.
> >
> > > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > > ---
> > > Changes since v1:
> > > Enabled IPV4 hw checksum generation as it works for IPV4.
> > >
> > > drivers/net/ethernet/faraday/ftgmac100.c | 13 ++++++++++++-
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> > > b/drivers/net/ethernet/faraday/ftgmac100.c
> > > index 030fed65393e..0255a28d2958 100644
> > > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > > @@ -1842,8 +1842,19 @@ 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;
> > > +
> > > + /* AST2500 doesn't have working HW checksum generation for IPV6
> > > + * but it works for IPV4, so disabling hw checksum and enabling
> > > + * it for only IPV4.
> > > + */
> > > + if (np && (of_device_is_compatible(np, "aspeed,ast2500-mac")))
> > > {
> > > + netdev->hw_features &= ~NETIF_F_HW_CSUM;
> > > + netdev->hw_features |= NETIF_F_IP_CSUM;
> > > + }
> > > +
> > > if (np && of_get_property(np, "no-hw-checksum", NULL))
> > > - netdev->hw_features &= ~(NETIF_F_HW_CSUM |
> > > NETIF_F_RXCSUM);
> > > + netdev->hw_features &= ~(NETIF_F_HW_CSUM |
> > > NETIF_F_RXCSUM
> > > + | NETIF_F_IP_CSUM);
> > > netdev->features |= netdev->hw_features;
> > >
> > > /* register network device */
> >
> >
> >
>
>
>
next prev parent reply other threads:[~2019-10-18 22:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191011213027.2110008-1-vijaykhemka@fb.com>
2019-10-17 1:28 ` [PATCH v2] ftgmac100: Disable HW checksum generation on AST2500 Benjamin Herrenschmidt
2019-10-17 22:01 ` Vijay Khemka
2019-10-17 23:14 ` Benjamin Herrenschmidt
2019-10-17 23:34 ` Benjamin Herrenschmidt
2019-10-18 0:06 ` Vijay Khemka
2019-10-18 0:32 ` Benjamin Herrenschmidt
2019-10-18 22:50 ` Vijay Khemka [this message]
2019-10-19 0:03 ` Benjamin Herrenschmidt
2019-10-19 1:31 ` Vijay Khemka
2019-10-19 10:25 ` Benjamin Herrenschmidt
[not found] <20190911194453.2595021-1-vijaykhemka@fb.com>
2019-09-17 19:34 ` Vijay Khemka
2019-09-24 17:26 ` Vijay Khemka
2019-10-10 19:20 ` Vijay Khemka
2019-10-11 1:16 ` Jakub Kicinski
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=529EF9B4-DFDE-4DB7-BE26-3AED8D814134@fb.com \
--to=vijaykhemka@fb.com \
--cc=TheSven73@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=bhsharma@redhat.com \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=joel@jms.id.au \
--cc=kstewart@linuxfoundation.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=sdasari@fb.com \
--cc=tglx@linutronix.de \
--cc=yuehaibing@huawei.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).