archive mirror
 help / color / mirror / Atom feed
From: David Ahern <>
To: Tom Herbert <>, Lorenzo Bianconi <>
	"Linux Kernel Network Developers" <>,
	"David S. Miller" <>,
	"Jakub Kicinski" <>,
	"Daniel Borkmann" <>,
	"Alexei Starovoitov" <>,
	"Eelco Chaudron" <>,,
	"Toke Høiland-Jørgensen" <>,
	"Jesper Dangaard Brouer" <>,,
	"Maciej Fijałkowski (Intel)" <>,
	"john fastabend" <>
Subject: Re: [RFC bpf-next 1/4] net: xdp: introduce flags field in xdp_buff and xdp_frame
Date: Fri, 28 May 2021 19:33:15 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 5/28/21 3:18 PM, Tom Herbert wrote:
> On Fri, May 28, 2021 at 10:44 AM Lorenzo Bianconi <> wrote:
>> Introduce flag field in xdp_buff and xdp_frame data structure in order
>> to report xdp_buffer metadata. For the moment just hw checksum hints
>> are defined but flags field will be reused for xdp multi-buffer
>> For the moment just CHECKSUM_UNNECESSARY is supported.
>> CHECKSUM_COMPLETE will need to set csum value in metada space.
> Lorenzo,
> This isn't sufficient for the checksum-unnecessary interface, we'd
> also need ability to set csum_level for cases the device validated
> more than one checksum.

That's on me. The original patch was for XDP_REDIRECT to VMs and the
VIRTIO_NET_HDR_ API does not support csum_level.
implemented 10 years ago.

> IMO, we shouldn't support CHECKSUM_UNNECESSARY for new uses like this.
> For years now, the Linux community has been pleading with vendors to
> provide CHECKSUM_COMPLETE which is far more useful and robust than
> CHECSUM_UNNECESSARY, and yet some still haven't got with the program
> even though we see more and more instances where CHECKSUM_UNNECESSARY
> doesn't even work at all (e.g. cases with SRv6, new encaps device
> doesn't understand). I believe it's time to take a stand! :-)

There is no new hardware or new feature at play here. This about XDP
frames getting the checksum validation setting that an skb enjoys today.
You are taking a stand against S/W equivalency with the existing NICs?
That basically penalizes XDP, continuing to limit its usefulness with
very well established use cases that could benefit from it.

  reply	other threads:[~2021-05-29  1:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-28 17:43 [RFC bpf-next 0/4] add partial rx hw csum offload support for XDP Lorenzo Bianconi
2021-05-28 17:43 ` [RFC bpf-next 1/4] net: xdp: introduce flags field in xdp_buff and xdp_frame Lorenzo Bianconi
2021-05-28 21:18   ` Tom Herbert
2021-05-29  1:33     ` David Ahern [this message]
2021-05-29  4:56     ` Jakub Kicinski
2021-05-29 13:37       ` Lorenzo Bianconi
2021-05-29 13:34     ` Lorenzo Bianconi
2021-05-31 11:07       ` Jesper Dangaard Brouer
2021-05-28 17:43 ` [RFC bpf-next 2/4] mvneta: return csum computation result from mvneta_rx_csum Lorenzo Bianconi
2021-05-28 17:43 ` [RFC bpf-next 3/4] net: mvneta: report csum result in xdp_buff Lorenzo Bianconi
2021-05-28 17:43 ` [RFC bpf-next 4/4] net: xdp: update csum building the skb Lorenzo Bianconi
2021-05-28 18:01 ` [RFC bpf-next 0/4] add partial rx hw csum offload support for XDP David Ahern

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).