netdev - Re: ixp4xx_hss MAX_CHAN

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] [day] [month] [year] [list]

Message-ID: <b0438a630811260408t6952603ei66c15d4cf1c18cca@mail.gmail.com>
Date:	Wed, 26 Nov 2008 13:08:43 +0100
From:	"Miguel Ángel Álvarez" <gotzoncabanes@...il.com>
To:	"Krzysztof Halasa" <khc@...waw.pl>
Cc:	netdev@...r.kernel.org, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: ixp4xx_hss MAX_CHAN_DEVICES

Again... thanks a lot for your answers.

2008/11/26 Krzysztof Halasa <khc@...waw.pl>:
> "Miguel Ángel Álvarez" <gotzoncabanes@...il.com> writes:
>
>>> Basically MVIP divides your entire frame into 2 or 4 parts.
>>>
>> Sure. But... It is automatically activated when the frame length is
>> greater than 256 or should it be explicitelly set?
>
> You must set the number of (packetized) pipes.
> For channelized data, there is apparently no difference.
>
No problem in this.

>> OK... I understand the concept, but I am not sure about how this is
>> integrated with your driver (or the NPE). I mean... When I use your
>> driver, I obtain two interfaces hdlc0 and hdlc1 (one per HSS). If I
>> had only a packetized stream, I could open a socket to the interface
>> and send the data. No problem (I think) in it.
>> But if I want to have four streams (one per E1), is your driver
>> prepare to deal with this, or should I manage to create four
>> interfaces per HSS?
>
> The driver is currently missing the MVIP code.
>
That is what I supposed.

>> In the first case... Is it related with set_hdlc_chan function? The
>> name could suggest this, but then it does nothing for MODE_HDLC but
>> MODE_RAW and MODE_G704.
>
> That's for channelized data.
>
OK.

>> In the second case... I understand that if I have to add the new
>> interfaces, they should be network interfaces. Where do you recommend
>> me to do it?
>
> I'd have to look at it.
>
OK, thanks. If we add an HSS id in the platform driver, I think we
could create up to 4 hdlc interfaces for each HSS. As all of them are
independent, all your code could be useful for each one. The main
question would be then how to map each one with the correct FIFO, not?
(What does txreadyq represent? How are their values chosen?)

>> In both cases... How can the user direct his data to one E1 or the other?
>
> Each "member" E1 is connected to its respective HDLC controller
> ("packetized pipe"), and these have "TX" and "RX-free" queues (one set
> per each HDLC).
>
Sure... I suppose I have to modify queue_ids to use the correct queues
for tx and rx values. What should I do for txdone, rxfree and chan
values?

>> In my case (bad luck...) we have a legacy mode of connection, so I
>> cannot use any of the methods described. I "just" need something
>> similar to the IxHssAccPktPortConnection in the Intel Software
>> Library...
>
> Sure, you can use this raw HDLC + packet interface. One stream per
> (member) E1/T1 (or, to be precise, one stream per 1, 1/2 or 1/4 of the
> physical interface).
>
Yes... I think this raw HDLC (although we are talking of raw HDLC we
are refering to MODE_HDLC with "sethdlc hdlc0 hdlc" and not MODE_RAW,
not?) is the answer if I found a way to create and interconnect
correctly 4*2 interfaces (hdlc0-hdlc7?).

Thanks a lot

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