All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: netdev@vger.kernel.org
Cc: "(JC), Jayachandran" <j-rameshbabu@ti.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Chintan Vankar <c-vankar@ti.com>,
	Danish Anwar <danishanwar@ti.com>, Daolin Qiu <d-qiu@ti.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Felix Maurer <fmaurer@redhat.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Neelima Muralidharan <neelima@ti.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Praneeth Bajjuri <praneeth@ti.com>,
	Pratheesh Gangadhar TK <pratheesh@ti.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Simon Horman <horms@kernel.org>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Subject: Re: [PATCH net-next v6 0/8] hsr: Add additional info to send/ receive skbs
Date: Fri, 25 Sep 2026 12:07:09 +0200	[thread overview]
Message-ID: <20260925100709.pybl7s3J@linutronix.de> (raw)
In-Reply-To: <20260923-hsr_ptp-v6-0-6ea07b3fb8a8@linutronix.de>

On 2026-09-23 14:14:01 [+0200], To netdev@vger.kernel.org wrote:
> I am trying to extend linuxptp to support PTP over a HSR network.
…

sashiko:
- #2
| Does this manual offset adjustment corrupt the hardware checksum offload offset?

Nothing sets ->ip_summed here. But the bot seems to be right here.

| Does this overly strict pull check drop valid small Ethernet frames?

after revisiting I tend to replace it with
		 if (!pskb_may_pull(skb, HSR_HLEN + movelen))
with
	         if (!pskb_may_pull(skb, movelen))

since the memmove() below only moves movelen bytes, so there is no need
to check for the HSR_HLEN which are in the headroom.

| Does this hardcoded offset corrupt the network_header for VLAN frames?
okay, will add the VLAN header.

- #3 
| Does this code break UAPI backward compatibility for standard userspace
| applications?

complains about the in-line header. Intended.

- #4
| Will packets arriving from a Single Attached Node (SAN) via the interlink
| port bypass the new PTP drop logic?

Yes. I guess it is okay to drop the PTP packets from SAN port, too.

| Does this check miss PTP packets encapsulated in VLANs or UDP/IP?

Yes. The specification does not mention UDP/IP for PTP packets. I will
ignore VLAN filtering for now.

- #5
| Does this code unconditionally drop standard L2 PTP traffic?

Complains about the in-line header again.

Let me fix that.

Sebastian

      parent reply	other threads:[~2026-09-25 10:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 12:14 [PATCH net-next v6 0/8] hsr: Add additional info to send/ receive skbs Sebastian Andrzej Siewior
2026-09-23 12:14 ` [PATCH net-next v6 1/8] hsr: Add header_ops::parse_protocol Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 2/8] hsr: Use skb_clone() while adding the HSR header Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 3/8] hsr: Add a magic header for sending PTP packets Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 4/8] hsr: Drop received " Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 5/8] hsr: Use the port and header information in hsr_forward_skb() Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 6/8] hsr: Assign a socket for cloned skbs Sebastian Andrzej Siewior
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-23 12:14 ` [PATCH net-next v6 7/8] hsr: Move struct hsr_ethhdr to a global header Sebastian Andrzej Siewior
2026-09-23 12:14 ` [PATCH net-next v6 8/8] selftests: hsr: Add test for the inline PTP header on HSR Sebastian Andrzej Siewior
2026-09-24  2:08   ` Hangbin Liu
2026-09-27 13:24   ` netdev-bot+sashiko
2026-09-25 10:07 ` Sebastian Andrzej Siewior [this message]

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=20260925100709.pybl7s3J@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=c-vankar@ti.com \
    --cc=d-qiu@ti.com \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmaurer@redhat.com \
    --cc=horms@kernel.org \
    --cc=j-rameshbabu@ti.com \
    --cc=kuba@kernel.org \
    --cc=neelima@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=praneeth@ti.com \
    --cc=pratheesh@ti.com \
    --cc=richardcochran@gmail.com \
    --cc=vigneshr@ti.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 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.