On 4/3/2025 11:26 pm, Vladimir Oltean wrote:
On Mon, Mar 03, 2025 at 05:26:54AM -0500, Faizal Rahim wrote:+static inline bool igc_fpe_is_verify_or_response(union igc_adv_rx_desc *rx_desc, + unsigned int size) +{ + 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); + + return (smd == IGC_RXD_STAT_SMD_TYPE_V || smd == IGC_RXD_STAT_SMD_TYPE_R) && + size == SMD_FRAME_SIZE; +}The NIC should explicitly not respond to frames which have an SMD-V but are not "verify" mPackets (7 octets of 0x55 + 1 octet SMD-V + 60 octets of 0x00 + mCRC - as per 802.3 definitions). Similarly, it should only treat SMD-R frames which contain 7 octets of 0x55 + 1 octet SMD-R + 60 octets of 0x00 + mCRC as "respond" mPackets, and only advance its verification state machine based on those. Specifically, it doesn't look like you are ensuring the packet payload contains 60 octets of zeroes. Is this something that the hardware already does for you, or is it something that needs further validation and differentiation in software?
The hardware doesn’t handle this, so the igc driver have to do it manually. I missed this handling, and Chwee Lin also noticed the issue while testing this patch series—it wasn’t rejecting SMD-V and SMD-R with a non-zero payload. I’ll update this patch to include the fix that Chwee Lin implemented and tested. Thanks.
