Netdev List
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Michal Kubiak <michal.kubiak@intel.com>,
	Larysa Zaremba <larysa.zaremba@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC net-next 01/34] idpf: reuse libie's definitions of parsed ptype structures
Date: Mon, 8 Jan 2024 17:04:16 +0100	[thread overview]
Message-ID: <9e8e8b47-24ab-4947-8f22-f2a07c2549ca@intel.com> (raw)
In-Reply-To: <658c46269aa52_a33e629442@willemb.c.googlers.com.notmuch>

From: Willem De Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 27 Dec 2023 10:43:34 -0500

> Alexander Lobakin wrote:
>> idpf's in-kernel parsed ptype structure is almost identical to the one
>> used in the previous Intel drivers, which means it can be converted to
>> use libie's definitions and even helpers. The only difference is that
>> it doesn't use a constant table, rather than one obtained from the
>> device.

[...]

>>  static void idpf_rx_singleq_csum(struct idpf_queue *rxq, struct sk_buff *skb,
>> -				 struct idpf_rx_csum_decoded *csum_bits,
>> -				 u16 ptype)
>> +				 struct idpf_rx_csum_decoded csum_bits,
>> +				 struct libie_rx_ptype_parsed parsed)
>>  {
>> -	struct idpf_rx_ptype_decoded decoded;
>>  	bool ipv4, ipv6;
>>  
>>  	/* check if Rx checksum is enabled */
>> -	if (unlikely(!(rxq->vport->netdev->features & NETIF_F_RXCSUM)))
>> +	if (!libie_has_rx_checksum(rxq->vport->netdev, parsed))
>>  		return;
>>  
>>  	/* check if HW has decoded the packet and checksum */
>> -	if (unlikely(!(csum_bits->l3l4p)))
>> +	if (unlikely(!csum_bits.l3l4p))
>>  		return;
>>  
>> -	decoded = rxq->vport->rx_ptype_lkup[ptype];
>> -	if (unlikely(!(decoded.known && decoded.outer_ip)))
>> +	if (unlikely(parsed.outer_ip == LIBIE_RX_PTYPE_OUTER_L2))
>>  		return;
>>  
>> -	ipv4 = IDPF_RX_PTYPE_TO_IPV(&decoded, IDPF_RX_PTYPE_OUTER_IPV4);
>> -	ipv6 = IDPF_RX_PTYPE_TO_IPV(&decoded, IDPF_RX_PTYPE_OUTER_IPV6);
>> +	ipv4 = parsed.outer_ip == LIBIE_RX_PTYPE_OUTER_IPV4;
>> +	ipv6 = parsed.outer_ip == LIBIE_RX_PTYPE_OUTER_IPV6;
>>  
>>  	/* Check if there were any checksum errors */
>> -	if (unlikely(ipv4 && (csum_bits->ipe || csum_bits->eipe)))
>> +	if (unlikely(ipv4 && (csum_bits.ipe || csum_bits.eipe)))
>>  		goto checksum_fail;
>>  
>>  	/* Device could not do any checksum offload for certain extension
>>  	 * headers as indicated by setting IPV6EXADD bit
>>  	 */
>> -	if (unlikely(ipv6 && csum_bits->ipv6exadd))
>> +	if (unlikely(ipv6 && csum_bits.ipv6exadd))
>>  		return;
>>  
>>  	/* check for L4 errors and handle packets that were not able to be
>>  	 * checksummed due to arrival speed
>>  	 */
>> -	if (unlikely(csum_bits->l4e))
>> +	if (unlikely(csum_bits.l4e))
>>  		goto checksum_fail;
>>  
>> -	if (unlikely(csum_bits->nat && csum_bits->eudpe))
>> +	if (unlikely(csum_bits.nat && csum_bits.eudpe))
>>  		goto checksum_fail;
>>  
>>  	/* Handle packets that were not able to be checksummed due to arrival
>>  	 * speed, in this case the stack can compute the csum.
>>  	 */
>> -	if (unlikely(csum_bits->pprs))
>> +	if (unlikely(csum_bits.pprs))
>>  		return;
>>  
>>  	/* If there is an outer header present that might contain a checksum
>>  	 * we need to bump the checksum level by 1 to reflect the fact that
>>  	 * we are indicating we validated the inner checksum.
>>  	 */
>> -	if (decoded.tunnel_type >= IDPF_RX_PTYPE_TUNNEL_IP_GRENAT)
>> +	if (parsed.tunnel_type >= LIBIE_RX_PTYPE_TUNNEL_IP_GRENAT)
>>  		skb->csum_level = 1;
>>  
>> -	/* Only report checksum unnecessary for ICMP, TCP, UDP, or SCTP */
>> -	switch (decoded.inner_prot) {
>> -	case IDPF_RX_PTYPE_INNER_PROT_ICMP:
>> -	case IDPF_RX_PTYPE_INNER_PROT_TCP:
>> -	case IDPF_RX_PTYPE_INNER_PROT_UDP:
>> -	case IDPF_RX_PTYPE_INNER_PROT_SCTP:
>> -		skb->ip_summed = CHECKSUM_UNNECESSARY;
>> -		return;
>> -	default:
>> -		return;
>> -	}
>> +	skb->ip_summed = CHECKSUM_UNNECESSARY;
>> +	return;
> 
> Is it intentional to change from CHECKSUM_NONE to CHECKSUM_UNNECESSARY
> in the default case?

The basic logic wasn't changed. libie_has_rx_checksum() checks if the
protocol can be checksummed by HW at the beginning of the function
instead of the end (why calculate and check all this if the proto is not
supported?).

> 
> I suppose so, as idpf_rx_csum (the splitq equivalent) does the same
> (bar CHECKSUM_COMPLETE depending on descriptor bit).

Thanks,
Olek

  reply	other threads:[~2024-01-08 16:04 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-23  2:55 [PATCH RFC net-next 00/34] Christmas 3-serie XDP for idpf (+generic stuff) Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 01/34] idpf: reuse libie's definitions of parsed ptype structures Alexander Lobakin
2023-12-27 15:43   ` Willem de Bruijn
2024-01-08 16:04     ` Alexander Lobakin [this message]
2023-12-23  2:55 ` [PATCH RFC net-next 02/34] idpf: pack &idpf_queue way more efficiently Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 03/34] idpf: remove legacy Page Pool Ethtool stats Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 04/34] libie: support different types of buffers for Rx Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 05/34] idpf: convert header split mode to libie + napi_build_skb() Alexander Lobakin
2023-12-27 15:30   ` Willem de Bruijn
2024-01-08 16:17     ` Alexander Lobakin
2024-01-09 13:59       ` Willem de Bruijn
2024-01-11 13:09         ` Alexander Lobakin
2024-01-09 14:43   ` Eric Dumazet
2023-12-23  2:55 ` [PATCH RFC net-next 06/34] idpf: use libie Rx buffer management for payload buffer Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 07/34] libie: add Tx buffer completion helpers Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 08/34] idpf: convert to libie Tx buffer completion Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 09/34] bpf, xdp: constify some bpf_prog * function arguments Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 10/34] xdp: constify read-only arguments of some static inline helpers Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 11/34] xdp: allow attaching already registered memory model to xdp_rxq_info Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 12/34] xdp: add generic xdp_buff_add_frag() Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 13/34] xdp: add generic xdp_build_skb_from_buff() Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 14/34] xdp: get rid of xdp_frame::mem.id Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 15/34] page_pool: add inline helper to sync VA for device (for XDP_TX) Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 16/34] jump_label: export static_key_slow_{inc,dec}_cpuslocked() Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 17/34] libie: support native XDP and register memory model Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 18/34] libie: add a couple of XDP helpers Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 19/34] idpf: stop using macros for accessing queue descriptors Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 20/34] idpf: make complq cleaning dependent on scheduling mode Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 21/34] idpf: prepare structures to support xdp Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 22/34] idpf: implement XDP_SETUP_PROG in ndo_bpf for splitq Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 23/34] idpf: use generic functions to build xdp_buff and skb Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 24/34] idpf: add support for XDP on Rx Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 25/34] idpf: add support for .ndo_xdp_xmit() Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 26/34] xdp: add generic XSk xdp_buff -> skb conversion Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 27/34] idpf: add support for sw interrupt Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 28/34] idpf: add relative queue id member to idpf_queue Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 29/34] idpf: add vc functions to manage selected queues Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 30/34] idpf: move search rx and tx queues to header Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 31/34] idpf: add XSk pool initialization Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 32/34] idpf: implement Tx path for AF_XDP Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 33/34] idpf: implement Rx " Alexander Lobakin
2023-12-23  2:55 ` [PATCH RFC net-next 34/34] idpf: enable XSk features and ndo_xsk_wakeup Alexander Lobakin
2023-12-26 20:23 ` [PATCH RFC net-next 00/34] Christmas 3-serie XDP for idpf (+generic stuff) Willem de Bruijn
2024-01-08 16:01   ` Alexander Lobakin
2024-01-08 16:09     ` Willem de Bruijn

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=9e8e8b47-24ab-4947-8f22-f2a07c2549ca@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemdebruijn.kernel@gmail.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