From: Vladimir Oltean <olteanv@gmail.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: Jason Xing <kerneljasonxing@gmail.com>,
irusskikh@marvell.com, andrew+netdev@lunn.ch, bharat@chelsio.com,
ayush.sawal@chelsio.com, UNGLinuxDriver@microchip.com,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, sgoutham@marvell.com,
willemb@google.com, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next v1 4/4] net: lan966x: generate software timestamp just before the doorbell
Date: Thu, 8 May 2025 17:21:57 +0300 [thread overview]
Message-ID: <20250508142157.sk7u37baqsl7yb64@skbuf> (raw)
In-Reply-To: <20250508094156.kbegdd5vianotsrr@DEN-DL-M31836.microchip.com>
Horatiu,
On Thu, May 08, 2025 at 11:41:56AM +0200, Horatiu Vultur wrote:
> > > > - skb_tx_timestamp(skb);
> > >
> > > Changing this will break the PHY timestamping because the frame gets
> > > modified in the next line, meaning that the classify function will
> > > always return PTP_CLASS_NONE.
> >
> > Sorry that I'm not that familiar with the details. I will remove it
> > from this series, but still trying to figure out what cases could be.
> >
> > Do you mean it can break when bpf prog is loaded because
> > 'skb_push(skb, IFH_LEN_BYTES);' expands the skb->data area?
>
> Well, the bpf program will check if it is a PTP frame that needs to be
> timestamp when it runs ptp_classify_raw, and as we push some data in
> front of the frame, the bpf will run from that point meaning that it
> would failed to detect the PTP frames.
>
> > May I ask
> > how the modified data of skb breaks the PHY timestamping feature?
>
> If it fails to detect that it is a PTP frame, then the frame will not be
> passed to the PHY using the callback txtstamp. So the PHY will timestamp the
> frame but it doesn't have the frame to attach the timestamp.
While I was further discussing this in private with Jason, a thought
popped up in my head.
Shouldn't skb_tx_timestamp(skb); be done _before_ this section?
/* skb processing */
needed_headroom = max_t(int, IFH_LEN_BYTES - skb_headroom(skb), 0);
needed_tailroom = max_t(int, ETH_FCS_LEN - skb_tailroom(skb), 0);
if (needed_headroom || needed_tailroom || skb_header_cloned(skb)) {
err = pskb_expand_head(skb, needed_headroom, needed_tailroom,
GFP_ATOMIC);
if (unlikely(err)) {
dev->stats.tx_dropped++;
err = NETDEV_TX_OK;
goto release;
}
}
The idea is that skb_tx_timestamp() calls skb_clone_tx_timestamp(), and
that should require skb_unshare() before you make any further
modification like insert an IFH here, so that the IFH is not visible to
clones (and thus to user space, on the socket error queue).
I think pskb_expand_head() serves the role of skb_unshare(), because I
see skb_header_cloned() is one of the conditions on which it is called.
But the problem is that skb_header_cloned() may have been false, then
skb_tx_timestamp() makes skb_header_cloned() true, but pskb_expand_head()
has already run. So the IFH is shared with the clone made for TX
timestamping purposes, I guess.
Am I completely off?
Also, I believe you can set dev->needed_headroom = IFH_LEN_BYTES,
dev->needed_tailroom = ETH_FCS_LEN, and then just call
skb_ensure_writable_head_tail().
next prev parent reply other threads:[~2025-05-08 15:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 3:33 [PATCH net-next v1 0/4] misc drivers' sw timestamp changes Jason Xing
2025-05-08 3:33 ` [PATCH net-next v1 1/4] net: atlantic: generate software timestamp just before the doorbell Jason Xing
2025-05-08 3:33 ` [PATCH net-next v1 2/4] net: cxgb4: " Jason Xing
2025-05-08 3:33 ` [PATCH net-next v1 3/4] net: stmmac: " Jason Xing
2025-05-08 3:33 ` [PATCH net-next v1 4/4] net: lan966x: " Jason Xing
2025-05-08 7:07 ` Horatiu Vultur
2025-05-08 8:40 ` Jason Xing
2025-05-08 9:41 ` Horatiu Vultur
2025-05-08 12:22 ` Jason Xing
2025-05-08 12:40 ` Vladimir Oltean
2025-05-08 14:16 ` Jason Xing
2025-05-08 14:21 ` Vladimir Oltean [this message]
2025-05-12 7:22 ` Horatiu Vultur
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=20250508142157.sk7u37baqsl7yb64@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=ayush.sawal@chelsio.com \
--cc=bharat@chelsio.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horatiu.vultur@microchip.com \
--cc=horms@kernel.org \
--cc=irusskikh@marvell.com \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sgoutham@marvell.com \
--cc=willemb@google.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