Re: qmgr for ixp4xx

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

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

>> We also have to make sure the queues don't conflict with the Ethernet
>> driver and (if used) with the crypto code.
>>
> The queues are different for each NPE, aren' t they?

They have to (except one Ethernet queue (TXDONE) which is used by all
ports).

> I will check for the 64-queue support patch (thanks Karl). However, if
> I am not sure they are required. I mean...
> - HSS0 uses queues 12-22.
> - HSS1 uses queues 0-10.
> - That leaves us 10 queues free, doesn't it? Couldn't we use queue 11
> for eth txreadyq, 23-26 for HSS0 txreadyq, 27-30 for HSS1 txreadyq and
> 31 for crypto code (which I do not know?)

Ethernet needs 3 queues per port + 1 (465 CPUs can have 3 Ethernet
ports), the crypto code probably needs several ones.

>> /* 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.
>>
> Ummm? To know which queue should be refeeded? How could we do that?

I think so. You'd have to check with the real hardware, I remember
some NPEs set some fields in the descriptors.

>>> 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.
>>
> Where?

In the lower address bits (bits 0-4?), like in the line above.

> I was trying to improve your code to make it work in a 4E1. Before
> making it configurable, I have made a first implementation considering
> only my problem (which is not completely fixed yet). I will send you a
> patch with my development (too large to add it in the list), so that
> you could give me your oppinion if you want to. I would like to merge
> it with your code when it is working (and the clean-up is made).

Great.
-- 
Krzysztof Halasa