From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Furong Xu <0x1207@gmail.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
Serge Semin <fancer.lancer@gmail.com>,
Xiaolei Wang <xiaolei.wang@windriver.com>,
Suraj Jaiswal <quic_jsuraj@quicinc.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Gal Pressman <gal@nvidia.com>,
Jesper Nilsson <jesper.nilsson@axis.com>,
Choong Yong Liang <yong.liang.choong@linux.intel.com>,
Chwee-Lin Choong <chwee.lin.choong@intel.com>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [PATCH iwl-next v8 07/11] igc: add support for frame preemption verification
Date: Fri, 7 Mar 2025 19:52:33 +0800 [thread overview]
Message-ID: <43277258-7100-4230-82da-8a78ad341dde@linux.intel.com> (raw)
In-Reply-To: <20250306002825.rva7wjsymmms7kbd@skbuf>
On 6/3/2025 8:28 am, Vladimir Oltean wrote:
> On Wed, Mar 05, 2025 at 08:00:22AM -0500, Faizal Rahim wrote:
>> Co-developed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Co-developed-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
>> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
>> Co-developed-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
>> Signed-off-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
>> ---
>> +
>> +static inline bool igc_fpe_is_verify_or_response(union igc_adv_rx_desc *rx_desc,
>> + unsigned int size, void *pktbuf)
>> +{
>> + u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
>> + static const u8 zero_payload[SMD_FRAME_SIZE] = {0};
>> + int smd;
>> +
>> + smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
>> +
>> + return (smd == IGC_RXD_STAT_SMD_TYPE_V || smd == IGC_RXD_STAT_SMD_TYPE_R) &&
>> + size == SMD_FRAME_SIZE &&
>> + !memcmp(pktbuf, zero_payload, SMD_FRAME_SIZE); /* Buffer is all zeros */
>
> Using this definition...
>
>> +}
>> +
>> +static inline void igc_fpe_lp_event_status(union igc_adv_rx_desc *rx_desc,
>> + struct ethtool_mmsv *mmsv)
>> +{
>> + u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
>> + int smd;
>> +
>> + smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
>> +
>> + if (smd == IGC_RXD_STAT_SMD_TYPE_V)
>> + ethtool_mmsv_event_handle(mmsv, ETHTOOL_MMSV_LP_SENT_VERIFY_MPACKET);
>> + else if (smd == IGC_RXD_STAT_SMD_TYPE_R)
>> + ethtool_mmsv_event_handle(mmsv, ETHTOOL_MMSV_LP_SENT_RESPONSE_MPACKET);
>> +}
>> @@ -2617,6 +2617,15 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
>> size -= IGC_TS_HDR_LEN;
>> }
>>
>> + if (igc_fpe_is_pmac_enabled(adapter) &&
>> + igc_fpe_is_verify_or_response(rx_desc, size, pktbuf)) {
>
> ... invalid SMD-R and SMD-V frames will skip this code block altogether, and
> will be passed up the network stack, and visible at least in tcpdump, correct?
> Essentially, if the link partner would craft an ICMP request packet with
> an SMD-V or SMD-R, your station would respond to it, which is incorrect.
>
> A bit strange, the behavior in this case seems a bit under-specified in
> the standard, and I don't see any counter that should be incremented.
>
>> + igc_fpe_lp_event_status(rx_desc, &adapter->fpe.mmsv);
>> + /* Advance the ring next-to-clean */
>> + igc_is_non_eop(rx_ring, rx_desc);
>> + cleaned_count++;
>> + continue;
>> + }
>
> To fix this, don't you want to merge the unnaturally split
> igc_fpe_is_verify_or_response() and igc_fpe_lp_event_status() into a
> single function, which returns true whenever the mPacket should be
> consumed by the driver, but decides whether to emit a mmsv event on its
> own? Merging the two would also avoid reading rx_desc->wb.upper.status_error
> twice.
>
> Something like this:
>
> static inline bool igc_fpe_handle_mpacket(struct igc_adapter *adapter,
> union igc_adv_rx_desc *rx_desc,
> unsigned int size, void *pktbuf)
> {
> u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
> int smd;
>
> smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
> if (smd != IGC_RXD_STAT_SMD_TYPE_V && smd != IGC_RXD_STAT_SMD_TYPE_R)
> return false;
>
> if (size == SMD_FRAME_SIZE && mem_is_zero(pktbuf, SMD_FRAME_SIZE)) {
> struct ethtool_mmsv *mmsv = &adapter->fpe.mmsv;
> enum ethtool_mmsv_event event;
>
> if (smd == IGC_RXD_STAT_SMD_TYPE_V)
> event = ETHTOOL_MMSV_LP_SENT_VERIFY_MPACKET;
> else
> event = ETHTOOL_MMSV_LP_SENT_RESPONSE_MPACKET;
>
> ethtool_mmsv_event_handle(mmsv, event);
> }
>
> return true;
> }
>
> if (igc_fpe_is_pmac_enabled(adapter) &&
> igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf)) {
> /* Advance the ring next-to-clean */
> igc_is_non_eop(rx_ring, rx_desc);
> cleaned_count++;
> continue;
> }
>
> [ also remark the use of mem_is_zero() instead of memcmp() with a buffer
> pre-filled with zeroes. It should be more efficient, for the simple
> reason that it's accessing a single memory buffer and not two. Though
> I'm surprised how widespread the memcmp() pattern is throughout the
> kernel. ]
Thanks for the suggestion—it reads much better and flows smoothly. Got it
on the driver needing to consume a non-zero packet buffer from SMD-V and SMD-R.
WARNING: multiple messages have this Message-ID (diff)
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@linux.intel.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Furong Xu <0x1207@gmail.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
Serge Semin <fancer.lancer@gmail.com>,
Xiaolei Wang <xiaolei.wang@windriver.com>,
Suraj Jaiswal <quic_jsuraj@quicinc.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Gal Pressman <gal@nvidia.com>,
Jesper Nilsson <jesper.nilsson@axis.com>,
Choong Yong Liang <yong.liang.choong@linux.intel.com>,
Chwee-Lin Choong <chwee.lin.choong@intel.com>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v8 07/11] igc: add support for frame preemption verification
Date: Fri, 7 Mar 2025 19:52:33 +0800 [thread overview]
Message-ID: <43277258-7100-4230-82da-8a78ad341dde@linux.intel.com> (raw)
In-Reply-To: <20250306002825.rva7wjsymmms7kbd@skbuf>
On 6/3/2025 8:28 am, Vladimir Oltean wrote:
> On Wed, Mar 05, 2025 at 08:00:22AM -0500, Faizal Rahim wrote:
>> Co-developed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Co-developed-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
>> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
>> Co-developed-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
>> Signed-off-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
>> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
>> ---
>> +
>> +static inline bool igc_fpe_is_verify_or_response(union igc_adv_rx_desc *rx_desc,
>> + unsigned int size, void *pktbuf)
>> +{
>> + u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
>> + static const u8 zero_payload[SMD_FRAME_SIZE] = {0};
>> + int smd;
>> +
>> + smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
>> +
>> + return (smd == IGC_RXD_STAT_SMD_TYPE_V || smd == IGC_RXD_STAT_SMD_TYPE_R) &&
>> + size == SMD_FRAME_SIZE &&
>> + !memcmp(pktbuf, zero_payload, SMD_FRAME_SIZE); /* Buffer is all zeros */
>
> Using this definition...
>
>> +}
>> +
>> +static inline void igc_fpe_lp_event_status(union igc_adv_rx_desc *rx_desc,
>> + struct ethtool_mmsv *mmsv)
>> +{
>> + u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
>> + int smd;
>> +
>> + smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
>> +
>> + if (smd == IGC_RXD_STAT_SMD_TYPE_V)
>> + ethtool_mmsv_event_handle(mmsv, ETHTOOL_MMSV_LP_SENT_VERIFY_MPACKET);
>> + else if (smd == IGC_RXD_STAT_SMD_TYPE_R)
>> + ethtool_mmsv_event_handle(mmsv, ETHTOOL_MMSV_LP_SENT_RESPONSE_MPACKET);
>> +}
>> @@ -2617,6 +2617,15 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
>> size -= IGC_TS_HDR_LEN;
>> }
>>
>> + if (igc_fpe_is_pmac_enabled(adapter) &&
>> + igc_fpe_is_verify_or_response(rx_desc, size, pktbuf)) {
>
> ... invalid SMD-R and SMD-V frames will skip this code block altogether, and
> will be passed up the network stack, and visible at least in tcpdump, correct?
> Essentially, if the link partner would craft an ICMP request packet with
> an SMD-V or SMD-R, your station would respond to it, which is incorrect.
>
> A bit strange, the behavior in this case seems a bit under-specified in
> the standard, and I don't see any counter that should be incremented.
>
>> + igc_fpe_lp_event_status(rx_desc, &adapter->fpe.mmsv);
>> + /* Advance the ring next-to-clean */
>> + igc_is_non_eop(rx_ring, rx_desc);
>> + cleaned_count++;
>> + continue;
>> + }
>
> To fix this, don't you want to merge the unnaturally split
> igc_fpe_is_verify_or_response() and igc_fpe_lp_event_status() into a
> single function, which returns true whenever the mPacket should be
> consumed by the driver, but decides whether to emit a mmsv event on its
> own? Merging the two would also avoid reading rx_desc->wb.upper.status_error
> twice.
>
> Something like this:
>
> static inline bool igc_fpe_handle_mpacket(struct igc_adapter *adapter,
> union igc_adv_rx_desc *rx_desc,
> unsigned int size, void *pktbuf)
> {
> u32 status_error = le32_to_cpu(rx_desc->wb.upper.status_error);
> int smd;
>
> smd = FIELD_GET(IGC_RXDADV_STAT_SMD_TYPE_MASK, status_error);
> if (smd != IGC_RXD_STAT_SMD_TYPE_V && smd != IGC_RXD_STAT_SMD_TYPE_R)
> return false;
>
> if (size == SMD_FRAME_SIZE && mem_is_zero(pktbuf, SMD_FRAME_SIZE)) {
> struct ethtool_mmsv *mmsv = &adapter->fpe.mmsv;
> enum ethtool_mmsv_event event;
>
> if (smd == IGC_RXD_STAT_SMD_TYPE_V)
> event = ETHTOOL_MMSV_LP_SENT_VERIFY_MPACKET;
> else
> event = ETHTOOL_MMSV_LP_SENT_RESPONSE_MPACKET;
>
> ethtool_mmsv_event_handle(mmsv, event);
> }
>
> return true;
> }
>
> if (igc_fpe_is_pmac_enabled(adapter) &&
> igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf)) {
> /* Advance the ring next-to-clean */
> igc_is_non_eop(rx_ring, rx_desc);
> cleaned_count++;
> continue;
> }
>
> [ also remark the use of mem_is_zero() instead of memcmp() with a buffer
> pre-filled with zeroes. It should be more efficient, for the simple
> reason that it's accessing a single memory buffer and not two. Though
> I'm surprised how widespread the memcmp() pattern is throughout the
> kernel. ]
Thanks for the suggestion—it reads much better and flows smoothly. Got it
on the driver needing to consume a non-zero packet buffer from SMD-V and SMD-R.
next prev parent reply other threads:[~2025-03-07 11:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 13:00 [PATCH iwl-next v8 00/11] igc: Add support for Frame Preemption feature in IGC Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 13:00 ` [PATCH iwl-next v8 01/11] net: stmmac: move frag_size handling out of spin_lock Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 22:30 ` Vladimir Oltean
2025-03-05 22:30 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-06 2:09 ` Furong Xu
2025-03-06 2:09 ` [Intel-wired-lan] " Furong Xu
2025-03-05 13:00 ` [PATCH iwl-next v8 02/11] net: ethtool: mm: extract stmmac verification logic into common library Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 13:00 ` [PATCH iwl-next v8 03/11] net: ethtool: mm: reset verification status when link is down Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 22:45 ` Vladimir Oltean
2025-03-05 22:45 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-05 13:00 ` [PATCH iwl-next v8 04/11] igc: rename xdp_get_tx_ring() for non-xdp usage Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 13:00 ` [PATCH iwl-next v8 05/11] igc: optimize the TX packet buffer utilization Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 22:46 ` Vladimir Oltean
2025-03-05 22:46 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-05 13:00 ` [PATCH iwl-next v8 06/11] igc: set the RX packet buffer size for TSN mode Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 22:58 ` Vladimir Oltean
2025-03-05 22:58 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-05 13:00 ` [PATCH iwl-next v8 07/11] igc: add support for frame preemption verification Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-06 0:28 ` Vladimir Oltean
2025-03-06 0:28 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-07 11:52 ` Abdul Rahim, Faizal [this message]
2025-03-07 11:52 ` Abdul Rahim, Faizal
2025-03-05 13:00 ` [PATCH iwl-next v8 08/11] igc: add support to set tx-min-frag-size Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-06 0:43 ` Vladimir Oltean
2025-03-06 0:43 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-07 11:26 ` Abdul Rahim, Faizal
2025-03-07 11:26 ` [Intel-wired-lan] " Abdul Rahim, Faizal
2025-03-05 13:00 ` [PATCH iwl-next v8 09/11] igc: block setting preemptible traffic class in taprio Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 13:00 ` [PATCH iwl-next v8 10/11] igc: add support to get MAC Merge data via ethtool Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-05 13:00 ` [PATCH iwl-next v8 11/11] igc: add support to get frame preemption statistics " Faizal Rahim
2025-03-05 13:00 ` [Intel-wired-lan] " Faizal Rahim
2025-03-06 0:48 ` Vladimir Oltean
2025-03-06 0:48 ` [Intel-wired-lan] " Vladimir Oltean
2025-03-07 3:20 ` Abdul Rahim, Faizal
2025-03-07 3:20 ` [Intel-wired-lan] " Abdul Rahim, Faizal
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=43277258-7100-4230-82da-8a78ad341dde@linux.intel.com \
--to=faizal.abdul.rahim@linux.intel.com \
--cc=0x1207@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chwee.lin.choong@intel.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fancer.lancer@gmail.com \
--cc=gal@nvidia.com \
--cc=hawk@kernel.org \
--cc=hayashi.kunihiko@socionext.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesper.nilsson@axis.com \
--cc=john.fastabend@gmail.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=quic_jsuraj@quicinc.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
--cc=xiaolei.wang@windriver.com \
--cc=yong.liang.choong@linux.intel.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.