Netdev List
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Daniel Zahka <daniel.zahka@gmail.com>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Andrew Lunn <andrew+netdev@lunn.ch>,
	 "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	 Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 3/6] netdevsim: psp: move rx processing into nsim_poll()
Date: Mon, 11 May 2026 20:51:30 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.3467d6902b8a2@gmail.com> (raw)
In-Reply-To: <a3aff385-4c40-46e7-9ad9-d64f399750f6@gmail.com>

Daniel Zahka wrote:
> 
> On 5/11/26 4:03 PM, Willem de Bruijn wrote:
> > Daniel Zahka wrote:
> >> nsim_do_psp() does PSP decap and skb extension creation in the tx
> >> path. This has the slightly undesirable property of not allowing the
> >> psp rx code to run on PSP packets cooked up in userspace and
> >> transmitted on a packet socket from the peer dev (e.g. packetdrill).
> > Whether this happens in the nsim_start_xmit tx side handler directly
> > or is deferred to nsim_napi_rx is irrelevant, isn't it?
> 
> 
> You're right. The way netdevsim works, it is entirely immaterial. I'll 
> correct the erroneous commit message, but I still think having the decap 
> code in the napi_poll side makes a little bit more logical sense here.

Agreed
 
> 
> >> +/* Returns true if skb was consumed, false otherwise. */
> >> +bool nsim_psp_handle_rx(struct netdevsim *ns, struct sk_buff *skb)
> >> +{
> >> +	struct psp_dev *psd;
> >> +	struct psphdr *psph;
> >> +	struct udphdr *uh;
> >> +	int payload_len;
> >> +	u32 versions;
> >> +	int psp_off;
> >> +	bool is_udp;
> >> +	int l3_hlen;
> >> +	u8 version;
> >> +	u32 psd_id;
> >> +	int err;
> >> +
> >> +	if (skb->protocol == htons(ETH_P_IP)) {
> >> +		struct iphdr *iph;
> >> +
> >> +		if (!pskb_may_pull(skb, sizeof(struct iphdr)))
> >> +			return false;
> >> +
> >> +		iph = (struct iphdr *)skb->data;
> >> +		if (iph->ihl < 5)
> >> +			return false;
> >> +
> >> +		is_udp = iph->protocol == IPPROTO_UDP;
> >> +		l3_hlen = iph->ihl * 4;
> >> +	} else if (skb->protocol == htons(ETH_P_IPV6)) {
> >> +		struct ipv6hdr *ip6h;
> >> +
> >> +		if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
> >> +			return false;
> >> +		ip6h = (struct ipv6hdr *)skb->data;
> >> +		is_udp = ip6h->nexthdr == IPPROTO_UDP;
> >> +		l3_hlen = sizeof(struct ipv6hdr);
> >> +	} else {
> >> +		return false;
> >> +	}
> >> +
> >> +	if (!is_udp)
> >> +		return false;
> >> +
> >> +	if (!pskb_may_pull(skb, l3_hlen + sizeof(struct udphdr) + PSP_HDR_SIZE))
> >> +		return false;
> >> +
> >> +	uh = (struct udphdr *)(skb->data + l3_hlen);
> >> +	if (uh->dest != htons(PSP_DEFAULT_UDP_PORT))
> >> +		return false;
> >> +
> >> +	psph = (struct psphdr *)(uh + 1);
> >> +	version = FIELD_GET(PSPHDR_VERFL_VERSION, psph->verfl);
> > This seems to reimplement a lot of psp_dev_rcv. Is that needed?
> >
> > Is it a hint that this psp driver API needs some work?
> 
> 
> It could be. I'd have to split the parsing from the decap logic in 
> psp_dev_rcv(). I just wonder if another user of the two separate halves 
> other than netdevsim will come along.

Fair. Why does this driver need it. Only for that version check? If so,
can that move after the generic decap.

> 
> >> +	rcu_read_lock();
> >> +	psd = rcu_dereference(ns->psp.dev);
> >> +	if (psd) {
> >> +		versions = READ_ONCE(psd->config.versions);
> >> +		psd_id = psd->id;
> >> +	}
> >> +	rcu_read_unlock();
> >> +
> >> +	if (!psd || !(versions & (1 << version))) {
> >> +		skb->ip_summed = CHECKSUM_NONE;
> >> +		return false;
> >> +	}
> >> +
> >> +	psp_off = l3_hlen + sizeof(struct udphdr);
> >> +	payload_len = skb->len - psp_off - PSP_HDR_SIZE - PSP_TRL_SIZE;
> >> +	if (payload_len < 0)
> >> +		goto drop;
> >> +
> >> +	skb_push(skb, ETH_HLEN);
> >> +	skb->mac_len = ETH_HLEN;
> >> +	err = psp_dev_rcv(skb, psd_id, 0, false);
> >> +	if (err)
> >> +		goto drop;
> >> +
> >> +	skb_reset_mac_header(skb);
> >> +	skb_pull(skb, ETH_HLEN);
> > Similarly this is a bit of a hack, pushing and pulling a fake Ethernet
> > offset.
> >
> > And is this skb_reset_mac_header needed?
> 
> 
> skb_reset_mac_header() is needed because psp_dev_rcv() shifts the l2 and l3 headers forward, and the mac header has already been set. psp_dev_rcv() expects the mac header to be there. I hear what you're saying though. The driver api could probably handle these for us, but I also didn't want to overfit to netdevsim without another user. I'll explore some options before I post this again.

Ack, thanks. 



  reply	other threads:[~2026-05-12  0:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 14:53 [PATCH net-next 0/6] netdevsim: psp: implement real crypto operations from the PSP spec Daniel Zahka
2026-05-08 14:53 ` [PATCH net-next 1/6] netdevsim: psp: reset spi on key rotation and check for exhaustion on alloc Daniel Zahka
2026-05-11 16:53   ` Willem de Bruijn
2026-05-08 14:53 ` [PATCH net-next 2/6] netdevsim: psp: remove unnecessary UDP checksum computation Daniel Zahka
2026-05-11 17:01   ` Willem de Bruijn
2026-05-11 17:46     ` Daniel Zahka
2026-05-11 19:01       ` Willem de Bruijn
2026-05-11 19:43         ` Daniel Zahka
2026-05-08 14:53 ` [PATCH net-next 3/6] netdevsim: psp: move rx processing into nsim_poll() Daniel Zahka
2026-05-11 20:03   ` Willem de Bruijn
2026-05-12  0:25     ` Daniel Zahka
2026-05-12  0:51       ` Willem de Bruijn [this message]
2026-05-08 14:53 ` [PATCH net-next 4/6] netdevsim: psp: implement kdf from psp spec Daniel Zahka
2026-05-11 19:49   ` Willem de Bruijn
2026-05-11 23:55     ` Daniel Zahka
2026-05-12  0:48       ` Willem de Bruijn
2026-05-08 14:53 ` [PATCH net-next 5/6] netdevsim: psp: add real aes-gcm encryption and decryption Daniel Zahka
2026-05-11 20:10   ` Willem de Bruijn
2026-05-08 14:53 ` [PATCH net-next 6/6] netdevsim: psp: count rx authentication and length errors Daniel Zahka
2026-05-11 20:19   ` 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=willemdebruijn.kernel.3467d6902b8a2@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=daniel.zahka@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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