netdev - Re: qmgr for ixp4xx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Dec 2008 09:51:18 +0100
From:	"Miguel Ángel Álvarez" <gotzoncabanes@...il.com>
To:	"Krzysztof Halasa" <khc@...waw.pl>
Cc:	netdev@...r.kernel.org
Subject: Re: qmgr for ixp4xx

Hi

2008/12/4 Krzysztof Halasa <khc@...waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@...il.com> writes:
>
>> As I am trying to use my HSSs as 4E1, I find that the FIFOs for each
>> HDLC should be 1 word wide and not 4 words wide. I think that this
>> finally means that when accessing the queues, I have to do the
>> following modification.
>>
>> +++ linux-2.6.26.7/include/asm-arm/arch-ixp4xx/qmgr.h 2008-12-02
>> 10:47:23.000000000 +0100
>> @@ -67,16 +67,17 @@
>>  void qmgr_release_queue(unsigned int queue);
>>
>>
>> -static inline void qmgr_put_entry(unsigned int queue, u32 val)
>> +static inline void qmgr_put_entry(unsigned int queue, unsigned int pipe,
>> +                   u32 val)
>>  {
>>       extern struct qmgr_regs __iomem *qmgr_regs;
>> -     __raw_writel(val, &qmgr_regs->acc[queue][0]);
>> +     __raw_writel(val, &qmgr_regs->acc[queue][pipe]);
>>  }
>>
>> -static inline u32 qmgr_get_entry(unsigned int queue)
>> +static inline u32 qmgr_get_entry(unsigned int queue, unsigned int pipe)
>>  {
>>       extern struct qmgr_regs __iomem *qmgr_regs;
>> -     return __raw_readl(&qmgr_regs->acc[queue][0]);
>> +     return __raw_readl(&qmgr_regs->acc[queue][pipe]);
>>  }
>
> 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?

> Queues, on the other hand, can be 1, 2 or 4-words wide (32, 64 or 128
> bits). I think nothing uses/needs 2 or 4-word queues so they aren't
> implemented.
>
> 4E1 mode uses the same 1-word queues. It just uses more queues :-)

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?
- Must we use different txreadyq for each hdlc?
- 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.
Shouldn't we use 23 and 24 (for example)?
- 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), 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). So that is why I thought acc represented the same thing. If
not... What you are saying is that if I send the data to the correct
tx queue, it will reach the correct FIFO... OK. And reception? If I
have only one reception queue how could I manage to know to which
channel have I received the data?
- 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.

Thanks

Miguel Ángel Álvarez
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html