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]
Message-ID: <b0438a630812090148u4c42a193q833c913a1a27e0a9@mail.gmail.com>
Date:	Tue, 9 Dec 2008 10:48:03 +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/5 Krzysztof Halasa <khc@...waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@...il.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).
>
OK.

>> 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.
>
Sure... But in case you are not using ethernet in the NPEA (most
likely if you are using HSS), ethernet only takes one common queue
(TXDONE = 31). The rest of the queues seem to be NPE dependent. At
least that was what I thought, but if I change rxq and txreadyq for
ethernet in ixdp425-setup.c and give them the values 0x103, 0x114 for
NPEB and 0x203, 0x214 for NPEC they also interfere with the queues for
HSS (for not 0 hdlcs...).

So... Do we have 32 queues for NPE, or some of them are common for all
NPEs? In the first case it could be possible to work with 32 queues in
most of the situations... if not, 64-queue patch seems to be required
(where can I find last version of it? I just found one which is
heavily critizised by you, Krzysztof).

>>> /* 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.
>
How can I check it?

>>>> 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.
>
OK.

Thanks

Miguel Ángel
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ