Re: qmgr for ixp4xx

[Krzysztof Halasa <khc@pm.waw.pl>]

"Miguel Ángel Álvarez" <gotzoncabanes@gmail.com> writes:

>> The FIFOs are some internal property of HDLC controller (it isn't
>> documented but they probably connect the bus master DMA controller to
>> the bit-stuffer and transmitter (and bit-destuffer and receiver in the
>> RX path)). You just need to send a message to HSS to tell it the
>> correct value.
>>
> ¿The message is the HSS_CONFIG_CORE_CR containing the
> CCR_NPE_HFIFO_3_OR_4HDLC flag?

Well right, this one, too. I missed this one.

So it seems the following are needed (and 128-bit LUT):

#define PKT_NUM_PIPES           1 /* 1, 2 or 4 */
#define PKT_NUM_PIPES_WRITE             0x52

#define PKT_PIPE_FIFO_SIZEW     4 /* total 4 dwords per HSS */
(= 1 word for 4E1, 2 words for 2E1, 4 for 1E1)
#define PKT_PIPE_FIFO_SIZEW_WRITE       0x53

#define CCR_NPE_HFIFO_2_HDLC            0x04000000
#define CCR_NPE_HFIFO_3_OR_4HDLC        0x08000000
(to be set in the CORE register).

> I understand this, but I do not know exactly how to use it. I mean...
> - I have seen that more queues are added for tx and rxfree, but not rx
> or txdone... Are they not require?

The HSS uses 4 TX queues (each for 1 HDLC/packetized stream), and it
sends all used descriptors back to TXDONE queue (all 4 streams).

The same with RX, you have 4 RXFREE queues (= "RX empty" descriptors,
waiting for RX data), but when the data is ready, they are going back
to the CPU in a single RX queue. There is a stream# in the descriptor.

> - Must we use different txreadyq for each hdlc?

Yes, otherwise one HSS could grab all descriptors thus making the
other HSS (temporarily) unusable. Actually we need a TXREADY queues
per HDLC stream (4 per 4E1 port).

> - The values you have chosen for txreadyq are 2 and 19. Does it not
> conflict with HSS0_PKT_RXFREE1_QUEUE and HSS1_PKT_RXFREE1_QUEUE.

It does certainly conflict. For now there are no problems because MVIP
isn't supported. I guess we need 64-queue support. Fortunately, Karl
Hiramoto already has a patch for 64 queues, almost ready for merge.

We also have to make sure the queues don't conflict with the Ethernet
driver and (if used) with the crypto code.

> - I am not sure which documentation did you use for this (great)
> implementation of eth and hss. The intel manuals lack all information
> about this, so I am trying to check differences with Intel's software
> library (a nightmare),

I was using the library, though I processed it first with some custom
scripts to make it easier to read. Christian Hohnstaedt's code was
also a great help to understand what's going on.

> and have found that in "ixHssAccPktTxInternal"
> they add the hdlc port to the entry (which at last seemed to me that
> they were accessing consecutive memory positions from the entry for
> hdlc0).

Do you mean this?
/* Set the least significant 2 bits of the queue entry to the HDLC port number. */
qEntry |= (hdlcPortId & IX_HSSACC_QM_Q_CHAN_NUM_MASK);

They want it when the packet is back in TXDONE queue.

> So that is why I thought acc represented the same thing.

No, acc is a private thing of queue manager. HSS code don't know about
it.

> What you are saying is that if I send the data to the correct
> tx queue, it will reach the correct FIFO... OK.

Yes.

> And reception? If I
> have only one reception queue how could I manage to know to which
> channel have I received the data?

The descriptor will have an ID in it.

> - Do you know where can it be found more information about this
> relation between queues, dmas and FIFOs? You are helping me greatly,
> but I do not want to make you loose so much time.

We only have ixp4xx library code. Few small minutes of my time are
not a problem when spent to help implement a useful feature.

I wonder what should I do now with all this. Perhaps integrating
Karl's 64-queue patch and making the HDLC part of HSS driver able to
be merged upstream... I will look if it does make sense.
-- 
Krzysztof Halasa