[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bb88fc9-5acd-0997-15c8-a9164c789738@caviumnetworks.com>
Date: Thu, 2 Nov 2017 12:12:33 -0700
From: David Daney <ddaney@...iumnetworks.com>
To: Florian Fainelli <f.fainelli@...il.com>,
David Daney <david.daney@...ium.com>,
linux-mips@...ux-mips.org, ralf@...ux-mips.org,
James Hogan <james.hogan@...s.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>
Cc: linux-kernel@...r.kernel.org,
"Steven J. Hill" <steven.hill@...ium.com>,
devicetree@...r.kernel.org, Carlos Munoz <cmunoz@...ium.com>
Subject: Re: [PATCH 4/7] MIPS: Octeon: Add Free Pointer Unit (FPA) support.
On 11/02/2017 11:04 AM, Florian Fainelli wrote:
> On 11/02/2017 09:27 AM, David Daney wrote:
>> On 11/01/2017 08:29 PM, Florian Fainelli wrote:
>>> Le 11/01/17 à 17:36, David Daney a écrit :
>>>> From: Carlos Munoz <cmunoz@...ium.com>
>>>>
>>>> From the hardware user manual: "The FPA is a unit that maintains
>>>> pools of pointers to free L2/DRAM memory. To provide QoS, the pools
>>>> are referenced indirectly through 1024 auras. Both core software
>>>> and hardware units allocate and free pointers."
>>>
>>> This looks like a possibly similar implement to what
>>> drivers/net/ethernet/marvell/mvneta_bm.c, can you see if you can make
>>> any use of genpool_* and include/net/hwbm.h here as well?
>>
>> Yikes! Is it permitted to put function definitions that are not "static
>> inline" in header files?
>
> Meh well, this is not even ressembling what we initially discussed, so I
> was hoping we could build more interesting features on top of this.
>
>>
>> The driver currently doesn't use page fragments, so I don't think that
>> the hwbm thing can be used.
>>
>> Also the FPA unit is used to control RED and back pressure in the PKI
>> (packet input processor), which are features that are features not
>> considered in hwbm.
>>
>> The OCTEON-III hardware also uses the FPA for non-packet-buffer memory
>> allocations. So for those, it seems that hwbm is also not a good fit.
>
> OK, let me see if I understand how FPA works, can we say that this is
> more or less a buffer tokenizer in that, you give it a buffer physical
> address and it returns an unique identifier that the FPA uses for actual
> packet passing, transmission and other manipulations?
At a high level, think of the FPA as a FIFO containing DMA addresses
used by hardware. The FIFO property is not guaranteed, so it is best to
consider it as a pool of buffer addresses.
Software pushes pointers into the FPA, and the hardware RX unit (PKI)
pops them off when it needs an RX buffer. The TX unit (PKO) and input
queue (SSO) also use memory obtained from the FPA as backing store for
their internal queues.
In addition to obtaining buffers, the PKI uses the number of entries in
an FPA pool to control RED and back pressure.
There are other features not used by the driver like threshold
interrupts, and pointer alignment so you don't have to calculate the
buffer address from a pointer to the middle of the buffer when freeing.
>
> There were a few funky things in the network driver, I will comment there.
> --
> Florian
>
Powered by blists - more mailing lists