mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "MITTAL, HIMANSHU" <h-mittal1@ti.com>
To: Simon Horman <horms@kernel.org>
Cc: <pabeni@redhat.com>, <kuba@kernel.org>, <edumazet@google.com>,
	<davem@davemloft.net>, <andrew+netdev@lunn.ch>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <srk@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Roger Quadros <rogerq@kernel.org>, <danishanwar@ti.com>,
	<m-malladi@ti.com>, <pratheesh@ti.com>, <prajith@ti.com>
Subject: Re: [PATCH net v2] net: ti: icssg-prueth: Fix buffer allocation for ICSSG
Date: Tue, 15 Jul 2025 12:37:45 +0530	[thread overview]
Message-ID: <b626dc40-e05b-40e0-b300-45ced82d2f97@ti.com> (raw)
In-Reply-To: <20250711144323.GV721198@horms.kernel.org>


On 7/11/2025 8:13 PM, Simon Horman wrote:
> On Thu, Jul 10, 2025 at 06:42:50PM +0530, Himanshu Mittal wrote:
>> Fixes overlapping buffer allocation for ICSSG peripheral
>> used for storing packets to be received/transmitted.
>> There are 3 buffers:
>> 1. Buffer for Locally Injected Packets
>> 2. Buffer for Forwarding Packets
>> 3. Buffer for Host Egress Packets
>>
>> In existing allocation buffers for 2. and 3. are overlapping causing packet
>> corruption.
>>
>> Packet corruption observations:
>> During tcp iperf testing, due to overlapping buffers the received ack
>> packet overwrites the packet to be transmitted. So, we see packets on wire
>> with the ack packet content inside the content of next TCP packet from
>> sender device.
>>
>> Details for AM64x switch mode:
>> -> Allocation by existing driver:
>> +---------+-------------------------------------------------------------+
>> |         |          SLICE 0             |          SLICE 1             |
>> |         +------+--------------+--------+------+--------------+--------+
>> |         | Slot | Base Address | Size   | Slot | Base Address | Size   |
>> |---------+------+--------------+--------+------+--------------+--------+
>> |         | 0    | 70000000     | 0x2000 | 0    | 70010000     | 0x2000 |
>> |         | 1    | 70002000     | 0x2000 | 1    | 70012000     | 0x2000 |
>> |         | 2    | 70004000     | 0x2000 | 2    | 70014000     | 0x2000 |
>> | FWD     | 3    | 70006000     | 0x2000 | 3    | 70016000     | 0x2000 |
>> | Buffers | 4    | 70008000     | 0x2000 | 4    | 70018000     | 0x2000 |
>> |         | 5    | 7000A000     | 0x2000 | 5    | 7001A000     | 0x2000 |
>> |         | 6    | 7000C000     | 0x2000 | 6    | 7001C000     | 0x2000 |
>> |         | 7    | 7000E000     | 0x2000 | 7    | 7001E000     | 0x2000 |
>> +---------+------+--------------+--------+------+--------------+--------+
>> |         | 8    | 70020000     | 0x1000 | 8    | 70028000     | 0x1000 |
>> |         | 9    | 70021000     | 0x1000 | 9    | 70029000     | 0x1000 |
>> |         | 10   | 70022000     | 0x1000 | 10   | 7002A000     | 0x1000 |
>> | Our     | 11   | 70023000     | 0x1000 | 11   | 7002B000     | 0x1000 |
>> | LI      | 12   | 00000000     | 0x0    | 12   | 00000000     | 0x0    |
>> | Buffers | 13   | 00000000     | 0x0    | 13   | 00000000     | 0x0    |
>> |         | 14   | 00000000     | 0x0    | 14   | 00000000     | 0x0    |
>> |         | 15   | 00000000     | 0x0    | 15   | 00000000     | 0x0    |
>> +---------+------+--------------+--------+------+--------------+--------+
>> |         | 16   | 70024000     | 0x1000 | 16   | 7002C000     | 0x1000 |
>> |         | 17   | 70025000     | 0x1000 | 17   | 7002D000     | 0x1000 |
>> |         | 18   | 70026000     | 0x1000 | 18   | 7002E000     | 0x1000 |
>> | Their   | 19   | 70027000     | 0x1000 | 19   | 7002F000     | 0x1000 |
>> | LI      | 20   | 00000000     | 0x0    | 20   | 00000000     | 0x0    |
>> | Buffers | 21   | 00000000     | 0x0    | 21   | 00000000     | 0x0    |
>> |         | 22   | 00000000     | 0x0    | 22   | 00000000     | 0x0    |
>> |         | 23   | 00000000     | 0x0    | 23   | 00000000     | 0x0    |
>> +---------+------+--------------+--------+------+--------------+--------+
>> --> here 16, 17, 18, 19 overlapping with below express buffer
>>
>> +-----+-----------------------------------------------+
>> |     |       SLICE 0       |        SLICE 1          |
>> |     +------------+----------+------------+----------+
>> |     | Start addr | End addr | Start addr | End addr |
>> +-----+------------+----------+------------+----------+
>> | EXP | 70024000   | 70028000 | 7002C000   | 70030000 | <-- Overlapping
> Thanks for the detailed explanation with these tables.
> It is very helpful. I follow both the existing and new mappings
> with their help. Except for one thing.
>
> It's not clear how EXP was set to the values on the line above.
> Probably I'm missing something very obvious.
> Could you help me out here?

The root cause for this issue is that, buffer configuration for Express 
Frames
in function: prueth_fw_offload_buffer_setup() is missing.


Details:
The driver implements two distinct buffer configuration functions that 
are invoked
based on the driver state and ICSSG firmware:- 
prueth_fw_offload_buffer_setup()
- prueth_emac_buffer_setup()

During initialization, the driver creates standard network interfaces 
(netdevs) and
configures buffers via prueth_emac_buffer_setup(). This function 
properly allocates
and configures all required memory regions including:
- LI buffers
- Express packet buffers
- Preemptible packet buffers

However, when the driver transitions to an offload mode (switch/HSR/PRP),
buffer reconfiguration is handled by prueth_fw_offload_buffer_setup().
This function does not reconfigure the buffer regions required for 
Express packets,
leading to incorrect buffer allocation.
>> | PRE | 70030000   | 70033800 | 70034000   | 70037800 |
>> +-----+------------+----------+------------+----------+
>>
>> +---------------------+----------+----------+
>> |                     | SLICE 0  |  SLICE 1 |
>> +---------------------+----------+----------+
>> | Default Drop Offset | 00000000 | 00000000 |     <-- Field not configured
>> +---------------------+----------+----------+
> ...

Thanks,
Himanshu


  reply	other threads:[~2025-07-15  7:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-10 13:12 Himanshu Mittal
2025-07-11 14:43 ` Simon Horman
2025-07-15  7:07   ` MITTAL, HIMANSHU [this message]
2025-07-15 10:29     ` Simon Horman
2025-07-17  9:37       ` MITTAL, HIMANSHU
2025-07-17 12:18 ` Markus Elfring

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=b626dc40-e05b-40e0-b300-45ced82d2f97@ti.com \
    --to=h-mittal1@ti.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m-malladi@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=prajith@ti.com \
    --cc=pratheesh@ti.com \
    --cc=rogerq@kernel.org \
    --cc=srk@ti.com \
    --cc=vigneshr@ti.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

all inboxes | Powered by JetHome®