All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Wei Fang <wei.fang@nxp.com>, tom@herbertland.com
Cc: Simon Horman <horms@kernel.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Clark Wang <xiaoning.wang@nxp.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	Frank Li <frank.li@nxp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"imx@lists.linux.dev" <imx@lists.linux.dev>
Subject: Re: [PATCH v6 RESEND net-next 1/5] net: enetc: add Rx checksum offload for i.MX95 ENETC
Date: Sun, 8 Dec 2024 17:47:29 +0200	[thread overview]
Message-ID: <Z1W_kSMUp3lsLPr_@shredder> (raw)
In-Reply-To: <PAXPR04MB85107FD857F1AB33BBE4F70988312@PAXPR04MB8510.eurprd04.prod.outlook.com>

On Fri, Dec 06, 2024 at 12:45:02PM +0000, Wei Fang wrote:
> > -----Original Message-----
> > From: Simon Horman <horms@kernel.org>
> > Sent: 2024年12月6日 20:31
> > To: Wei Fang <wei.fang@nxp.com>
> > Cc: Claudiu Manoil <claudiu.manoil@nxp.com>; Vladimir Oltean
> > <vladimir.oltean@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>;
> > andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> > kuba@kernel.org; pabeni@redhat.com; Frank Li <frank.li@nxp.com>;
> > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> > Subject: Re: [PATCH v6 RESEND net-next 1/5] net: enetc: add Rx checksum
> > offload for i.MX95 ENETC
> > 
> > On Fri, Dec 06, 2024 at 10:33:15AM +0000, Wei Fang wrote:
> > > > -----Original Message-----
> > > > From: Simon Horman <horms@kernel.org>
> > > > Sent: 2024年12月6日 17:23
> > > > To: Wei Fang <wei.fang@nxp.com>
> > > > Cc: Claudiu Manoil <claudiu.manoil@nxp.com>; Vladimir Oltean
> > > > <vladimir.oltean@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>;
> > > > andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> > > > kuba@kernel.org; pabeni@redhat.com; Frank Li <frank.li@nxp.com>;
> > > > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> > > > Subject: Re: [PATCH v6 RESEND net-next 1/5] net: enetc: add Rx checksum
> > > > offload for i.MX95 ENETC
> > > >
> > > > On Wed, Dec 04, 2024 at 01:29:28PM +0800, Wei Fang wrote:
> > > > > ENETC rev 4.1 supports TCP and UDP checksum offload for receive, the bit
> > > > > 108 of the Rx BD will be set if the TCP/UDP checksum is correct. Since
> > > > > this capability is not defined in register, the rx_csum bit is added to
> > > > > struct enetc_drvdata to indicate whether the device supports Rx
> > checksum
> > > > > offload.
> > > > >
> > > > > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > > > > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > > > > Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> > > > > ---
> > > > > v2: no changes
> > > > > v3: no changes
> > > > > v4: no changes
> > > > > v5: no changes
> > > > > v6: no changes
> > > > > ---
> > > > >  drivers/net/ethernet/freescale/enetc/enetc.c       | 14
> > ++++++++++----
> > > > >  drivers/net/ethernet/freescale/enetc/enetc.h       |  2 ++
> > > > >  drivers/net/ethernet/freescale/enetc/enetc_hw.h    |  2 ++
> > > > >  .../net/ethernet/freescale/enetc/enetc_pf_common.c |  3 +++
> > > > >  4 files changed, 17 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c
> > > > b/drivers/net/ethernet/freescale/enetc/enetc.c
> > > > > index 35634c516e26..3137b6ee62d3 100644
> > > > > --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> > > > > +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> > > > > @@ -1011,10 +1011,15 @@ static void enetc_get_offloads(struct
> > enetc_bdr
> > > > *rx_ring,
> > > > >
> > > > >  	/* TODO: hashing */
> > > > >  	if (rx_ring->ndev->features & NETIF_F_RXCSUM) {
> > > > > -		u16 inet_csum = le16_to_cpu(rxbd->r.inet_csum);
> > > > > -
> > > > > -		skb->csum = csum_unfold((__force
> > __sum16)~htons(inet_csum));
> > > > > -		skb->ip_summed = CHECKSUM_COMPLETE;
> > > > > +		if (priv->active_offloads & ENETC_F_RXCSUM &&
> > > > > +		    le16_to_cpu(rxbd->r.flags) &
> > ENETC_RXBD_FLAG_L4_CSUM_OK)
> > > > {
> > > > > +			skb->ip_summed = CHECKSUM_UNNECESSARY;
> > > > > +		} else {
> > > > > +			u16 inet_csum = le16_to_cpu(rxbd->r.inet_csum);
> > > > > +
> > > > > +			skb->csum = csum_unfold((__force
> > __sum16)~htons(inet_csum));
> > > > > +			skb->ip_summed = CHECKSUM_COMPLETE;
> > > > > +		}
> > > > >  	}
> > > >
> > > > Hi Wei,
> > > >
> > > > I am wondering about the relationship between the above and
> > > > hardware support for CHECKSUM_COMPLETE.
> > > >
> > > > Prior to this patch CHECKSUM_COMPLETE was always used, which seems
> > > > desirable. But with this patch, CHECKSUM_UNNECESSARY is conditionally
> > used.
> > > >
> > > > If those cases don't work with CHECKSUM_COMPLETE then is this a
> > bug-fix?
> > > >
> > > > Or, alternatively, if those cases do work with CHECKSUM_COMPLETE, then
> > > > I'm unsure why this change is necessary or desirable. It's my understanding
> > > > that from the Kernel's perspective CHECKSUM_COMPLETE is preferable to
> > > > CHECKSUM_UNNECESSARY.
> > > >
> > > > ...
> > >
> > > Rx checksum offload is a new feature of ENETC v4. We would like to exploit
> > this
> > > capability of the hardware to save CPU cycles in calculating and verifying
> > checksum.
> > >
> > 
> > Understood, but CHECKSUM_UNNECESSARY is usually the preferred option as
> > it
> > is more flexible, e.g. allowing low-cost calculation of inner checksums
> > in the presence of encapsulation.
> 
> I think you mean 'CHECKSUM_COMPLETE' is the preferred option. But there is no
> strong reason against using CHECKSUM_UNNECESSARY. So I hope to keep this patch.

I was also under the impression that CHECKSUM_COMPLETE is more desirable
than CHECKSUM_UNNECESSARY. Maybe Tom can help.

Tom:

If a device can report both CHECKSUM_UNNECESSARY and CHECKSUM_COMPLETE,
is there any advantage in reporting CHECKSUM_UNNECESSARY? The only
advantage I can think of is that when the kernel pulls headers (IPv6 for
example) it wouldn't need to compute their checksum in order to adjust
skb->csum, but I am not sure how critical that is.

I am asking because I am interested in knowing what is the
recommendation for future devices: Implement both or only
CHECKSUM_COMPLETE?

Original patch is here [1] and I did read your paper [2] and David's
presentation [3].

Thanks

[1] https://lore.kernel.org/netdev/20241204052932.112446-1-wei.fang@nxp.com/T/#mf89bb4c6c72e8dd4a697551cbc9485217366d013
[2] https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf
[3] https://www.netdevconf.info/1.1/proceedings/slides/miller-hardware-checksumming.pdf

  reply	other threads:[~2024-12-08 15:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04  5:29 [PATCH v6 RESEND net-next 0/5] Add more feautues for ENETC v4 - round 1 Wei Fang
2024-12-04  5:29 ` [PATCH v6 RESEND net-next 1/5] net: enetc: add Rx checksum offload for i.MX95 ENETC Wei Fang
2024-12-06  9:23   ` Simon Horman
2024-12-06 10:33     ` Wei Fang
2024-12-06 12:30       ` Simon Horman
2024-12-06 12:45         ` Wei Fang
2024-12-08 15:47           ` Ido Schimmel [this message]
2024-12-10  7:49             ` Wei Fang
2024-12-10 20:07               ` Simon Horman
2024-12-04  5:29 ` [PATCH v6 RESEND net-next 2/5] net: enetc: add Tx " Wei Fang
2024-12-06  9:37   ` Simon Horman
2024-12-06 10:46     ` Wei Fang
2024-12-06 12:32       ` Simon Horman
2024-12-06 12:38         ` Wei Fang
2024-12-06 13:31           ` Simon Horman
2024-12-04  5:29 ` [PATCH v6 RESEND net-next 3/5] net: enetc: update max chained Tx BD number " Wei Fang
2024-12-06 10:11   ` Simon Horman
2024-12-04  5:29 ` [PATCH v6 RESEND net-next 4/5] net: enetc: add LSO support for i.MX95 ENETC PF Wei Fang
2024-12-06  9:59   ` Simon Horman
2024-12-06 10:33     ` Simon Horman
2024-12-04  5:29 ` [PATCH v6 RESEND net-next 5/5] net: enetc: add UDP segmentation offload support Wei Fang
2024-12-08 15:09   ` Ido Schimmel
2024-12-08 15:54     ` Eric Dumazet

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=Z1W_kSMUp3lsLPr_@shredder \
    --to=idosch@idosch.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=frank.li@nxp.com \
    --cc=horms@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tom@herbertland.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=wei.fang@nxp.com \
    --cc=xiaoning.wang@nxp.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.